Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
> A lame delegation is said to exist when a server assumed (by
> the querier) to be authoritative for a zone replies
> non-authoritatively for {any|all} data within the zone.
...
> 3) {any|all} open question...can a server be "partially lame?"
Sadly, yes, ref. suspected load balancers who have been taught
how to reply to A queries, but return empty non-AA answers
(possibly with authority information) when queried for other
record types, such as , ref.
dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. a
vs.
dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com.
(this example came up earlier in the discussion, just repeating
it here as an example)
See the results of querying for "ns" or "soa", they are also
non-AA but with a authority section among others pointing to
itself, similar to the result for the "" query.
Regards,
- Håvard
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
On 5/1/23, 12:43 PM, "DNSOP on behalf of Wessels, Duane"
wrote:
>My preferred definition is the one originally given by Paul Vixie, amended
> by myself, and further amended by Peter Thomassen:
>
>A lame delegation is said to exist when one or more authoritative
>servers designated by the delegating NS rrset or by the child's apex NS
>rrset answers non-authoritatively for a zone.
The trouble I have with this definition is that servers don't "answer ... for a
zone", they answer specific queries.
Plus, the adjective "authoritative" is redundant, as " designated by the
delegating NS rrset or by the child's apex NS rrset" includes all authoritative
servers (and then some, if you don’t include a parent NS name not in the child
NS name as authortitative).
And, as DNS data is constantly changing, what's in or out of an NS set or
authoritatively answered may change from moment to moment (so I add 'assumed'
below):
A lame delegation is said to exist when a server assumed (by the querier) to be
authoritative for a zone replies non-authoritatively for {any|all} data within
the zone.
1) Answering authoritatively means that the answer section matches the query
and the AUTHORITATIVE ANSWER bit is properly set - this ought to be in its own
definition.
2) A server may be assumed to be authoritative for a zone if the server is
listed in a current NS set for the zone, whether that set is published by the
delegating zone at a cut point or by the zone itself at its apex. This also
should be a separate definition. ...The undefined term in that is "current" -
meaning - a NS set that is still within the TTL upon arrival...
3) {any|all} open question...can a server be "partially lame?"
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis one week extension for lame delegation definition
I've been around in DNS for quite a while. The way I've always heard "lame delegation" used is in the sense of a useless parent NS record at a delegation point. Note that "delegation" is singular. The usual case is that the server name in the NS RR is a non-existent name or has no address associated with it or, if it does have an address, there is no DNS server there. If an NS RR at the delegation point has an existing name that resolves to the address of a DNS server, its lameness is getting pretty mild but if that server can't answer authoritatively, then I guess it really is still a lame delegation... Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Thu, Apr 27, 2023 at 4:05 PM Benno Overeinder wrote: > Dear WG, > > The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion > on lame delegation did not find consensus, but two specific suggestions > were put forward. We would like to include one of them in rfc8499bis if > we can get consensus to do so. > > The chairs are seeking input on the following two suggestions: > > * Either we leave the definition of “lame delegation” as it is with the >comment that no consensus could be found, or > > * alternatively, we include a shorter definition without specific >examples. > > 1) Leaving the definition of lame delegation as in the current > draft-ietf-dnsop-rfc8499bis, and including the addition by the > authors that: > > "These early definitions do not match current use of the term "lame > delegation", but there is also no consensus on what a lame delegation > is." (Maybe change to ... no consensus what *exactly* a lame > delegation is.) > > 2) Update the definition as proposed by Duane and with the agreement of > some others (see mailing list > https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/): > > "A lame delegation is said to exist when one or more authoritative > servers designated by the delegating NS RRset or by the child's apex > NS RRset answers non-authoritatively [or not at all] for a zone". > > The chairs ask the WG to discuss these two alternative definitions of > the term "lame delegation". We close the consultation period on > Thursday 4 May. > > Regards, > > Benno > > ___ > 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
Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
On 5/1/23, 4:25 PM, "DNSOP on behalf of Mark Delany" wrote: >On 01May23, John Kristoff apparently wrote: >> (usually due to a bad configuration) > >Was any "lame" situation defined which wasn't the result of a bad > configuration? The difference between observing a symptom and diagnosing a cause is great. I say this to caution against tying the "why it is" with "what it is." (E.g., a lame delegation may have been set up to test software's reaction to a lame delegation, like seeing zone data mis-signed for a DNSSEC test.) Further, prescribing a remedy, even when a symptom is identified and a diagnosis nailing the cause, can still be tricky. In defining what the term "lame delegation" means, stick to the situation as observed, without guessing why or the fix. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
On 5/1/23, 12:58 PM, "DNSOP on behalf of John Kristoff" wrote: On Mon, 1 May 2023 16:09:23 + Paul Hoffman wrote: > It would be grand if a bunch more people would speak up on this > thread. I'm not particularly satisfied with the requirement that there must be a response to meet the definition, but that seems to be the consensus even if most seem to agree it is imperfect. I won't derail. Until someone comes up with better terminology, I'm likely still going to refer to all those many cases we see in operation (usually due to a bad configuration) as a form of lame delegation when a delegation is effectively broken. :-) When there is a timeout situation, there can be no conclusion about the remote end's status. It could be that the remote end is properly set up to answer for a zone, but queries to the server are dropped on the way there. Or responses dropped on the way back. Or that the timeout is simple too quick. The timeout may have nothing at all to do with the remote end. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
