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

[Andrew Sullivan <[e-mail]>]

no hat

On Fri, Feb 18, 2011 at 02:36:53PM +0000, Suzanne Woolf wrote:
> I *think* Andrew's text above says no, we can't reasonably help
> registry operators if we leave applications with the same problem they
> have now (knowing for themselves that string $x needs to map to string
> $y). But rather than argue with something he may not have actually
> said, I'm looking for further comments on this point.

That wasn't really what I was trying to say, so I guess I better clarify.

I'm trying to keep in mind two things at once.

On the one hand, we have a narrow issue about the DNS and
provisioning.  And the idea is that we need to make it easier to say
"When you encounter alias {A[1], A[2]. . .A[n]} for some value of n,
then that is mostly functionally equivalent to encountering FQDN F."
This isn't really that big a deal, and we have at least two
complimentary proposals on how to do it.  There are some tricks in
stating exactly what "mostly" and "functionally equivalent" mean, but
I think this isn't that hard.

But if we think about this in the larger sense, we have to confront
the reason why people want the above.  It is surely not just that
people want to have more ways to write the same name.  It is rather
that naive users on the Internet will try to use such "alternative
spelling" names, and we want to help the operators of sites that are
the target of such attempted use to make their lives easier.

Therefore, if we deliver an answer that makes it trivial to add all
these additional ways of referring to "the same host" or "the same
resource" or something like that, we cannot simply ignore the
potential issues for how the addressed services are going to manage
this plethora of names.  This is in fact exactly why I am so concerned
that we have not attracted broad-based attention from the applications
community: we need to hear from them, if we mess up, "Hey, DNS
weenies!  You just made my life impossible."  For if we do that, we
will have failed in the real goal of this work.

Consider that the mail admins and the web admins could be completely
different parts of the organization in a large enterprise (they were
in a university where I worked).  BNAME could have an effect on the
mail admin even if it were just added to help the web admin.  These
are practical consequences of a big change in the DNS protocol, and we
have to think about them in the case of adding new aliasing features.
(This is not the same as what happens when you do it with
provisioning: those admins already have to understand their
provisioning and the deployed applications already have rules for
those cases.)

This is why I think just solving the provisioning case, without at
least some way for the applications to know what to do, is not enough.

I have been very intrigued by the idea of having two-way pointers, so
that if you are a mail server and you're coming up, you can look up
your name and learn how else you might be called.  But nobody has
offered a proposal for how to do that nicely, and we haven't heard
from actual application people about whether that's useful or totally
silly.

(Note I'm not bashing "application people" and I appreciate, very
much, the active involvement of those who have relevant experience and
have been expressing opinions.  But those people are here extremely
notable for their rarity.)

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.