Subject: [Bundled-domain-names] A lightweight and semantics-free proposal to signal aliasing

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 14 Nov 2016 22:16:43 +0900

Following the discussion this evening in Seoul. If you have time to
read it before the BoF on Wednesday...

I'll formally present it at the BoF if there is interest.

Subject: I-D Action: draft-bortzmeyer-bundled-signaling-alias-00.txt
From: [email-masked]
To: <[email-masked]>
Date: Mon, 14 Nov 2016 05:02:40 -0800
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Signaling that a domain name is an alias of another one
        Author          : Stephane Bortzmeyer
	Filename        : draft-bortzmeyer-bundled-signaling-alias-00.txt
	Pages           : 7
	Date            : 2016-11-14

Abstract:
   This document suggests a light-weight and semantics-free way to
   signal, in the DNS itself, that a domain name is actually an alias of
   another one (and therefore that they are member of the same bundle).

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   dnsbundled maiing list <https://www.ietf.org/mailman/listinfo/
   bundled-domain-names>.  The source of the document, as well as a list
   of open issues, is currently kept at Github [1].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bortzmeyer-bundled-signaling-alias/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-bortzmeyer-bundled-signaling-alias-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "John Levine" <[email-masked]>
Date: 8 Nov 2016 19:37:31 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-

If the goal is to alias trees, I don't understand how clients would
use it.  Let's say you do this:

other.example. ALIAS main.example.

main.example. SAILA other.example.

Now I look up www.other.example, which I presume is supposed to be
substitutable for www.main.example.  How can I tell that one is
the alias for the other?  Tree walk?  Magic extra stuff in the
DNS response?  Something else?

Signed,
Confused

PS: This proposal looks a lot like a simpler version of Andrew's SOPA
proposal, which solved the problem by requiring a SOPA record at every
substitutable name.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 15 Nov 2016 11:09:11 +0900

Stephane,

At 2016-11-14 22:16:43 +0900

> I'll formally present it at the BoF if there is interest.

With the draft as written, a client has to explicitly request the ALIAS
record, right? Does it make sense to include this in the additional
section of an NXDOMAIN response to avoid this extra query?

Cheers,

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Nov 2016 11:20:14 +0900

On Tue, Nov 08, 2016 at 07:37:31PM -0000,
 John Levine <[email-masked]> wrote 
 a message of 26 lines which said:

> substitutable for www.main.example.

Yes.

> Tree walk?

Yes. May be helped by some optimisations from a public suffix list.

> Magic extra stuff in the DNS response?

No, the idea is to use unmodified name servers (resolvers or auths).

> proposal,

draft-sullivan-domain-policy-authority ? If so, _I_ am confused, SOPA
does not describe aliases/substitutable domain names, and it
explicitely does not work unless names are contiguous in the tree
("The target name SHOULD be either an ancestor, a descendent, or a
sibling of the owner name in the record.")

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Nov 2016 11:28:48 +0900

On Tue, Nov 15, 2016 at 11:09:11AM +0900,
 Shane Kerr <[email-masked]> wrote 
 a message of 63 lines which said:

> With the draft as written, a client has to explicitly request the
> ALIAS record, right?

Right.

> Does it make sense to include this in the additional section of an
> NXDOMAIN response to avoid this extra query?

Yes. I believe it is partially covered in the "An authoritative name
server MAY send it in the additional section of a response, when the
QNAME is a domain name which has such an ALIAS" provision of the
draft. May be rewrite it as " "An authoritative name server MAY send
it in the additional section of a response, when the QNAME is a domain
name which has such an ALIAS, or a descendant of such"?

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Nov 2016 12:44:13 +0900

Shouldn't DNAMEs in the parent zone work for this?

Sent from my iPhone

> On Nov 9, 2016, at 04:37, John Levine <[email-masked]> wrote:
> 
> Bundled-domain-names mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bundled-domain-names

---

From: "John R Levine" <[email-masked]>
Date: 15 Nov 2016 13:03:22 +0900

> Shouldn't DNAMEs in the parent zone work for this?

Now that you mention it, they should, give or take the well known problems 
with NS and MX.

>> proposal, which solved the problem by requiring a SOPA record at every

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 15 Nov 2016 13:28:19 +0900

On Tue, Nov 15, 2016 at 12:44:13PM +0900,
 Paul Wouters <[email-masked]> wrote 

> Shouldn't DNAMEs in the parent zone work for this?

Most of the time, you cannot add a DNAME in the parent. Two examples:
you're a TLD, the root does not allow it. Or you manage a 2nd-level
domain, most TLDs do not allow it.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Nov 2016 23:36:41 -0500

> sibling of the owner name in the record.")

That was only there because some people didn't like cross-tree
relationships, so I put it as a restriction in an effort to stop the
complaints.  It was never actually required.

And yes, I did originally think that the SOPA mechanism could be used
to help with this bundling stuff, but people hated that idea too.  If
we instead do it with a special-purpose version of the same technique,
I think that'd be a shame.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 15 Nov 2016 13:58:10 +0900

> domain, most TLDs do not allow it.

Well, OK, now it looks like BNAME, a DNAME that also mirrors itself.

draft-yao-dnsext-bname-06

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Nov 2016 00:17:46 -0500

> Well, OK, now it looks like BNAME, a DNAME that also mirrors itself.

And that, of course, is incompatible with DNSSEC unless you replicate
all the DNSSEC algorithms and (in effect) break all the validation in
the world until everyone upgrades.  Maybe the pain is worth it, but
I'm not especially convinced given the value that this seems to offer.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 16 Nov 2016 07:25:02 +0900

The idea that clients need to do a second lookup seems completely weird 
to me. It would take decades (at best) before most clients did this and, 
in the interim, a bundle would not be found. That seems to go against 
all the language-based use cases.

--Paul Hoffman