Delegating /24's from a /19

Thu Mar 17 07:54:15 UTC 2005

> I'm afraid that above is not an accurate or workable sequence of events.
>
Not accurate in the sense that I left out some of the queries and left
it as a summary of the relevant ones, however...

[...bind 9.3.1...] snip

> 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.
>
And their host names.

> 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.
>
Right... However, pretty quickly, your cache gets these and, unless you
are patholigically stupid about restarting your nameservers often, this
is almost never necessary.

> 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.)
>
Except that the additional info was done long before Verisign was in the
picture.  Not sure why you think Verisign should get credit.

Anyway, again, this query is almost never necessary.

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

> 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.)
>
Right, but, again, this happens once in a blue moon.

> 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.
>
Again, if you actually have to do this.  99+% of the time, you will not.

> 7. The .com servers also give the same hybrid answers (.com and .net are
> on the same machines) for the 4 name servers.
>
And, as such, you probably already have these answers.

> 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.
>
Uh, right, but, steps 2,3,5 and 6,7,9 are almost always unnecessary as they
get put in the cache and pretty much left there for anything at all
active pretty quickly.

> 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.)
>
OK... Fine... You're right, it returns more like

172.in-addr.arpa. IN NS ns1.arin.net.

But I don't see this as a significant distinction, since, ARIN will still
return the next line the same.  They are, btw, NS records...

dig @a.root-servers.net 162.57.173.209.in-addr.arpa. PTR

; <<>> DiG 9.2.3 <<>> @a.root-servers.net 162.57.173.209.in-addr.arpa. PTR
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24751
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0

;; QUESTION SECTION:
;162.57.173.209.in-addr.arpa.   IN      PTR

;; AUTHORITY SECTION:
209.in-addr.arpa.       86400   IN      NS      chia.ARIN.NET.
209.in-addr.arpa.       86400   IN      NS      dill.ARIN.NET.
209.in-addr.arpa.       86400   IN      NS      BASIL.ARIN.NET.
209.in-addr.arpa.       86400   IN      NS      henna.ARIN.NET.
209.in-addr.arpa.       86400   IN      NS      indigo.ARIN.NET.
209.in-addr.arpa.       86400   IN      NS      epazote.ARIN.NET.
209.in-addr.arpa.       86400   IN      NS      figwort.ARIN.NET.

;; Query time: 102 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Wed Mar 16 23:37:33 2005
;; MSG SIZE  rcvd: 196

>> 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.
>
If that were true, then, there would be no such thing as recursive resolvers
and all clients would have to have recursive libraries.  If I ask a 
recursive
resolver for a foreign A record, I usually get an A record in response.
If I ask a non-recursive server, I usually get NS records in response.
This is no less consistent than that scenario.

> 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.
>
In an ideal world, that's preferable, but, in this scenario, I have
yet to see anything break when they don't, so long as ns1.foobar.com is
within the RR Set returned by ns1.arin.net.

> So, I don't think the above is workable or even realistic.
>
It may not be RFC-Pretty, but, I can guarantee you it does work in the real
world (RFC 2317 subdelegations downstream notwithstanding, I need to look
into that a bit more).

>>>  	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.
>
Perhaps, but, as long as the referrals consistently point to an
end and not a loop, in general, it seems to work.

> 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.
>
Obviously, in most circumstances, I'd agree that this is preferred.

> 2) Use DNAME, RFC 2672.  Good luck.
>
> (http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.html)
>
Right.

> 3) Use RFC 2317.  "I encourage my competitors to operate this way."
>
Very much not pretty with /24 and shorter prefixes.

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

The zone-transfer based solution would be my second choice.  The above
delegation-based solution (NS records) would be my third with 2317 being
fourth and 2672 being last.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050316/d47a4624/attachment.sig>