>> I believe that the most natural perspective is from the view point of a >> resolver attempting to classify a (non?)response to a query sent to an >> authoritative server. > > Another way of thinking about this perspective is that, e.g., a > delegation response from a.gtld-servers.net (.COM nameserver) that > returns some set of nameservers for "example.com.": > > ; ANSWER > ; AUTHORITY > example.com. IN NS ns1.provider.net. > example.com. IN NS ns2.provider.net. > > is a valid delegation response (and so not from this perspective a LAME > delegation), whether or not the target servers actualy serve the zone.
I agree that this is a valid delegation response. I do however disagree with the latter part of this sentence; it *may* be a "lame delegation" depending on the response you as a recursive resolver get from the two delegated-to name servers when you try to look up a name in the example.com zone. > A LAME delegation (response) happens when "ns1" or "ns2" respond to > queries with yet another (e.g. self) delegation that does not move the > resolver closer to the target: > > ; ANSWER > ; AUTHORITY > example.com. IN NS ns1.provider.net. > example.com. IN NS ns2.provider.net. I am having problems seeing under what normal-ish circumstances either ns1 or ns2 would provide this response. One could be that they do not serve the example.com zone, but are somehow hidden slave name servers for .com (which is unlikely due to the resource requirements to run such a name server). If they do serve example.com, I would normally expect a non-empty answer (if queried for an existing name in the zone), an err=NXDOMAIN response or an empty err=NOERROR response (for empty non-terminal names), and not a delegation as above. If they do not serve example.com, where would the delegation response come from? Remember, the recursive resolver querying these name servers would do so with RD=0, so neither of them are being asked to do a recursive lookup, so if they despite this either go out and query the .com name servers and return the delegation or respond with data from their cache (if they also provide recursive service to a subset of clients), that would go against the spirit of adhering to the RD=0. And ... both being a publishing name server and a recursive server is IMO rightfully frowned upon, especially if data from the cache is allowed to leak through to a non-recursive query. So ... if ns1 and ns2 are both publishing-only non-recursive name servers (which I would claim would be "normal"), and they do run a DNS name server, I would argue that an appropriate response to a query for a name in a zone they are not provisioned to serve would be err=REFUSED instead of somehow cooking up a delegation response. > A resolver would then report a LAME delegation EDE (once defined) > accordingly, based on non-progress. The concept of non-progress is nice. However, I don't think we need to define a new EDE, what's wrong with (re)using 4.23. Extended DNS Error Code 22 - No Reachable Authority The resolver could not reach any of the authoritative name servers (or they potentially refused to reply). > If there's a failure at the ".COM" layer, it falls outside the DNS > protocol, and veers into questions of intent and operator competence, > questions of authority and responsibility to keep data up date, ... I'm not sure what scenario this desribes -- a delegation from the root to the .com zone which points to a name server which isn't set up to serve the .com zone? (That would indeed be a lame delegation at the .com level, but would in operational reality be unlikely; the folks managing the .com zone tend to have their ducks in a row.) > Any protocol failure is with ns1/ns2 whether or not it is > administratively their operator's *fault*. Again, I'm not sure what this describes. However, the situation where both ns1 and ns2 fail to respond as "expected" to queries for example.com can very much arise without the administrator of ns1/ns2 being at fault. If the registrars for .com just allow registration of delegations without checking for operational viability at the time of delegation creation or modification, the domain owner of example.com can ask for this delegation without informing the operator of ns1/ns2. One could question why the domain owner would do that, "lack of knowledge" would be one valid response. But the operators of ns1/ns2 would not be at fault. But you had perhaps something else in mind? Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
