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

[Warren Kumari]

On Tue, May 02, 2023 at 7:43 PM, Havard Eidnes  wrote:

> 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.
>

Well, perhaps - but it *is* a common deployment scenario.

Many companies use ACLs and views (or similar) to expose something like
corp.example.com, but only to "internal" IP addresses[0]. It's obviously
easier to just have one set of nameservers, so if you query e.g www.
example.com from the global Internet you get an address, but if you query
e.g accounting.corp.example.com you get REFUSED.
I slight variation on this is if the servers for example.com *do* answer
the public Internet, but have a delegation to other servers which handle
the corp.example.com zone, and these only answer queries from "inside" the
organization.


W
[0]: Obviously you can't let just anyone on the Internets know that you
have a server called e.g accounting.corp.example.com with the IP address of
192.168.13.24, because, um… well… erm.. no-one has ever really been able to
explain the threat model to me, but they are all *sure* that the sky will
fall if attackers know this… Often there is some allusion to "well, it may
leak that we working on a magic hovercraft product, because they'd see a
device called magic-hovercraft.new-products.corp.example.com
… ¯\_(ツ)_/¯



> Best,
>
> - 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

[Havard Eidnes]

> 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

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

[Havard Eidnes]

>>"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".
>>
>> ... without the "or not at all" part (so, an answer is required for
>> "lameness").

I'm agreeing with the above, and think it is a precise
description of the term under discussion.

> I don't think that is complete.

I disagree.

> If all the parental NS records point to properly working
> nameservers, but the authoritative nameservers claim an
> additional NS record, I would also call the delegation
> lame.

In that case (and no other conditions given), I would simply call
the delegation inconsistent.

As has been said elsewhere, many recursors will let the NS RRset
from one of the authoritative name servers for the child zone
override the NS RRset received from one of the name servers of
the parent zone.

However, at this point in the description, the "additional" name
server *could* be have been configured to serve the zone, and
nothing untoward would happen operationally as a result.
However, the delegation would still be inconsistent.

> Especially if that additional nameserver specified in the
> authoritative NS RRset is responding non-authoritatively.

Then that response will be an indication that the delegation to
that name server would be characterized as being "lame" (even
though the corresponding NS record doesn't come from the parent
zone; this is covered by the quoted text above).

> This might not be lame on the initial queries, but if the
> resolver is child centric or validating, that broken
> authoritative NS will end up getting queried and a lame answer
> would be given.

Correct.

> How about:
>
> "A lame delegation is said to exist when the NS RRset of a zone is
>  different at the parent and child nameservers, with the mismatched
>  authoritative servers either listed at the parent or child answering
>  non-authoritatively for that zone."

I don't think this is a good definition because to me this over-
focuses on the "inconsistent" aspect, and it is not so that every
inconsistent delegation includes an instance of a lame
delegation.

On the other hand, you can have a perfectly consistent delegation
(NS RRsets from parent and child zone are identical), but still
have an instance of a lame delegation because one of the
delegated-to name servers answers non-authoritatively for the
zone in question.

I think the quoted definition at the top of this message more
precisely describes my perception of the term.  And, yes, I think
that you need to get a (non-authoritative) response in order to
say that the delegation of a given zone to a given name server is
lame.

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

[Warren Kumari]

On Tue, May 02, 2023 at 12:14 PM, Peter Thomassen  wrote:

> On 5/2/23 17:52, Joe Abley wrote:
>
> On Tue, May 2, 2023 at 11:09, Peter Thomassen mailto:On
> Tue, May 2, 2023 at 11:09, Peter Thomassen <> 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

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

[John Kristoff]

On Mon, 01 May 2023 21:15:29 +
Joe Abley  wrote:

> Yes -- some people (not me) would evidently describe a server that
> they didn't receive a response from as lame.

Lots of people and organizations tend to talk about "types" or "ways"
in which a server or delegation is lame. Here are a few well known
organizations or popular pages talking about what lame means so you
know the sorts of inconsistency (that's a term I like :-) you're up
against:

  

  

  
  
  

  

John

___
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

[Peter Thomassen]

On 5/2/23 17:52, Joe Abley wrote:

On Tue, May 2, 2023 at 11:09, Peter Thomassen mailto:On Tue, May 2, 2023 
at 11:09, Peter Thomassen <> 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. 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.)

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?

(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.)

Best,
Peter

___
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

[Joe Abley]

