[dns-wg] TLD delegation trade-offs

At 0:50 +0000 6/7/05, bmanning at vacation.karoshi.com wrote:
>>  of wasteful usage of IPv4 address space: the /8s that Stanford and MIT
>>  have for instance.
>
>	er... MIT & MERIT... stanford returned theirs years ago...
>
>	now if i understood Ed, both he and you are tangentially
>	arguing for in-baliwick glue.  why was this considered such
>	bad practice last decade, but now seems to be not only
>	prefered but the only choice for right-thinking people?

Perhaps looking at the workings of the tools we have today.

I don't understand why glue in the reverse map is considered any more 
of a hit than glue in the forward tree.  It is one less issue in the 
reverse map, but it has cost us by requiring crutches placed in the 
forward tree.

The crutch I refer to I have written about in many places - the 
crutch is the hybrid "cache response/referral" you get in response, 
for example to this query:

    dig @f.gtld-servers.com figwort.arin.net a

(Meant as an example only.  Look at the flags, no RA, no AA, but 
ANCOUNT > 0 and the rest of the message looks like a referral.)

This crutch will have to be removed for DNSSEC (or DNSSEC will have 
to bend around it).  When the crutch is removed, antique name servers 
will start to fall over.

Perhaps the above is worded too strongly, I mean it as a potential 
reason why there is a call for in-bailiwick glue.

And maybe RFC 2181's introduction of credibility as a means to stop 
cache poisoning plays a role, as well as BIND's search for the 
authoritative addresses of name servers in spite of having the glue 
addresses.

BTW - This presentation at NANOG 33 gives another angle on this.

   http://www.nanog.org/mtg-0501/minda.html

I believe that the similar presentations have been made at IETF$last 
and RIPE50.

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

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