Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[Warren Kumari <[e-mail]>]

On Tue, May 02, 2023 at 12:14 PM, Peter Thomassen <[e-mail]> wrote:

> On 5/2/23 17:52, Joe Abley wrote:
>
> On Tue, May 2, 2023 at 11:09, Peter Thomassen <[e-mail] <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>