Delegating /24's from a /19

Edward Lewis Ed.Lewis at neustar.biz
Wed Mar 16 21:27:05 UTC 2005


At 20:22 -0800 3/15/05, Owen DeLong wrote:

>.... I'm not sure what you mean by "sideways delegations".  It is
>perfectly acceptable, for example, for:
>
>a.root-servers.net returns 16.172.in-addr.arpa. IN NS ns1.arin.net.
>ns1.arin.net returns 124.16.172.in-addr.apra. IN NS ns1.foobar.com.
>ns1.foobar.com. returns 124.16.172.in-addr.arpa. IN NS ns1.subsidiary.com.
>ns1.subsidiary.com. returns 5.124.16.172.in-addr.arpa. IN PTR 
>foo.subsidiary.com.
>
>This does work.  This is what is being proposed.

I'm afraid that above is not an accurate or workable sequence of events.

Here is what happens *today* when a "fresh" copy of named seeks a 
"reverse map."  First the disclaimer - I'm using named 9.3.1, not all 
iterating resolvers have the same strategy.  I'm omitting repeated 
queries, as well as queries for AAAA records and retranmissions 
because of FORMERR.  Also, if you start the server, run the query, 
stop the server and repeat (with an empty cache), the next result may 
vary as zones held vary be server.

Note too that this is from a fresh (empty) cache.  Some queries are 
not needed when the cache is populated.  It is not always as bad as I 
am illustrating - but it's easiest to visualize from the "0" state.

1. I ask a root-server for "162.57.173.209.in-addr.arpa./PTR".  The 
response is a referral to the servers for 209.in-addr.arpa and I am 
told there are 7 of them.

2. I ask another root-server for the address of each of the 7 name 
servers.  This means 7 new queries (14 w/AAAA's) directed to this 
second root server.  Note that in this example, all 7 name servers 
are in the .net domain.

3. I ask the .net name servers the same questions as in #2.  From 
this I get some "hybrid" answers - referrals enriched with answers - 
for most of the 7 name servers.  I call these hybrids because, if you 
adhere strictly to the DNS protocol specifications, referrals are 
what you should get.  The addition of the answer records to the 
referrals is a crutch to help the Internet run more smoothly.  (For 
this we should thank Verisign engineers.)

4. The query in step 1 is issued to one of the name servers with a 
hybrid answer at this point.  The reply received in this "step" is a 
referral to the servers for 57.173.209.in-addr.arpa, served up by 
four machines in neustar.com.

5. BIND continues seeking the glue for the name servers w/o hybrid 
answers in step 3.  BIND does this to have these name servers 
available for further querying, but is not necessary for the 
immediate question.  (This is done in parallel too - to avoid 
unnecessary latency.)

6. Armed with new name servers in step 4, a query for each's address 
is sent to another root server, which results in referrals to the 
servers for .com.

7. The .com servers also give the same hybrid answers (.com and .net 
are on the same machines) for the 4 name servers.

8. The original query is then issued to one of the servers whose 
address was obtained in step 7.  The result of this is what we wanted 
all along.

9. BIND may continue seeking addresses for other servers after 
returning the answer, filling out its cache.

Why bother to detail all this?  It's important to realize that the 
real iteration is done only in steps 1, 4, and 8.  In step 1 I am 
being told who to ask.  In step 4 I am also being told who to ask. 
The rest of the time I am trying to find out "where to ask".  Steps 
2,3,5 get me the addresses for the question in step 4.  Steps 6,7,9 
get the addresses for the question in step 8.

So - going back to the comment above:

>a.root-servers.net returns 16.172.in-addr.arpa. IN NS ns1.arin.net.

The root-servers do not return NS records, the refer the querier to 
one of the /8 zones.  (Note that not all root servers have the same 
zones, some might refer the querier to the in-addr.arpa. zone.)

>ns1.arin.net returns 124.16.172.in-addr.apra. IN NS ns1.foobar.com.
>ns1.foobar.com. returns 124.16.172.in-addr.arpa. IN NS ns1.subsidiary.com.

If the above two "situations" happened, then there's a violation of 
the database coherency principle that DNS tries hard (split-brain 
aside) to uphold.  In the global DNS, no matter where you ask 
question, you should get the same answer.

I.e.,

dig @ns1.arin.net 124.16.172.in-addr.arpa. IN NS

and

dig @ns1.foobar.com 124.16.172.in-addr.apra. IN NS

had better return the same NS RRSet.

So, I don't think the above is workable or even realistic.

>>  	Thirdly I'm sick and tired of having to debug stupid
>>  	schemes ISP's come up with to try to avoid SWIPing the
>>  	nameservers in situations like this.  They don't work
>>  	or they don't meet the customers expectations (i.e.
>>  	they have a /24 and should just be able to use x.y.z.in-addr.arpa
>>  	and have it work reliably).
>>
>So don't debug them.  As long as ARIN has all of the /24s within the /19
>pointing as NS records to the nameserver which contains the partially
>populated /16 zone file (or which secondaries each of the relevant /24 zones
>from their true owners), things work just fine.  Nothing really to debug.

I think the above two paragraphs are on the same side of the page.

>>  	Delegation is the DNS is strictly hierachical.
>>
>I don't see where the above breaks this.

It's the incoherency in your example that is the breakage.

>>  	You either SWIP the new servers or you slave the zones
>>  	from the customer.  In both cases you are following the
>>  	delegation heirarchy.  Note even if you slave the zones
>>  	you still have to ensure the delegation is correct.
>>
>I guess we will have to agree to disagree on this.  I will point out that
>the above solution is working in a number of networks without problem.
>Sure, if you screw it up, it doesn't work.  That's true of DNS generally.

If the delegation from the /8 zone is to the /24 level (as opposed to 
the /16 level) there are three options for an ISP to "transfer" the 
delegation to the customer.

1) Send a reassign-detailed or reallocate template (in ARIN lingo) 
for the space to the RIR.  Then the next set of DNS zone files 
generated will delegate to the customer's name servers.

2) Use DNAME, RFC 2672.  Good luck.

(http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.html)

3) Use RFC 2317.  "I encourage my competitors to operate this way."

'Course, the ISP is free to have the customer just update the ISP's 
name servers, whether by dynamic update or be zone transfers from 
hidden masters.

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

Achieving total enlightenment has taught me that ignorance is bliss.



More information about the NANOG mailing list