clueing in TLD registries for delegations to non-BIND servers
All, good to see nsd make progress (played with it a litte while ago, but tinydns continues to serve me best). I understand that nsd (as most non-BIND servers) returns SERVFAIL for questions for which it it does have neither authoritative nor non- authoritative data (i.e. it is lame) and that this behaviour is RFC- conformant and certainly best-practice for authoritative-only servers. Some TLD registries, however, make unreasonable demands regarding the behaviour of servers to which they delegate zones. Most notably the .fr and .it registries, which apparently demand that servers return a (non-authoritative!, in the case of .it) referral to the root servers when they are lame. These demands are highly questionable -to say the least- and are hard and sometimes impossible to follow for users of at least tinydns and nsd. I was wondering if RIPE or a group from the RIPE community might appeal to those registries and try to make them stop acting stupid. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC}
On Thu, Feb 06, 2003 at 06:42:45PM +0100, Stefan Paletta <stefanp@cabal1.com> wrote a message of 25 lines which said:
Some TLD registries, however, make unreasonable demands regarding the behaviour of servers to which they delegate zones. Most notably the .fr and .it registries, which apparently demand that servers return a (non-authoritative!, in the case of .it) referral to the root servers when they are lame.
I am not involved in the daily operations of the '.fr' registry but, AFAIK, the ZoneCheck tool (check it out yourself <URL:http://www.nic.fr/zonecheck/>) requires a referral only if your server claims to be recursive. Therefore, nsd, which is never recursive, or BIND9 with two views (one with recursion for local clients and one without for serving authoritative data to the outside) are OK. BIND8 is more problematic since the recursive flag is apparently global.
I was wondering if RIPE or a group from the RIPE community might appeal to those registries and try to make them stop acting stupid.
A new (completely new: rewritten from scratch) version of ZoneCheck is currently beta. Unlike ZoneCheck 1, the actual tests are configured in a separate configuration file so you can remove some tests without hacking the code. This will make policy adjustements much easier. Input from the community is welcome.
On Fri, 7 Feb 2003, Stephane Bortzmeyer wrote:
On Thu, Feb 06, 2003 at 06:42:45PM +0100, Stefan Paletta <stefanp@cabal1.com> wrote a message of 25 lines which said:
Some TLD registries, however, make unreasonable demands regarding the behaviour of servers to which they delegate zones. Most notably the .fr and .it registries, which apparently demand that servers return a (non-authoritative!, in the case of .it) referral to the root servers when they are lame.
You may wish to refer to the dnsop archives, and the 'Should a nameserver know about itself?' thread, starting at: http://www.cafax.se/dnsop/maillist/2001-05/msg00009.html ( I am not expressing an opinion of the RIPE NCC, just work I did at my previous employer )
I am not involved in the daily operations of the '.fr' registry but, AFAIK, the ZoneCheck tool (check it out yourself <URL:http://www.nic.fr/zonecheck/>) requires a referral only if your server claims to be recursive.
Is this 'recursive for the zone being delegated' (somewhat bad) or 'recursive' in general ? Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security
At 3:33 PM +0100 2003/02/07, Bruce Campbell wrote:
You may wish to refer to the dnsop archives, and the 'Should a nameserver know about itself?' thread, starting at:
http://www.cafax.se/dnsop/maillist/2001-05/msg00009.html
( I am not expressing an opinion of the RIPE NCC, just work I did at my previous employer )
I read through this entire thread. It doesn't seem to have anything to do with whether or not an authoritative-only server should respond with a referral to the root zone when asked a question that it is not authoritative for. So far, the best argument I've seen for returning anything else, is for returning a SERVFAIL, in <http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00530.html>. However, I am not yet convinced. IMO, if I ask a server a question and it gives me a root referral, then I know that name is not served by that machine. If it gives me a SERVFAIL instead, then I am left wondering just how b0rken it is, and whether or not it should be ignored for all future queries of any type or question. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
At 6:42 PM +0100 2003/02/06, Stefan Paletta wrote:
I understand that nsd (as most non-BIND servers) returns SERVFAIL for questions for which it it does have neither authoritative nor non- authoritative data (i.e. it is lame) and that this behaviour is RFC- conformant and certainly best-practice for authoritative-only servers.
Best practice? No, I would disagree most vehemently on that. If nsd is doing this, then I believe it needs to be fixed. Handing out a referral to the root zone is no more work than handing out SERVFAIL.
Some TLD registries, however, make unreasonable demands regarding the behaviour of servers to which they delegate zones.
Unreasonable? No, I consider this to be best practice.
These demands are highly questionable -to say the least- and are hard and sometimes impossible to follow for users of at least tinydns and nsd.
Hard for users of tinydns? Just what is required? Here's what the djbdns FAQ at <http://www.fefe.de/djbdns/> has to say: Tinydns does not answer at all when someone lamely delegates to it? Yes. You can add this line to your data file to simulate BIND behaviour: &::a.root-servers.net While I believe this to be b0rken behaviour, and I definitely ding djbdns for doing this by default, this is not what I would consider to be particularly onerous if you have jumped through all the other necessary hoops, incredibly poor documentation, and bizarre data file formats in order to get djbdns running. Now, for users of nsd, yes this is a serious problem. They are not given any choice. But then, nsd is not useful as a general-purpose authoritative nameserver -- it is designed as a root/TLD nameserver, and anyone who mis-uses or abuses it to try to serve as a general-purpose authoritative nameserver basically gets what they deserve.
I was wondering if RIPE or a group from the RIPE community might appeal to those registries and try to make them stop acting stupid.
I would appeal to the authors of nsd to fix this and to have nsd generate referrals by default. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Fri, 7 Feb 2003, Brad Knowles wrote:
At 6:42 PM +0100 2003/02/06, Stefan Paletta wrote:
I understand that nsd (as most non-BIND servers) returns SERVFAIL for questions for which it it does have neither authoritative nor non- authoritative data (i.e. it is lame) and that this behaviour is RFC- conformant and certainly best-practice for authoritative-only servers.
Best practice? No, I would disagree most vehemently on that. If nsd is doing this, then I believe it needs to be fixed. Handing out a referral to the root zone is no more work than handing out SERVFAIL.
nsd could be configured to either hand out a referral or send SERVFAIL. bind9 will reply with REFUSED if the hints file is missing and it is configured to be authoritative only. jakob
At 4:58 PM +0100 2003/02/07, Jakob Schlyter wrote:
nsd could be configured to either hand out a referral or send SERVFAIL.
It should be configured to hand out a referral.
bind9 will reply with REFUSED if the hints file is missing and it is configured to be authoritative only.
Are you sure? For which version of BIND 9? My understanding is that they had a pre-compiled list of the root servers built into the source code, and that this would be used to generate the initial "hints" zone, thus allowing you to avoid having this file. Indeed, I wouldn't be surprised at all if the built-in data over-rode the file, but maybe that's going too far. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Fri, 7 Feb 2003, Brad Knowles wrote:
At 4:58 PM +0100 2003/02/07, Jakob Schlyter wrote:
nsd could be configured to either hand out a referral or send SERVFAIL.
It should be configured to hand out a referral.
if you do not include a hints file in nsd's database, it will return SERVFAIL.
bind9 will reply with REFUSED if the hints file is missing and it is configured to be authoritative only.
Are you sure? For which version of BIND 9? My understanding is that they had a pre-compiled list of the root servers built into the source code, and that this would be used to generate the initial "hints" zone, thus allowing you to avoid having this file. Indeed, I wouldn't be surprised at all if the built-in data over-rode the file, but maybe that's going too far.
if you set up bind9 with a authoritative-only view it will return REFUSED. in a "normal" configuration, it will use pre-compiled root-hints. jakob
At 7:47 PM +0100 2003/02/07, Jakob Schlyter wrote:
if you do not include a hints file in nsd's database, it will return SERVFAIL.
Are you saying that it will hand out a referral if this information is configured into the database? If so, then I would be much less unhappy with the way it is working. Maybe this code isn't on by default, but it's much better than not being there at all.
if you set up bind9 with a authoritative-only view it will return REFUSED. in a "normal" configuration, it will use pre-compiled root-hints.
Right, but REFUSED != SERVFAIL. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
At 3:01 AM +0100 2003/02/08, Brad Knowles wrote:
if you set up bind9 with a authoritative-only view it will return REFUSED. in a "normal" configuration, it will use pre-compiled root-hints.
Right, but REFUSED != SERVFAIL.
Moreover, this isn't the default behaviour of BIND 9. You have to go out of your way to make this configuration choice. I'm okay with people choosing to configure their servers this way, but this isn't something that should be done by default. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Sat, 8 Feb 2003, Brad Knowles wrote:
At 7:47 PM +0100 2003/02/07, Jakob Schlyter wrote:
if you do not include a hints file in nsd's database, it will return SERVFAIL.
Actually (having burnt my fingers on this one), you really do not want to configure any zones into nsd (including '.') unless you are authoritative for those zones. Since nsd is (by design) an authoritative-only nameserver, any zones configured will be answered authoritatively.
Are you saying that it will hand out a referral if this information is configured into the database?
nsd will return authoritative NXDOMAIN with authority of '.' on unknown queries if '.' is configured. This is probably not what is wanted in most cases. Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security
At 11:33 PM +0100 2003/02/08, Bruce Campbell wrote:
if you do not include a hints file in nsd's database, it will return SERVFAIL.
Actually (having burnt my fingers on this one), you really do not want to configure any zones into nsd (including '.') unless you are authoritative for those zones. Since nsd is (by design) an authoritative-only nameserver, any zones configured will be answered authoritatively.
In which case, it is impossible to configure nsd to "do the right thing", even if this feature wasn't turned on by default. If you don't configure the root zone, then you get SERVFAIL instead. If you do, then you get bogus information. We need a third way, one that gives us the right answer. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
[please do not explicitly send copies of followups to me] Brad Knowles wrote/schrieb/scripsit:
In which case, it is impossible to configure nsd to "do the right thing", even if this feature wasn't turned on by default. If you don't configure the root zone, then you get SERVFAIL instead. If you do, then you get bogus information. We need a third way, one that gives us the right answer.
There is no One True Lame Delegation Answer. Servers have always re- sponded differently when a delegation was lame. For example, suppose I had configured the cabal1.net nameservers like: $ORIGIN cabal1.net. ; SOA yadda yadaa foobar NS k k A 193.0.14.129 ; address of k.root-servers.net Then, when a client had learned that k.cabal1.net at address 193.0.14.129 was supposed to know about foobar.cabal1.net, this nameserver, when asked for the address of foobar.cabal1.net, would respond with an authoritative referral to the net servers. The client would notice that this was a lame delegation and then throw away the information received, because it would be vulnerable to poisoning otherwise. Similarly, BIND servers usually have a root.cache file, even when they are not acting as recursive resolvers. As a consequence, under certain circumstances, all they could do when asked for information they did not have was to return their knowledge of the root servers. They would do this non-authoritatively because the root.cache information is not their authoritative knowledge. No matter if this is even an authorita- tive answer (i.e. the server had a local root zone configured) or not, the client will notice that the delegation is lame and then throw away the (possibly bogus) information. So, there is absolutely nothing magic about returning a referral to the roots. Many possible -- and correct -- responses to a lame delegation exist and one of them is to simply return SERVFAIL for lack of better knowledge. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC}
At 10:56 PM +0100 2003/02/09, Stefan Paletta wrote:
[please do not explicitly send copies of followups to me]
Roger.
There is no One True Lame Delegation Answer. Servers have always re- sponded differently when a delegation was lame.
Just because you got a query for a zone that you do not host does not mean that there is a lame delegation. It could very well be an issue of a mis-configured resolver or a mis-configured client nameserver, and have nothing to do with published delegation information.
Then, when a client had learned that k.cabal1.net at address 193.0.14.129 was supposed to know about foobar.cabal1.net, this nameserver, when asked for the address of foobar.cabal1.net, would respond with an authoritative referral to the net servers. The client would notice that this was a lame delegation and then throw away the information received, because it would be vulnerable to poisoning otherwise.
Correct.
Similarly, BIND servers usually have a root.cache file, even when they are not acting as recursive resolvers.
BIND 8 requires a root.cache file, BIND 9 does not. BIND 9 has an equivalent of a root.cache file built directly into the source code, and will use this built-in equivalent in the absence of a root.cache file.
As a consequence, under certain circumstances, all they could do when asked for information they did not have was to return their knowledge of the root servers.
Correct.
They would do this non-authoritatively because the root.cache information is not their authoritative knowledge.
Correct.
No matter if this is even an authorita- tive answer (i.e. the server had a local root zone configured) or not, the client will notice that the delegation is lame and then throw away the (possibly bogus) information.
Again, the query may not have been the result of a lame delegation.
So, there is absolutely nothing magic about returning a referral to the roots. Many possible -- and correct -- responses to a lame delegation exist and one of them is to simply return SERVFAIL for lack of better knowledge.
I disagree. I am willing to be convinced. However, I think this needs wider and more in-depth discussion over a longer period of time. When we get to a standards-track RFC that explicitly states this fact, and I can go back and review all of the public discussions on this topic, and I can sit down with people who were involved in the appropriate private discussions, I would be more likely to agree to this statement. But not yet. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On 08.02 23:33, Bruce Campbell wrote:
On Sat, 8 Feb 2003, Brad Knowles wrote:
At 7:47 PM +0100 2003/02/07, Jakob Schlyter wrote:
if you do not include a hints file in nsd's database, it will return SERVFAIL.
Actually (having burnt my fingers on this one), you really do not want to configure any zones into nsd (including '.') unless you are authoritative for those zones. Since nsd is (by design) an authoritative-only nameserver, any zones configured will be answered authoritatively.
Are you saying that it will hand out a referral if this information is configured into the database?
nsd will return authoritative NXDOMAIN with authority of '.' on unknown queries if '.' is configured. This is probably not what is wanted in most cases.
If you load a root zone into a name server and tell it to be authoritative for it (default in nsd) it serves that zone authoritatively. Anything else would be strange, wouldn't it? So if a TLD is not in that zone the only correct answer is an autoritative NXDOMAIN. (If you take a hints file, add a SOA record, and then tell NSD it is a root zone, the outcome is the same. How can the poor program know it is really a hints file with a SOA added and not a zone file? ;-() The next release of nsd (actually zonec) will require a special flag to allow compiling the '.' zone. Just another feeble attempt to prevent bullets in feet caused by the preconceptions that all name servers need a hints file to work. I hope it will be more successful than all the other "Do you really want to do this [y/n]?" questions. Imho non-recursing name servers should not answer anything they are not authoritative for. Such queries should not go to them and being extra helpful without knowing authoritative information is never good. This is why I always ask more than one person for directions especially if the first person I asked is very nice and helpful. It is better to admit one does not know. (RFC 1123 section 6.1.2.5 codifies this) Daniel
[please do not explicitly send copies of followups to me] Brad Knowles wrote/schrieb/scripsit:
Best practice? No, I would disagree most vehemently on that. If nsd is doing this, then I believe it needs to be fixed. Handing out a referral to the root zone is no more work than handing out SERVFAIL.
The ability to hand out referrals has an administrative overhead and is thus more prone to errors. The recent misconfiguration of NS.EU.NET is a good example for that. Most importantly, responding with a SERVFAIL is RFC compliant.
Now, for users of nsd, yes this is a serious problem. They are not given any choice. But then, nsd is not useful as a general-purpose authoritative nameserver -- it is designed as a root/TLD nameserver, and anyone who mis-uses or abuses it to try to serve as a general-purpose authoritative nameserver basically gets what they deserve.
Are you suggesting that different demands for conformance should be applied to root/TLD nameservers vs. others? There is btw. nothing in the announcements of and documentation for NSD to suggest that it might not be designed or fit for use as a general-purpose authoritative nameserver. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC}
At 9:38 PM +0100 2003/02/09, Stefan Paletta wrote:
[please do not explicitly send copies of followups to me]
Roger.
The ability to hand out referrals has an administrative overhead and is thus more prone to errors. The recent misconfiguration of NS.EU.NET is a good example for that.
It does require more network traffic, yes. But the specific IP addresses should not be paid attention to by anyone -- all they should record is that they got a response that basically said "Sorry, I don't have this information -- if you like, you may try asking this question of these machines".
Most importantly, responding with a SERVFAIL is RFC compliant.
I am not yet convinced of this. Yes, I've read the namedroppers traffic. But so far as I know, this issue has never been put into a ID, BCP, or standards-track RFC. Therefore, a very small community of people have discussed this issue in very isolated circumstances, and IMO this has not received sufficient review to be considered "RFC compliant".
Are you suggesting that different demands for conformance should be applied to root/TLD nameservers vs. others?
Depends on what you're testing against.
There is btw. nothing in the announcements of and documentation for NSD to suggest that it might not be designed or fit for use as a general-purpose authoritative nameserver.
Understood. However, obviously people are now mis-using it in this fashion (perhaps even at my behest, as a result of my presentation at LISA 2002), otherwise the original report would never have been generated. Therefore, I believe that making this point explicit is a very good idea. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On torsdag, feb 6, 2003, at 18:42 Europe/Stockholm, Stefan Paletta wrote:
Some TLD registries, however, make unreasonable demands regarding the behaviour of servers to which they delegate zones. Most notably the .fr and .it registries, which apparently demand that servers return a (non-authoritative!, in the case of .it) referral to the root servers when they are lame.
Do you have a pointer to this rule of theirs? In many cases an NS is lame simply because no DNS server is listening on the IP address which is associated with the NS in question. I.e. that someone has moved the server without talking to the parent zone administrator. paf
participants (7)
-
Brad Knowles -
Bruce Campbell -
Daniel Karrenberg -
Jakob Schlyter -
Patrik Fältström -
Stefan Paletta -
Stephane Bortzmeyer