Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment

[Brian Dickson <[e-mail]>]

I think there definitely needs to be a new combination of things:
RRTYPE, semantics, and API.

Overloading CNAME, while attractive, is likely to cause problems. It
is also limited by what CNAME permits for RDATA.

Consider a generic example, where there may be multiple equivalences
at multiple locations of a FQDN A.B.C.example.gr (say).

Say we have A1,A2,A3, and A4 that are all meant to be "the same", and
we want the "official" (canonical) name used to be A1.
Similarly, B1 for B2/B3/B4, C1 for C2/C3/C4.

It would be both cumbersome, and bloated, to have to put all
combinations into DNS as CNAMEs.
It would also be limiting to put other requirements onto how the zone
structure was built (such as requiring delegations/zone cuts).

Lets consider two aspects of the naming issue.
First, is the "same resolution" problem - having all combinations
An.Bn.Cn.example.gr resolve identically (such as with A records). (We
can leave that for another day, to discuss how to do that.)
Second, is having all such combinations advise the client what the
"canonical" name should be, i.e. A1.B1.C1.example.gr.

Having these two handled orthogonally, means there are two distinct
problems. It also means that the second problem is effectively
"opt-in"; it doesn't break anything that doesn't explicitly query for
it or understand it. It doesn't change the semantics of existing DNS
stuff.

Adding a new API, call it "dns_canonicalize()", lets things that care,
look up FQDNs, and get back "canonical FQDNs".
Ideally, the results of "gethostbyname(FQDN)" and
"gethostbyname(dns_canonicalize(FQDN))" would return the same values,
but I don't think it should be a strict requirement, rather a
"principal of least surprise" recommendation to zone operators.

The new RRTYPE could be, for example, CLABEL. A CLABEL's RDATA would
be either a "label", i.e. relative domain name, or an FQDN (ending
with a "." to anchor it at the root.)

So, in our example, A3.B2.C3.example.gr could be a CLABEL of "A1",
meaning only the left-most label has a "canonical" preferred label.
And B2.C3.example.gr could have a CLABEL of "B1", and C3.example.gr
could have a CLABEL of "C1".

The resolver implementing "dns_canonicalize" would start with the
FQDN, and work right-to-left (top down), looking for CLABELs at each
node. Any time a CLABEL is found, rewriting is done, either relative
(current label), or absolute (everything to the right).

So, "dns_canonicalize("A3.B2.C3.example.gr")" would proceed as:
A3.B2.C3.example.gr (no CLABEL at gr)
A3.B2.C3.example.gr (no CLABEL at example.gr)
A3.B2.C1.example.gr (CLABEL at C3 -> C1)
A3.B1.C1.example.gr (CLABEL at B2 -> B1)
A1.B1.C1.example.gr (CLABEL at A3 -> A1).

The extra code in a web browser would be taking what the user typed in
the address bar, apply (dns_canonicalize), and use the resulting name
as the correct name to open the http (or whatever) connection to the
server found at the corresponding A (or AAAA) record (or whatever else
gets used in figuring out where to go and what to do).

I think this has good scaling properties, doesn't break anything, and
is likely to be useful to those who need it. It doesn't matter if 97%
of the DNS namespace doesn't have any CLABELs, IMHO, as long as the
mechanism has adequate support at both the DNS protocol and the
application layers.

Brian

P.S. Perhaps CLABELs could be included in the additional section, if
QTYPE != CLABEL, to reduce delays, server load, etc. (?)

On Thu, Feb 17, 2011 at 3:17 PM, Mark Andrews <[e-mail]> wrote:
>
> In message <[e-mail]>, Danny Mayer writes:
>> Even if there were I'm not convinced that it would be useful since there
>> is no way on the RHS to specify the path. It can give you a name, a
>> port, a weight and a priority but no path. There was a proposal for a
>> URL RR but I cannot find it right now and I don't think the wg is
>> considering it, at least it's not on the document list.
>>
>> Danny
>
> Which can be dealt with entirely at the HTTP/S layer.
>
> People are using CNAME for
>
>        site -> hosting server
>
> this include "www.example.net CNAME example.net".
>
> We need to support
>
>        site alias -> site { -> hosting server }
>
>                 CNAME    NEW-TYPE
>
> Additionally people are too lazy to add records for each virtual
> service in the DNS so they use "* CNAME server" which makes using
> SRV hard as it requires prepended labels.
>
> To prevent breaking existing clients that use CNAME like NEW-TYPE
> client would look for NEW-TYPE and only re-write the URL there is
> a CNAME and a NEW-TYPE returned.
>
> The CNAME would be replace by NEW-TYPE + addresses records to
> help with the transition.
>
> This is very much like the introduction of MX records.  At
> some point you stop putting in address records.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>