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

[Andrew Sullivan]

On Fri, Jan 02, 2009 at 09:46:10AM -0500, John C Klensin wrote:

> relationship, regardless of how they are actually managed.  But 
> any real surrogacy relationship requires either aliasing or 
> somewhat parallel management of separate trees (whether on a 
> zone-by-zone or delegation-by-delegation within a zone basis). 
> "Don't do that" (or its traditional variation "just say no" may 
> very well be the right answer, but, with ICANN's help, that is 
> not a choice we are going to be able to make or impose at this 
> point --operational reality has gotten away from us and the only 
> choices are whether we want an alias type that does the right 
> thing or or want to encourage an environment in which people get 
> regularly surprised by the side-effects of people trying to 
> manage synchronized zones and subtrees.   In my devil's advocate 
> role, I believe the latter is irresponsible.  If DNSEXT says 
> "don't do that and, if you do, it is not our problem", that 
> ultimately becomes a sign of IETF being out of touch with 
> operational reality.

Well, I guess I should have been a little less glib.  But let me try
to explain more clearly.

If you are a zone operator, and you want (1) to have a number of
things tightly packaged together and (2) not to require that the
software of at least your entire target audience be replaced, then you
need to come up with something rather more clever than the traditional
editing of an ASCII zone file by someone typing in vi.  

If I were responsible for designing this kind of software and the
operational practices to go along with it, I'd probably do something
like this:

1.  Decide what things have to be "bundled together".  

2.  Write a registry-registr[ar|ant] protocol that allowed for
preferences within the preference tolerance of (1) to be expressed.

3.  Write a set of database triggers that ensured that all the
relevant parts from (2) always get handled together during DNS-data
generation. 

4.  Use the output from (3) to generate the DNS data every time.

If someone is going to complain that this is way more complicated,
hard to do, has nasty side effects and needs a lot of development,
well, yes.  Sorry, no free lunches here. This is indeed a very
expensive lunch.  But one that, I think, is possible for zone
operators who want to support that level of flexibility.  

Will this solve the problems of everything always being consistent
across the zone cut, and of different cached TTLs on different RRs in
the same RRset?  No, of course not.  If you want to fix those issues,
you need a new protocol: they're limitations of DNS as it was
designed.  In particular, they're limitations arising from using the
same RRTYPE on both sides of the cut, and from having the TTL on the
RR as opposed to the RRset.  On the other hand, we've lived with the
breakage for this long, and DNS was only ever loosely consistent, so
I'm not sure that we've stumbled on a new problem.  I agree that there
are lots of people who don't _like_ the way DNS works, or think it
unintuitive.  (Depending on my mood, I might count as one of those
people!)  But I don't believe we can apply enough paste and paper to
the protocol to make those features unsurprising to everyone who
operates at layer 9.

> Again playing devil's advocate, I suggest that "I/we don't like 
> this, therefore it maybe requires DNS2" is spurious.  

I'm not making any such argument.  I'm suggesting that the _whole
reason_ we're hanging IDNA on the side of DNS is to avoid a
requirement for the replacement of all (or even a large percentage) of
the resolvers on the Internet.  If we say, "It'll work for all the
existing resolvers, but you need a bunch of special software for it to
work right, and for people who don't upgrade it won't really work at
all," we might as well just admit that we're breaking stuff.

If we're going to break major things anyway, it seems like an
opportunity to ask what it is we _really_ want, and thereby get out
from under a number of the constraints that have already made this
whole effort fairly awkward.  For instance, why not just introduce a
unicode-based resolution protocol on a completely new port, and use
the "legacy" DNS to provide some sort of transition support for the
poor, lame systems out there that can't talk to the DNSng?  Dual-stack
DNS, as it were.  

If the argument is that this requires far too much upgrading
everywhere to be useful, I can only reply that today, requiring a new
RRTYPE for this to work at all is going to have the same effect.  We
are not, alas, in the era where the unknown RRTYPE is handled properly
on all systems.  It's a pity that after all this time, it isn't, but
that's the world we live in.

> one for permanent aliases within a given zone.  And, 
> incidentally, unless I don't understand your terminology, 
> whether a zone is "delegation-centric" either has nothing to do 
> with it or the zones of interest have exactly that property, 
> with a cluster of names consisting precisely of delegation 
> records at one node and and one or more alias nodes pointing at 
> it.

Hang on.  DNAME will work just fine for aliasing all the labels
underneath a label.  If one wants to support A and AAAA records at
that label too (and I really do think the right answer there is,
"don't," but I know others think differently), then the
database-founded approach that I sketched above will also work just
fine.  It's a bunch of additional entries in a zone, sure, but so
what?  IDNA is expensive for operators of such zones.  If you don't
want the additional expense, don't offer the service; if the service
is valuable to people, I presume they're willing to pay for it.  If
the argument is that you have to be able to support any random RRTYPE
at the same nodename as the one to be aliased, then you have a
problem.  That's just a lousy way to run delegation-centric zones
(like TLDs) _today_, and you shouldn't do it.  It leads to exactly
this sort of problem.  So even though it's possible, it's a bad idea.

A 

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