On Tue, May 2, 2023 at 11:09, Peter Thomassen <[pe...@desec.io](mailto:On Tue, 
May 2, 2023 at 11:09, Peter Thomassen < 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.

Whether or not two different servers that serve the same zone serve the same 
zone contents might be a sign of a problem, or it might be normal (e.g. a 
consequence of the loose coherence that is an accepted and acceptable 
consequence of DNS's standard replication mechanisms).

>

There are lots of things that can be wrong with DNS operations in general and 
with delegations in particular. A lame delegation is just one of them.

Joe___
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

[Joe Abley]

On Tue, May 2, 2023 at 11:01, Paul Wouters <[p...@nohats.ca](mailto:On Tue, May 
2, 2023 at 11:01, Paul Wouters < wrote:

> If all the parental NS records point to
> properly working nameservers, but the authoritative nameservers claim
> an additional NS record, I would also call the delegation lame.

I would not. A lame delegation is to do with the value of AA on a response from 
a server that has been included in an earlier referral. It's not to do with the 
contents of a zone.

Joe

>___
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

[Peter Thomassen]

On 5/2/23 17:07, Peter Thomassen wrote:



On 5/2/23 17:04, Paul Wouters 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.


To me this would not be lame if the NS RRsets are identical. You might
have still have a broken server, but if parent and child agrees, I
would not call it "lame".


It's possible I got this completely wrong, but if one of the NS answer 
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, no?


Excuse me, there was a fatal typo; I meant:

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?

Best,
Peter

___
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

[Peter Thomassen]

On 5/2/23 17:04, Paul Wouters 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.


To me this would not be lame if the NS RRsets are identical. You might
have still have a broken server, but if parent and child agrees, I
would not call it "lame".


It's possible I got this completely wrong, but if one of the NS answer 
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, no?

~Peter

--
https://desec.io/

___
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

[Paul Wouters]

On Tue, 2 May 2023, Frederico A C Neves wrote:


On Mon, May 01, 2023 at 04:43:11PM +, 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.


To me this would not be lame if the NS RRsets are identical. You might
have still have a broken server, but if parent and child agrees, I
would not call it "lame".

Paul

___
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

[Paul Wouters]

On Tue, 2 May 2023, Peter Thomassen wrote:

This, so far, was my understanding of the definition that was given in the 
other thread, and which Benno labeled (2) in the original post of this 
thread:


   "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".

... without the "or not at all" part (so, an answer is required for 
"lameness").


I don't think that is complete. If all the parental NS records point to
properly working nameservers, but the authoritative nameservers claim
an additional NS record, I would also call the delegation lame. Especially
if that additional nameserver specified in the authoritative NS RRset is
responding non-authoritatively. This might not be lame on the initial
queries, but if the resolver is child centric or validating, that broken
authoritative NS will end up getting queried and a lame answer would be
given.

Without asking to invent a term if none exists, I'd like to learn how to call 
a delegation that points to an NS hostname that does not have an address 
record (verifiably, e.g. denied by a DNSSEC negative response).


Before the discussion, I thought this qualifies as "lame" (because you can 
tell from the response that there's no DNS service; it's not a timeout), but 
with the above definition, it can't be called "lame".


How about:

"A lame delegation is said to exist when the NS RRset of a zone is
 different at the parent and child nameservers, with the mismatched
 authoritative servers either listed at the parent or child answering
 non-authoritatively for that zone."

Paul

___
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

[Wes Hardaker]

Paul Vixie  writes:

> > There I fixed it for you:
> 
> that's a meme, right?

Yes, it was a joke.  Apologies if it offended you in any way.

My point was to indicate that:

1. There are multiple (mis)understandings of what a lame delegation is
(regardless of whether or not the original terminology was more precise
and drift has happened)

2. There are in fact multiple underlying issues that could be better
documented in error messages to better explain to operators exactly what
problems are being seen.  This may require multiple terms to achieve a
better set of explanations.  Similar to how EDE has extended the reasons
why a SERVFAIL (or other error codes) may have been encountered.

> if you want to fix it

I've mentioned before that I think it would be better to have multiple
terms that defined more precise errors of exactly what was going wrong
from the point of view of the error-generator.  I typically don't rehash
my past statements unless I have something to add [and I don't - my
original statements still stand].  The consensus seemed to be at the
time "it's not broken, so we shouldn't fix it".

-- 
Wes Hardaker
USC/ISI

___
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

[Peter Thomassen]

On 5/1/23 23:22, Paul Vixie wrote:

to be a lame _delegation_ means some error or misconfiguration in the server. 
normally this means it's supposed to be authoritative but the zone expired or 
the operator forgot or similar.


This, so far, was my understanding of the definition that was given in the 
other thread, and which Benno labeled (2) in the original post of this thread:

   "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".

... without the "or not at all" part (so, an answer is required for "lameness").


or there is no server there any more (it was decomm'd or renumbered). icmp 
host-unreach or port-unreach would be symptoms of that, if you can hear them.


"Responses" like "unreachable" are not answers in the DNS sense. Are they meant to be included in 
"answer[ing] non-authoritatively" in the definition above, or is "answers non-authoritatively" 
restricted to DNS anwers (e.g. REFUSED)?


if we need more terms let's invent.


Without asking to invent a term if none exists, I'd like to learn how to call a 
delegation that points to an NS hostname that does not have an address record 
(verifiably, e.g. denied by a DNSSEC negative response).

Before the discussion, I thought this qualifies as "lame" (because you can tell from the 
response that there's no DNS service; it's not a timeout), but with the above definition, it can't 
be called "lame".

Thanks,
Peter

--
https://desec.io/

___
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

[Frederico A C Neves]

On Mon, May 01, 2023 at 04:43:11PM +, 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.

+1 for this one.

Fred

> 
> I don’t think it is perfect, but it is an improvement.  I don’t think 
> perfection will be achievable.  
> 
> IMO “[or not at all]” does not belong in the definition.  I don’t think we 
> should allow timeouts to be confused for or considered as lame delegation.
> 
> If something like the above definition is adopted then the document can note 
> there is some historical lack of agreement or consistency in use of the term.
> 
> DW
>  
> 
> 
> > On May 1, 2023, at 9:09 AM, Paul Hoffman  wrote:
> > 
> > Caution: This email originated from outside the organization. Do not click 
> > links or open attachments unless you recognize the sender and know the 
> > content is safe. 
> > 
> > It would be grand if a bunch more people would speak up on this thread.
> > 
> > --Paul Hoffman, wearing my co-author hat
> > 
> > On Apr 27, 2023, at 1: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://secure-web.cisco.com/1X5AMTQJt2cXj7u31WPDppT_N_lSyi56z_C_stVVEipVVZkqvDApuQPa0iKxw5z8KkYh6lUYaa8WwEbu1lbUw_3U3-oCZDRWfYload0wQnMB3d76sNuzWFVBh7JB6a-2AOK0wOchJz8ErMhve7dpEUAX3u3v-rv-1jqen-3Ar6uMAJe4pFpHNVMWX8RyUI7uPYRUghgCekgBWibFm6LiPtCBLmTeUAdGkHdbCvCQ-SgAe56iNE4EwIGnrBWJTVJZlM-Dv3FrK04mE2gMsQs6HDzz40kt4871oRIkuNMadfKo/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2F4E1AQKGivEHtJDB85gSNhofRuyM%2F):
> >> 
> >>  "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://secure-web.cisco.com/1XVxOCcNMkTcMeadUBQk9SlINRiQvUqtUMpxSKIOYBnT1ERKTnDtcFN1UjyDbfzk5FQqhfy31BXnCbOKFunIXd_OgZghAR9dJnnqlAmKIktWHve95FPY6YA3UinPiPabOUAEi7sOIwtzoF6rScnH_ml4EN5VeCkDj_DbUdU1FINNiKRFrKNlopElAMuHQoV1jehl-oCQtlNNopUy_X-mm_fPAbRNsYgc4S411S5vVePb4M-3xft1EktHXfsQNSe-y_vNR947juf5DmA2OYgq3gw0Efu3o0GxuyisOZ23nNj0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 
> ___
> 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

[Magnus Sandberg]

Hi all,

I think one of the problems are that we look at the term from different 
perspectives.


For me "lame delegation" is a log messages from the resolver software.

A lot of the comments are more from the human view and with different 
operational angles or potential end user experience.



If we only see it from the resolver software point of view it is 
something in the lines of "the status of the response (from what I 
thought was an authoritative server) didn't match my expectations", or 
"I didn't get a response at all".



When humans interpret that log message, we can see it from the resolver 
operation view, the zone owner view, the end users experience when 
trying to reach some service within the child zone, including slow 
responses as the resolver has to do extra work to find a way around the 
problem, etc.



So too many looking glasses or angles to know what we try to make clearer.

Regards,
// mem (without hats)



Den 2023-05-01 kl. 18:09, skrev Paul Hoffman:

It would be grand if a bunch more people would speak up on this thread.

--Paul Hoffman, wearing my co-author hat

On Apr 27, 2023, at 1: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