Re: [dnsext] Some thoughts on the updated aliasing draft

[Ted Hardie <[e-mail]>]

On Sun, Mar 27, 2011 at 11:14 AM, Suzanne Woolf <[e-mail]> wrote:

> On Sun, Mar 27, 2011 at 05:29:52AM +0000, Paul Vixie wrote:
> > > Date: 26 Mar 2011 20:33:36 -0000
> > > From: "John Levine" <[e-mail]>
> > >
> > > ...  In particular, it's quite possible for the DNS to have one
> > > canonical record with everything else pointing to it, but at the
> > > application level all the names look the same.  If I were hacking on
> > > my web or mail servers to handle this stuff, a simple way to do the
> > > configuration would be to configure in the canonical name, and then
> > > set a flag saying also to handle all of the aliases.
>
> In terms of where we are with the problem statement: I think we've
> determined that we can assume a canonical or base name, with others
> pointing to it, is not only OK but the only practical approach, since
> a more complete isomorphism is hard to describe and may be impossible
> in the current DNS.
>
> Where we still have some thinking to do (IMHO, but as doc editor) is
> in chracterizing the need, if any, for some property of "sameness" or
> "aliases-of" amongst a group of names such that the application
> doesn't just get what it would have gotten if the alias was the
> canonical name in the first place.
>
>
I thought I was with you until this.  Presumably what it gets at the alias
is a pointer to the canonical name, rather than what it would have gotten if
the alias *was* the canonical name.  The advantage of this synthesized
CNAME-style approach is that the client libraries learn that what they
originally handed the DNS was a pointer.  In the ideal case, they can use
that information to update their handling as well (within limits, of course)


> From the registry provisioning side, what seems to be wanted is "the
> applicaton can get an identical result but for less work on the part
> of the provisioning registry/registries (and maybe more work on the
> part of the API/resolver) to simply provisioning all of the names in
> parallel."
>
>
To put this another way, you don't have to provision everything to provide a
complete set of pointers, as the first pointer tells the client how to
synthesize them.


> This may also be what applications want, but it doesn't include
> visibility to the application of other associated names, or the fact
> that there are any. Creating such a property and giving the applicaton
> access to it is a different requirement, and at the moment is hard to
> see clearly as an application issue, an API/interface issue, or a DNS
> protocol issue (in any combination).
>
>
So, just to restate this for my own jet-lagged benefit:  the client hands a
name to the DNS and gets back the information that it's a pointer to a
canonical name, along with the data required to synthesize other names ("You
asked for "blue.color.example.co.uk.  All names under and including
color.example.co.uk are cannonically at or under colour.example.co.uk").  So
the application could get back "Here's the data for
blue.colour.example.co.uk; the requested you handed me returned a pointer to
here".  If it doesn't understand that , it gets the data at the record
stored at blue.colour.example.co.uk.

Does this match what you're thinking?

Ted

> > if we're allowed by the people asking for this to require dns client
> > libraries and applications to have to be changed to handle a new kind
> > of canonicalization before they'll be able to handle the new definition
> > of "sameness" then this is a practical approach.
> >
> > 'dns client libraries and applications' means the whole internet, so i
> > naturally assumed that this approach was out of scope.
>
> It would be useful to document where we think this line is. Send text.
>
>


> thx,
> Suzanne
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>