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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Andrew Sullivan writes:
> On Fri, Feb 18, 2011 at 02:09:13PM -0800, Doug Barton wrote:
> 
> > 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.
> 
> Well, yes and no.  Consider one of the favoured strategies in this
> area: BNAME.
> 
> The reason some people are unhappy with DNAME is because a DNAME at
> the parent side causes problems for (for instance) using email at the
> DNAMEd domain.  The natural use of BNAME, then, would be on the parent
> side (never mind whether it will work for email anyway, for now).
> 
> Now, today, people tend not to put DNAME on the parent side because it
> doesn't redirect the name itself.  But if we create this tool, it
> allows the parent side of the delegation effectively to _require_ that
> two names both be active; or at least, to force the child side of the
> delegation to handle the traffic from both "spellings". 
> 
> So if you want to run your mailserver at example.com, and your parent
> decides that you ought also to handle otherexample.com, you're going
> to get that traffic even if you don't want it.  And this, of course,
> carries up the tree.

This is where SMTP is now stupid. 822 (821?) required the sender
to rewrite in CNAME.  If you want multiple mail domains use a MX
record.  I suspect that a lot of this was driven because HTTP does
have the equivalent of MX and rather than fix the real problem SMTP
was stuffed up.

> That's a tool with potentially significant changes to the operational
> environment in which we have lived so far, and I don't want us to
> forget it.
> 
> > 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.
> 
> Yes.  I would keep at least a studied silence if I were throwing up my
> hands.  I'm not trying to be argumentative for its own sake.  I just
> want us to expose as many things as early as possible, while we're
> still working out what the problems are.  I'd hate to learn all of
> this in another year.
> 
> A
> 
> -- 
> Andrew Sullivan
> [e-mail]
> Shinkuro, Inc.
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]