> My parent says that the NS for exmple.com are ns1.example.com, > ns2.example.com , but I (example.com) say that my NS are ns1.example.com, > ns2.example.com *and* ns3.example.com. I don't (personally) think that this > is a lame delegation. Do others?
Nope. Given this information, this is simply "inconsistent". If both ns1.example.com, ns2.example.com and ns3.example.com are configured to serve the example.com zone, and return answers with aa=1 when queried for names in that zone, all is well and there is no instance of a "lame" delegation. However, if ns3.example.com isn't set up to serve the zone, and answers queries about names in the zone with aa=0, the delegation to that name server would be "lame". > Flipped around: My parent says that the NS for exmple.com are > ns1.example.com, ns2.example.com *and* ns3.example.com. I (example.com) say > that my NS are only ns1.example.com and ns2.example.com. At this point I'd again say "inconsistent". > If you query ns3.example.com, you get REFUSED. In that case I'd > (personally) say that ns3.example.com is lame for example.com. You had to put that in there? :) Thinking a bit about it: the REFUSED error code could be the result of configuring a name server with recursion turned off, and if you then query that name server about a name in a zone it is not set up to serve, a REFUSED answer would be "natural" and is these days fairly common for such a situation. Now, as to whether that's an instance of a lame delegation? I would tend to say "yes". > I don't think that I'd call example.com "lame", as both ns1 and > ns2 work OK. Correct. It's the particular delegation to ns3 which is "lame". Another example: if both the parent / delegating zone and the child zone lists ns1.example.com, ns2.example.com and ns3.example.com, you have a perfectly consistent delegation. However, if one of these are not set up to serve the zone, the delegation of this zone to that particular name server would be "lame". > I personally think that lameness is when a domain is delegated to a name > server, but that server does not have the zone configured. A corner case is > when the server is configured to not answer queries for that zone from that > source address, and so returns REFUSED or possibly SERVFAIL. If we're talking about the global DNS, restricting responses on a publishing name server does not make much sense to me. Best, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
