Implementation questions (digressing from...) / A DNAME issue

[Andrew Sullivan]

On Thu, Jan 01, 2009 at 08:33:18PM -0500, John C Klensin wrote:

> And, if you think that is clear to a non-specialist, I look 
> forward to IETF Last Call :-(

It's currently a WG I-D, and it hasn't passed from WGLC for other
reasons.  Nevertheless, questions about the draft that show up how it
is not clear to someone with a passing knowledge of DNS would be
welcome on the namedroppers at ops.ietf.org mailing list.

> If I correctly understand Vaggelis's concern, the problem isn't 
> (only) the A RRs, but the MX RRs and anything else that happens 
> to be lying around the zone apex/ tree location of the DNAME RR 
> itself(SRV, AAAA, NAPTR, etc.).

Sure.  But in delegation-centric zones (which is after all surely what
the DNAME answer is supposed to be addressing) most of those record
types should be on the other side of the zone cut.  I hate to say,
"Don't do that," but if we're going to make the zone operators
responsible for significant parts of the way things work, then we have
to rely on them to tell delegated zone operators bad news sometimes.

> nodes only do not apply.  If that case is going to be common 
> enough, it is time to invent a third alias type that, for that 
> limited circumstance, does what people keep wanting and 
> expecting DNAME to do.

If people need something that really does alias a whole zone, then we
need an RRTYPE, yes.  But keep in mind that there are serious problems
with relying on a new RRTYPE for this use case, most of which boil
down to "we need to replace all the resolvers in the part of the
Internet we want to reach."  If we're going to do that, I suggest that
IDNA is maybe the wrong approach; we maybe need DNS2.  That seems like
a tall order.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.