clueing in TLD registries for delegations to non-BIND servers
- Previous message (by thread): clueing in TLD registries for delegations to non-BIND servers
- Next message (by thread): clueing in TLD registries for delegations to non-BIND servers
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Brad Knowles
brad.knowles at skynet.be
Mon Feb 10 12:46:31 CET 2003
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 at 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(+++)
- Previous message (by thread): clueing in TLD registries for delegations to non-BIND servers
- Next message (by thread): clueing in TLD registries for delegations to non-BIND servers
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]