[dns-wg] TLD delegation trade-offs

There are quite a few message to respond in the thread, I'll stick to 
questions indicating that my comments need clarification...

At 0:45 +0100 6/7/05, Jim Reid wrote:
>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?

Let's say my TLD is "tld", that my two options for name server sets 
are {a.nic.tld, b.nic.tld} and {a.nic.example, b.nic.tld}, and the 
query is for "www.jim.tld A".

With option 1, if the query goes to the root and the iterative 
resolver is BIND, the queries for the addresses of a.nic.tld and 
b.nic.tld will follow.  If there is a problem with the tld zone, and 
perhaps the glue at the root isn't completely right, we will have 
problems.  With option 2, a problem with the tld zone isn't an issue 
if the copy of the zone on a.nic.example is in good enough condition. 
In summary, by using a different TLD, there's one more place to get 
the address of a name server.  It could be that the fault that makes 
this a true advantage has almost no chance of happening in isolation.

My supposition that spreading name servers among domains is based on 
watching how BIND does its resolution (via packet sniffing).  I don't 
have access to other (popular) implementations to see how they go 
about their business.

As you descend the tree, it's clearer than spreading name servers 
among domains (even different tlds) has a benefit.  Because there are 
more moving parts as you descend the tree, there's more chance 
something goes wrong, so you want to build in resiliency.  I can see 
that in the case of TLDs, there really aren't many options in case of 
a some failures.  And, as far as what I call glue space savings isn't 
seen in the root zone as all name servers are in the root domain.

Given that BIND chases the authoritative version of the glue it 
receives, and that there are a lot of BIND name servers (if not a 
majority), I think there's a gain in spreading the name servers over 
different TLDs.

NeuStar's name servers are all in the same TLD.  Internally, well, we 
just haven't seen a justification for trying "something new."  It's 
like this, it works as is, its an industry norm, and tinkering with 
operational systems should not be taken lightly.

I'd say that I have a hunch that there is a gain to mixing name 
servers over TLDs, and this is based on my thoughts about how 
enterprises should think.  Hunches are not always right.  (Recall I'm 
writing as an individual, not a company representative.)

As far as reverse lookups - I think there are a lot of folks who do 
care.  I've seen the issue more with routing discussions, traceroute 
is often cited as a tool that cares what it sees in the PTR record. 
Security analysis too - they rely on logging data.

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

I wasn't even considering EDNS0.  I was thinking anycast.

EDNS0 is good, but some non-DNS security devices still don't 
understand it.  That needs fixing, and is out of scope for the thread 
and wg.

I don't see how CPU cycles are reduced by using "a clean set" of 
names.  A label pointer reference is the same, regardless of where it 
goes.


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

Going back to my fictional tld above and the two options, here is 
what the root can minimally send back:

option 1

answer:
authority:   tld            NS   a.nic.tld
              tld            NS   b.nic.tld
additional:  a.nic.tld      A    1.1.1.1
              b.nic.tld      AAAA ::1

option 2

answer:
authority:   tld            NS   a.nic.example
              tld            NS   b.nic.tld
additional:  b.nic.tld      AAAA ::1

The reason I say these are minimal is that any query for the records 
in the additional section would wind up with the same answer.  In 
option 2, the next query to the root would be for "a.nic.example A" 
(and AAAA) from a BIND resolver.  The response to that would be a 
referral to the example TLD servers.

In option 2, the out-of-baliwick server does not count the needed 
glue.  Of course, in reality, the root server is probably responding 
with it, as the server is under the root domain.

Perhaps I am seeing a gain that is possible, but is not realized in 
practice because of the tools we are using and are used to.

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

I thought that the main problem was that IANA wasn't permitting 
multiple hosts to point to one IP address.  Back in prehistoric 
times, this restriction was also in place in .com and .net.  I ran 
into this - and the technical glitch that caused the restriction was 
that the registry software couldn't support multiple PTRs in a set. 
My supposition was that this might have been the cause of concern 
with IANA - I can't imagine any other reason to be concerned.

Besides (potentially) faulty registry software, the main reason why 
multiple PTR records in a set are denigrated by some is that 
application software generally assumes a host has only one name.  (I 
think multiple PTRs are fine, I'm just relating the arguments levied 
against them.)

My experience with one dynamically updating DHCP server would treat 
the forward and reverse differently.  When it created a lease with a 
vanity name, it would add the vanity name to the forward, 
supplementing what was already there.  When updating the reverse, it 
deleted all previous records and out in the PTR with the vanity name. 
This is an application problem, not a DNS one.

The only time that the reverse of a name server has ever been called 
out is in some DNS checking packages.  I don't know why it's an 
issue, but DNS set ups were graded on that.

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

During the RIPE NCC presentation in the WG at RIPE 50, I thought the 
criticism was that the slave server names using unique addresses was 
considered wasteful and ironic that an RIR was doing this.  I thought 
that this was proposed in response to the "problems" with IANA as 
described in the draft.  It could be that my wires are crossed.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.