On Tue, May 02, 2023 at 12:14 PM, Peter Thomassen <pe...@desec.io> wrote:
> On 5/2/23 17:52, Joe Abley wrote: > > On Tue, May 2, 2023 at 11:09, Peter Thomassen <pe...@desec.io <mailto:On > Tue, May 2, 2023 at 11:09, Peter Thomassen <<a href=>> wrote: > > If one of the NS answers non-authoritatively, then it doesn't serve a > proper NS RRset, so it's not possible for that server's response to agree / > be identical with that on the parent side. As a result, the delegation (to > that server) is lame, isn't it? > > A nameserver can answer authoritatively for a particular query without > being listed in any zone's NS RRSet. > > A response from a server doesn't necessarily include an NS RRSet anyway. > > Sure, but to compare to the delegation's NS RRset (as Paul was arguing), > you'll have to ask the authoritative nameserver for the NS RRset, in which > case the response should contain that RRset and the AA bit. > > Paul said that even if the AA bit was missing, that would not be lame, as > long as the RDATA agree. I was trying to say that if the child's answer is > indeed non-authoritative, that's not a proper situation because the two > servers make conflicting authority claims. > Perhaps, but it *is* quite common (or, at least used to be quite common, I haven't checked stats recently). A surprising number of people put some sort of load-balancer in front of their authorative servers. These would basically just be recursive servers which were only[0] willing to recurse for a specific set of zones, or would do some sort of funky GSLB type behavior, or were "DNS firewalls"(!). These often would skip setting the AA bit, because they were, you know, not actually authorative. What the parent and the child nameserver say w.r.t. the NS hosts' authority > is not identical; as a result, I would call it lame. (Apologies for the > loose wording in my earlier post; I really should be more careful.) > 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? 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. 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. I don't think that I'd call example.com "lame", as both ns1 and ns2 work OK. Note that both of these fail your parent and child need to be identical test. > Another case would be where the name server responds with REFUSED, which, > depending on the reader's DNS expertise, could be construed as a "answering > non-authoritatively", although it's not answer (only a response). Is this > meant to be included in the "lame" definition? > I think so. 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. This means that a server can be lame for a domain, or that "all of the servers in a delegation can be lame", which I'd personally often just call "a lame delegation". > (It is not clear whether the verb "answering" is meant to require the > presence of answer RRs, but I suppose so. Further, the distinction between > "answer" and "response" may not be obvious to someone reading about "lame > delegations" when debugging an issue, so it may be worth clarifying what's > meant, e.g. by referring to the RCODE.) > Yah! I think that (personal view) the important bit is that a (non-recursive) query is hitting a server which cannot provide a meaningful answer, either because it doesn't have the zone configured, or perhaps because there are "views" which hide that zone from that query address. I'll note that this is often not the nameservers fault - as an example, there are many domains which are pointed at e.g ns1.google.com which ns1.google.com has no idea about. This isn't it's fault - people just seem to include it in their NS set for some reason ¯\_(ツ)_/¯. W > Best, > Peter > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
