[dns-wg] TLD delegation trade-offs

Since this looks like the beginning of a new thread on this discussion, 
it's only fair the Subject: header gets changed....

On Jun 6, 2005, at 22:00, Edward Lewis wrote:

> What I find interesting is the trade-off of:
>
> The gain in packet compression by using similar names plus the 
> operational advantage of streamlining the names
>
> vs
>
> The gain by spreading name server names under other TLDs plus the 
> logging convenience of only needing one PTR record per address

Ed, I'm not sure I understand the second part of your trade-off. The 
benefits of better label compression and streamlined names seem clear 
enough. Spreading name server names under other TLDs appears unwise: 
there's an increased likelihood of not getting all the glue in a 
referral response with that approach. Or have I missed something? I 
note Neustar doesn't spread the TLD NS RRsets for .biz and .us like 
that. :-) And as for reverse lookups, I doubt anybody or anything cares 
about what name (singular) should be returned for the address of some 
TLD server.  The operator of that server will care of course, but why 
would anyone or anything else even need to care?

> 1) Compression to insert more name servers or more glue records into a 
> response is an advantage that I think is becoming outdated.

With EDNS0 out there, I tend to agree. But there are lots of name 
servers deployed that don't and won't support EDNS0. And even if EDNS0 
was ubiquitous, I'd prefer to see NS RRsets use a clean set of target 
names. It's prettier. And it reduces the protocol overheads: fewer CPU 
cycles encoding/decoding DNS packets as well as saving precious bytes 
we're going to need for DNSSEC RRtypes. :-) Even with EDNS0. :-(

> 3) I would think that having servers listed under other TLDs (as we 
> are looking at a ccTLD here) would be a good thing.  Just for the fact 
> that we are spreading the servers about (in DNS, not just topology).  
> In addition, these servers don't count against the glue space hit in 
> the response.

Could you please expand on this Ed? There are things I simply do not 
understand here. What's gained by spreading the hostnames for 8 (say) 
name servers for some TLD across .tld0, .tld1, ... .tld7? And how does 
the extra space needed for these names not "count against the glue 
space hit" in a referral?

> 4) Multiple name per address is one of those topics that gets bashed 
> back and forth.  At times we find it distasteful to have multiple PTR 
> records in a set, for instance, this makes traceroutes and logs list 
> potentially "wrong" names.  Other times we are reminded that it is 
> perfectly natural to allow more than one PTR record in a set.  Maybe 
> this is a "it's good for servers but not good for routers" situation.

Hmm. Nobody mentioned PTR records in this discussion. I'm struggling to 
see how this matters. Is there a name server implementation that does 
reverse lookups of the IP addresses in a referral, compares them with 
the hostnames in the NS RRset and gets upset if there's a mismatch?

> The part of the trade-off I haven't addressed is:
>
> The gain by using unique name server names for each delegation
>
> vs
>
> The need for extra IP addresses in light of a one name per address 
> policy

This confuses me too Ed. AFAICT there is no one name per address 
policy. Even if this was the case for TLD delegations, we'd still only 
be talking about wasting around 4000 IPv4 addresses, assuming each TLD 
has around 20 NS records. There are plenty of far more blatant examples 
of wasteful usage of IPv4 address space: the /8s that Stanford and MIT 
have for instance.

> Nevertheless, what I've debated above doesn't seem to be the point of 
> the document.  It seems the document is presenting discomfort with the 
> response.

I'm not sure that's right either. I read Olivier's document as an 
abridged history of what happened and where things stand today. People 
are of course welcome to interpret that document in whatever way best 
suits their standpoint. The questions about transparency and process at 
IANA remain unanswered though Doug has promised to respond to them. It 
looks like these questions won't go away until they are answered. IMO, 
it would be better to see them answered here instead of in a more 
formal setting such as an ICANN meeting.