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

[Doug Barton <[e-mail]>]

On 02/18/2011 07:12, Andrew Sullivan wrote:
> 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 think what you have here is very clear, at least it helped me 
understand your concern quite a bit better.

> 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.

Agreed up to here.

> 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.)

Two comments ... First, just because we provide one or more solutions 
doesn't mean that the registrants of the preferred names will chose to 
use them. What generally happens with variants now is that either the 
registry assigns them to the registrant by default, or they are given 
the option to register them at an additional cost. At that point (for 
the most part) they also have the option of whether to delegate the 
variants or not. So IDN registrants are already dealing with these 
questions, we're just giving them a different set of tools with which to 
deal with them.

> 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.

Personally I think that's a really interesting idea, and I will try to 
work it into my CLONE draft (which I am aiming to have complete before 
the -00 deadline on March 7). For CLONE the design is that if a 
CLONE-aware resolver sends a query for a name that is actually a CLONE 
it gets the fact that it's a CLONE back in the ADDITIONAL section, so 
it's not impossible to believe that application developers could use 
that information.

What it sounds like may be useful is an additional RR (maybe CLONES) 
that asks the authority the question you posed above, "What other names 
are related to this one?" I can think of a couple of complications with 
that, not the least of which is that if the qname is one of the CLONEs, 
how do you represent the preferred label in the response (always list it 
first maybe)? The other problem that comes immediately to mind is what 
to do when you have multiple labels in a hostname and more than one of 
them has CLONEs. (Return all the possible variants is likely the correct 
answer, but depending on user creativity that could get unwieldy.)

But back to your original concern, I agree that we don't want to solve 
one part of the problem in a way that makes other parts of the problem 
harder (or impossible) to solve. But I think that we have to be careful 
not to throw our hands up too early, particularly before we've even 
tried to engage the people who are already dealing with these same 
issues we're discussing in theory.

The common case (at least as far as the IDN issues go) is likely to be a 
small enough number of variants that the registrants will be perfectly 
capable of manually configuring the relevant software for all of them. 
And for those that don't wish to do that they can simply choose to not 
provision the variants at the registry, just like they do now.


hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

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