From owner-nanog@merit.edu Tue Mar 15 14:12:12 2005 Date: Tue, 15 Mar 2005 15:12:10 -0500 From: Robert Blayzor <rblayzor@inoc.net> To: alex@pilosoft.com Cc: Mike Sawicki <fifi@HAX.ORG>, nanog@merit.edu Subject: Re: Delegating /24's from a /19
alex@pilosoft.com wrote:
Either by doing DNS delegation on the zone boundary or by SWIP'ing the space to the other company.
You can SWIP it yes, but that won't help DNS on small blocks like /24's.
It is very easy to do DNS delegation, say if you have 128.0.0.0/19, and you want to delegate 128.0.1.0/24, in your zone file for 0.128.in-addr.arpa zone put
1 IN NS ns1.othercompany.com 1 IN NS ns2.othercompany.com
The only way it will work is to use RFC2317 or slave the zones from the other name server. Because he does not have the entire /16 you can't just delegate like that.
OK, what am I missing? *ASSUMPTION*: The holder of the /16 _has_ delegated rDNS for the 32 /24s to the /19 owner. The /19 owner can, on it's nameserver, run an "authoritative" zone for the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing back to the rDNS nameserver of the /16 owner. "He who" queries from the outside world will work their way down from the .arpa zone, to the X.W.in-addr.arpa zone, get referred to the nameserver at "thiscompany", and get referred to the NS listed for Y.X.W.in-addr.arpa. which will resolve Z.Y.X.W.in-addr.arpa. "He who" queries the /19 owner nameserver directly for a Y.X.W.in-addr.arpa address that lies within the /19 owner's addresses will get answered by that nameserver, *or* be referred to the client's server. If they ask for something *outside* the /19 owner's space, the wildcard -- referring to the 'upstream' (the /16 owner) nameserver kicks in. _AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it pointing back to the 'parent' nameserver, this seems to work just fine. Admittedly, if the upstream block owner changes the _name_ of it's nameserver(s), the 'delegated to' nameserver requires manual tweaking, but, realistically, "how often" does _that_ happen?
In article <200503152040.j2FKe8p8001524@host122.r-bonomi.com> you write:
From owner-nanog@merit.edu Tue Mar 15 14:12:12 2005 Date: Tue, 15 Mar 2005 15:12:10 -0500 From: Robert Blayzor <rblayzor@inoc.net> To: alex@pilosoft.com Cc: Mike Sawicki <fifi@HAX.ORG>, nanog@merit.edu Subject: Re: Delegating /24's from a /19
alex@pilosoft.com wrote:
Either by doing DNS delegation on the zone boundary or by SWIP'ing the space to the other company.
You can SWIP it yes, but that won't help DNS on small blocks like /24's.
It is very easy to do DNS delegation, say if you have 128.0.0.0/19, and you want to delegate 128.0.1.0/24, in your zone file for 0.128.in-addr.arpa zone put
1 IN NS ns1.othercompany.com 1 IN NS ns2.othercompany.com
The only way it will work is to use RFC2317 or slave the zones from the other name server. Because he does not have the entire /16 you can't just delegate like that.
OK, what am I missing?
*ASSUMPTION*: The holder of the /16 _has_ delegated rDNS for the 32 /24s to the /19 owner.
The /19 owner can, on it's nameserver, run an "authoritative" zone for the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing back to the rDNS nameserver of the /16 owner.
"He who" queries from the outside world will work their way down from the .arpa zone, to the X.W.in-addr.arpa zone, get referred to the nameserver at "thiscompany", and get referred to the NS listed for Y.X.W.in-addr.arpa. which will resolve Z.Y.X.W.in-addr.arpa.
"He who" queries the /19 owner nameserver directly for a Y.X.W.in-addr.arpa address that lies within the /19 owner's addresses will get answered by that nameserver, *or* be referred to the client's server. If they ask for something *outside* the /19 owner's space, the wildcard -- referring to the 'upstream' (the /16 owner) nameserver kicks in.
_AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it pointing back to the 'parent' nameserver, this seems to work just fine. Admittedly, if the upstream block owner changes the _name_ of it's nameserver(s), the 'delegated to' nameserver requires manual tweaking, but, realistically, "how often" does _that_ happen?
This is the worst piece of "advice" I have ever seen. SWIP the nameservers. The OP customers will be expecting to be able to use the X.Y.Z.IN-ADDR.ARPA as the zone name. It also reduces the number of nameservers involved. It is also the clean solution. The RIR's are all setup to handle this. For those advising RFC 2317 please read the first sentence of the introduction. RFC 2317 was NOT written to cover this situation. Go put it back in the filing cabinet and bring it out when you have a situation that it does cover (/25-/32 sub-delegation). Mark
alex@pilosoft.com wrote:
Either by doing DNS delegation on the zone boundary or by SWIP'ing the space to the other company.
You can SWIP it yes, but that won't help DNS on small blocks like /24's.
SWIPping the large block won't help. SWIPping the /24s will.
OK, what am I missing?
*ASSUMPTION*: The holder of the /16 _has_ delegated rDNS for the 32 /24s to the /19 owner.
The /19 owner can, on it's nameserver, run an "authoritative" zone for the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing back to the rDNS nameserver of the /16 owner.
Absolutely.
[SNIP DNS Resolution 101 tutorial]
_AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it pointing back to the 'parent' nameserver, this seems to work just fine. Admittedly, if the upstream block owner changes the _name_ of it's nameserver(s), the 'delegated to' nameserver requires manual tweaking, but, realistically, "how often" does _that_ happen?
Seems perfectly reasonable to me.
This is the worst piece of "advice" I have ever seen.
Um, why?
SWIP the nameservers. The OP customers will be expecting to be able to use the X.Y.Z.IN-ADDR.ARPA as the zone name. It also reduces the number of nameservers involved. It is also the clean solution. The RIR's are all setup to handle this.
That's another alternative, but, not the only one, and, in many cases, not the most effective.
For those advising RFC 2317 please read the first sentence of the introduction. RFC 2317 was NOT written to cover this situation. Go put it back in the filing cabinet and bring it out when you have a situation that it does cover (/25-/32 sub-delegation).
While it doesn't inherently cover it, I see no reason it couldn't be used, although it seems unnecessarily complicated for the task. Using a /16 zone with a wildcard backreference seems to me the cleanest solution, with SWIP coming in a close second. In reality, the wildcard backreference is only needed _IF_ the nameserver is a resolver or forwarder, otherwise, it's useless anyway, as the nameserver in question should not be receiving queries outside of the space delegated to it. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
In article <2147483647.1110902129@imac-en0.delong.sj.ca.us> you write:
--==========D714B409A8D84E671065========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
alex@pilosoft.com wrote:
Either by doing DNS delegation on the zone boundary or by SWIP'ing the space to the other company.
You can SWIP it yes, but that won't help DNS on small blocks like = /24's.
SWIPping the large block won't help. SWIPping the /24s will.
OK, what am I missing?
*ASSUMPTION*: The holder of the /16 _has_ delegated rDNS for the 32 /24s to the /19 owner.
The /19 owner can, on it's nameserver, run an "authoritative" zone for the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing back to the rDNS nameserver of the /16 owner.
Absolutely.
[SNIP DNS Resolution 101 tutorial]
_AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it pointing back to the 'parent' nameserver, this seems to work just fine. Admittedly, if the upstream block owner changes the _name_ of it's nameserver(s), the 'delegated to' nameserver requires manual tweaking, but, realistically, "how often" does _that_ happen?
Seems perfectly reasonable to me.
This is the worst piece of "advice" I have ever seen.
Um, why?
Firstly he does NOT have authority for the /16 reverse. Lots of latent problems there. Secondly sideways delegations don't work. 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). Delegation is the DNS is strictly hierachical. 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. Mark
SWIP the nameservers. The OP customers will be expecting to be able to use the X.Y.Z.IN-ADDR.ARPA as the zone name. It also reduces the number of nameservers involved. It is also the clean solution. The RIR's are all setup to handle this.
That's another alternative, but, not the only one, and, in many cases, not the most effective.
For those advising RFC 2317 please read the first sentence of the introduction. RFC 2317 was NOT written to cover this situation. Go put it back in the filing cabinet and bring it out when you have a situation that it does cover (/25-/32 sub-delegation).
While it doesn't inherently cover it, I see no reason it couldn't be used, although it seems unnecessarily complicated for the task. Using a /16 zone with a wildcard backreference seems to me the cleanest solution, with SWIP coming in a close second. In reality, the wildcard backreference is only needed _IF_ the nameserver is a resolver or forwarder, otherwise, it's useless anyway, as the nameserver in question should not be receiving queries outside of the space delegated to it.
Owen
--=20 If it wasn't crypto-signed, it probably didn't come from me.
--==========D714B409A8D84E671065========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFCN3X1n5zKWQ/iqj0RAja3AKCMu6gl3QfPOUVlNRfNS2oulMwWHQCfeN9g 0aDxJs9OXpzyVVqavnPNJ4s= =Ja+n -----END PGP SIGNATURE-----
--==========D714B409A8D84E671065==========--
...snip...
Um, why?
Firstly he does NOT have authority for the /16 reverse. Lots of latent problems there.
Nor is he claiming it. Nowhere on the internet is there anything saying that the entire /16 should be looked up against his nameserver. No reference should exist pointing to his nameserver as authoritative for the /16. The convenience of having a zone file that is based on a /16 that he owns part of does not create authority out of thin air, nor does it make any meaningful claim to authority except to a system which (mistakenly) attempts to use those nameservers as resolvers. Yes, if you are going to do this, it is a prerequisite that your nameserver _NOT_ be anyone's resolver.
Secondly sideways delegations don't work.
Huh? 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.
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.
Delegation is the DNS is strictly hierachical.
I don't see where the above breaks this.
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. Owen P.S. Learn to trim quotations. -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
Um, why?
Firstly he does NOT have authority for the /16 reverse. Lots of latent problems there.
Nor is he claiming it. Nowhere on the internet is there anything saying that the entire /16 should be looked up against his nameserver. No=20 reference should exist pointing to his nameserver as authoritative for the /16. The convenience of having a zone file that is based on a /16 that he owns part of does not create authority out of thin air, nor does it make any meaningful claim to authority except to a system which (mistakenly) = attempts to use those nameservers as resolvers. Yes, if you are going to do this, = it is a prerequisite that your nameserver _NOT_ be anyone's resolver.
Secondly sideways delegations don't work.
Huh? 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=20 foo.subsidiary.com.
Actually it isn't. Nameservers can and do detect this as it looks like a classic lame delegation. It also a sideways delgation, the zone depth didn't impove between ns1.foobar.com and ns1.subsidiary.com.
This does work. This is what is being proposed.
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.
Well when you have a bug report saying that your nameserver doesn't work because someone tried to do a sideways delegation you have to go in there and show what is broken. This is not expected to work.
Delegation is the DNS is strictly hierachical.
I don't see where the above breaks this.
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.
Owen
P.S. Learn to trim quotations.
--=20 If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
--==========63ACF217CA8F895998F9========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin)
iD8DBQFCN7SEn5zKWQ/iqj0RAtK5AJ4pagTb5Ei+uMqGf9ob9RfSHJFWnQCghs2K Ltjk1dF5GCdssFNx1KiczoQ= =Se+y -----END PGP SIGNATURE-----
--==========63ACF217CA8F895998F9==========--
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
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.
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."
Note: DNAME is equivalent to RFC 2317. In both cases this will break the customers expectation that they can just use x.y.z.in-addr.arpa for the PTR records. Note for reliable local reverse lookups when the external link is down they will need to slave the ISP's x.y.z.in-addr.arpa zone and well as manage the zone the CNAME / DNAME maps to. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
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
At 23:54 -0800 3/16/05, Owen DeLong wrote:
Ed's comments:
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.
I was going to respond with a really long tutorial on reading DNS responses, but I figure this is not the forum. In short, yes, the responses are as you say, but to really understand this you have to dig deeper into the protocol details to see the difference between a referral and an answer.
Perhaps, but, as long as the referrals consistently point to an end and not a loop, in general, it seems to work.
In the IPv4 reverse space, you only have the following zones... root, arpa, in-addr.arpa, /8, maybe the /16, and /24 In operations, four or five referral possibilities, tops. DNAME and CNAME kind of change this, but they aren't "referrals" in the DNS dictionary, they rewrite the query. In theory, DNS referrals only loop if the there is a break in the protocol. DNS is a tree, which means "there's only one path between any two points." If you turn the tree into a bush, you've broken it.
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.
If that's the case, I don't know why this thread is being continued. I responded under the presumption you were about to propose some other way to do this. From your earlier message you mentioned "sideways delegations" and "this is what is proposed." Before "proposing" a change to DNS, the details of the protocol have to be clearly understood. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Robert Bonomi wrote:
OK, what am I missing?
*ASSUMPTION*: The holder of the /16 _has_ delegated rDNS for the 32 /24s to the /19 owner.
The /19 owner can, on it's nameserver, run an "authoritative" zone for the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing back to the rDNS nameserver of the /16 owner.
"He who" queries from the outside world will work their way down from the .arpa zone, to the X.W.in-addr.arpa zone, get referred to the nameserver at "thiscompany", and get referred to the NS listed for Y.X.W.in-addr.arpa. which will resolve Z.Y.X.W.in-addr.arpa.
I'm not as versed in DNS protocols as I was in the past (which then didn't compare to some on this list), but won't this cause tons of "lame server" messages that could be eliminated by proper SWIPping? pt
participants (5)
-
Edward Lewis -
Mark Andrews -
Owen DeLong -
Pete Templin -
Robert Bonomi