Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Shumon Huque]

On Fri, Apr 14, 2023 at 9:20 PM Mark Andrews  wrote:

>
> Similarly add an unknown EDNS option (pick a value between 1000 and 1999)
> to every QUERY until 1 Jan 2025 and if it comes back FORMERR with an OPT
> record present, drop the response.  10 years after cleaning up the EDNS
> specification we still have .5% of servers not updated.  BIND is
> effectively
> doing this with DNS COOKIE but it is painful when people say “but the
> lookup
> works with large recursive server”.
>

Yeah, I've mentioned the same sort of thing in the past too, when I first
learned
of TLS Grease (RFC 8701).

Speaking from experience though, and despite the efforts of EDNS flag day,
dropping the responses without fallback still may be too high a bar :(

We had to disable Cookies when we upgraded to a post EDNS flag day BIND
implementation because of hue and cry from some large customers still
running
broken DNS implementations :( (I mentioned more details on the
dns-operations
list at that time).

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Shumon Huque]

On Fri, Apr 14, 2023 at 7:04 PM Puneet Sood  wrote:

> I wanted to respond to this thread earlier, so apologies in advance
> for late posting and if this is a no-op at this point. Me getting
> confused about the last call for this draft
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/)
> and https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/
> being combined didn't help either.
>

I'm answering very late too, my apologies ...


> The draft does not contain any reference to the rfc8499bis I-D or to
> RFC 8499. It would be helpful to have a reference.
>

That's a reasonable suggestion. We can add it.

If it's not too late in the process:
> Given the numbers presented upthread, at a minimum could we have one
> sentence in section 2.3 Glue Cyclic Sibling Domain Name Server,
> discouraging implementers from doing this?
>

As I've mentioned earlier, I'm okay with adding such a sentence. And
perhaps you mean operators rather than implementers.

I see that the chairs have pushed the button on 'Publication Requested' for
this draft.

Maybe you can broach this subject again during "IETF last call", and we'll
see if we can get others to chime in then. (Personally, I'd also like to
see some big TLD operators speaking up in agreement with this. Otherwise,
we might just be writing something that will be ignored).

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Frederico A C Neves]

On Sat, Apr 15, 2023 at 11:20:13AM +1000, Mark Andrews wrote:
> At this stage I think the only way to force this is to drop negative
> responses without SOA records present.  To have the lookups fail and
> that requires buy in by the large recursive server operators.
> 
> Similarly add an unknown EDNS option (pick a value between 1000 and 1999)
> to every QUERY until 1 Jan 2025 and if it comes back FORMERR with an OPT
> record present, drop the response.  10 years after cleaning up the EDNS
> specification we still have .5% of servers not updated.  BIND is effectively
> doing this with DNS COOKIE but it is painful when people say “but the lookup
> works with large recursive server”. 

+1000 for this one!

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Mark Andrews]

At this stage I think the only way to force this is to drop negative
responses without SOA records present.  To have the lookups fail and
that requires buy in by the large recursive server operators.

Similarly add an unknown EDNS option (pick a value between 1000 and 1999)
to every QUERY until 1 Jan 2025 and if it comes back FORMERR with an OPT
record present, drop the response.  10 years after cleaning up the EDNS
specification we still have .5% of servers not updated.  BIND is effectively
doing this with DNS COOKIE but it is painful when people say “but the lookup
works with large recursive server”. 

> On 15 Apr 2023, at 11:01, Mark Andrews  wrote:
> 
> Somehow saying MUST include a SOA record in the negative response
> isn’t enough.
> 
> 3 - Negative Answers from Authoritative Servers
> 
> Name servers authoritative for a zone MUST include the SOA record of
> the zone in the authority section of the response when reporting an
> NXDOMAIN or indicating that no data of the requested type exists.
> This is required so that the response may be cached. The TTL of this
> record is set from the minimum of the MINIMUM field of the SOA record
> and the TTL of the SOA itself, and indicates how long a resolver may
> cache the negative answer. The TTL SIG record associated with the
> SOA record should also be trimmed in line with the SOA's TTL.
> 
> If the containing zone is signed [RFC2065] the SOA and appropriate
> NXT and SIG records MUST be added.
> 
> 6 - Negative answers from the cache
> 
> When a server, in answering a query, encounters a cached negative
> response it MUST add the cached SOA record to the authority section
> of the response with the TTL decremented by the amount of time it was
> stored in the cache. This allows the NXDOMAIN / NODATA response to
> time out correctly.
> 
>> On 15 Apr 2023, at 10:48, Puneet Sood  wrote:
>> 
>> Also the following section (2.2.1 - Special Handling of No Data)
>> suggests sending type 2 instead of type 1 responses but is silent
>> about type 3 responses.
>> 
>> On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood  wrote:
>>> 
>>> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews  wrote:
 
 RFC 2038 already says add the SOA so negative answers can be cached. The 
 other responses
 where to show what was out there so that they where not misinterpreted.
>>> I believe you are referring to this sentence? Quote: "The authority
>>> section will contain an SOA record, or there will be no NS records
>>> there."
>>> 
>>> That is not how I interpreted those lines. My understanding of the
>>> part after the "or" is that a response with an empty ANSWER and AUTH
>>> section also indicates NODATA (as confirmed by response type 3).
>>> 
 I doubt saying
 don’t do those old forms will make any difference.  Everything out there 
 has had 25 years
 to comply.
>>> I understand updating the specs by itself does not fix compliance.
>>> However clarifying that "or" would be useful.
>>> 
 
> On 15 Apr 2023, at 09:06, Puneet Sood 
>  wrote:
> 
> On the topic of authoritative server behavior as seen in the DNS
> responses, a few areas for improvement below (not touching DNSSEC).
> This is written from the perspective of a resolver using the auth
> responses to answer user queries.
> 
> * responding correctly to requests with certain flags, EDNS options.
> This is covered well by RFC 8906. Now we wait for compliance.
> 
> * proper glue
> This I-D clarifies the need to supply *all the glue* and to set TC=1
> correctly. Improve the specification for what to do with sibling or
> cyclic glue. Ideally recommend against publishing and/or depending on
> cyclic, sibling glue.
> 
> * NODATA responses
> RFC 2308 section 2.2 - No Data
> [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
> different ways an NS response could indicate NODATA. Types 1 and 2
> include a SOA record which is helpful in determining TTLs and start of
> the zone cut (this matters when the same auth server is authoritative
> for consecutive labels in a qname). Type 3 with no SOA while usable by
> resolvers is not very helpful.
> 
> Tightening of the specification to require type 1 or 2 responses for
> NODATA will be beneficial (drop type 3).
> 
> In addition two additional types of responses appear to show up in the
> wild. Tightening the spec likely won't help here.
> Type 4. SOA in Answer section
> Non-compliant but a resolver can kind of figure this out and use it to
> generate a NODATA answer.
> 
> Implementation note: Viktor has done work on this topic so we should
> have some data to share in a few weeks.
> 
> Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
> Generally treated as LAME.
> 
> Questions for the working group:
> Is there interest in updating existing specifications around 

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Mark Andrews]

Somehow saying MUST include a SOA record in the negative response
isn’t enough.

3 - Negative Answers from Authoritative Servers

Name servers authoritative for a zone MUST include the SOA record of
the zone in the authority section of the response when reporting an
NXDOMAIN or indicating that no data of the requested type exists.
This is required so that the response may be cached. The TTL of this
record is set from the minimum of the MINIMUM field of the SOA record
and the TTL of the SOA itself, and indicates how long a resolver may
cache the negative answer. The TTL SIG record associated with the
SOA record should also be trimmed in line with the SOA's TTL.

If the containing zone is signed [RFC2065] the SOA and appropriate
NXT and SIG records MUST be added.

6 - Negative answers from the cache

When a server, in answering a query, encounters a cached negative
response it MUST add the cached SOA record to the authority section
of the response with the TTL decremented by the amount of time it was
stored in the cache. This allows the NXDOMAIN / NODATA response to
time out correctly.

> On 15 Apr 2023, at 10:48, Puneet Sood  wrote:
> 
> Also the following section (2.2.1 - Special Handling of No Data)
> suggests sending type 2 instead of type 1 responses but is silent
> about type 3 responses.
> 
> On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood  wrote:
>> 
>> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews  wrote:
>>> 
>>> RFC 2038 already says add the SOA so negative answers can be cached. The 
>>> other responses
>>> where to show what was out there so that they where not misinterpreted.
>> I believe you are referring to this sentence? Quote: "The authority
>> section will contain an SOA record, or there will be no NS records
>> there."
>> 
>> That is not how I interpreted those lines. My understanding of the
>> part after the "or" is that a response with an empty ANSWER and AUTH
>> section also indicates NODATA (as confirmed by response type 3).
>> 
>>> I doubt saying
>>> don’t do those old forms will make any difference.  Everything out there 
>>> has had 25 years
>>> to comply.
>> I understand updating the specs by itself does not fix compliance.
>> However clarifying that "or" would be useful.
>> 
>>> 
 On 15 Apr 2023, at 09:06, Puneet Sood 
  wrote:
 
 On the topic of authoritative server behavior as seen in the DNS
 responses, a few areas for improvement below (not touching DNSSEC).
 This is written from the perspective of a resolver using the auth
 responses to answer user queries.
 
 * responding correctly to requests with certain flags, EDNS options.
 This is covered well by RFC 8906. Now we wait for compliance.
 
 * proper glue
 This I-D clarifies the need to supply *all the glue* and to set TC=1
 correctly. Improve the specification for what to do with sibling or
 cyclic glue. Ideally recommend against publishing and/or depending on
 cyclic, sibling glue.
 
 * NODATA responses
 RFC 2308 section 2.2 - No Data
 [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
 different ways an NS response could indicate NODATA. Types 1 and 2
 include a SOA record which is helpful in determining TTLs and start of
 the zone cut (this matters when the same auth server is authoritative
 for consecutive labels in a qname). Type 3 with no SOA while usable by
 resolvers is not very helpful.
 
 Tightening of the specification to require type 1 or 2 responses for
 NODATA will be beneficial (drop type 3).
 
 In addition two additional types of responses appear to show up in the
 wild. Tightening the spec likely won't help here.
 Type 4. SOA in Answer section
 Non-compliant but a resolver can kind of figure this out and use it to
 generate a NODATA answer.
 
 Implementation note: Viktor has done work on this topic so we should
 have some data to share in a few weeks.
 
 Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
 Generally treated as LAME.
 
 Questions for the working group:
 Is there interest in updating existing specifications around glue and
 NODATA responses?
 
 Are there other related auth response specifications which would
 benefit from updates?
 
 Thanks for reading.
 
 -Puneet
 
 On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
> 
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  
> wrote:
>> 
>> 
>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
>>> 
>>> 
>>> 
>>> On 3/28/23 03:14, Shumon Huque wrote:
 On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni 
 mailto:ietf-d...@dukhovni.org>> wrote:
 
   On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
   Can we at least state that domains with cyclic dependencies are a bad
   idea, and may not be supported 

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

Also the following section (2.2.1 - Special Handling of No Data)
suggests sending type 2 instead of type 1 responses but is silent
about type 3 responses.

On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood  wrote:
>
> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews  wrote:
> >
> > RFC 2038 already says add the SOA so negative answers can be cached. The 
> > other responses
> > where to show what was out there so that they where not misinterpreted.
> I believe you are referring to this sentence? Quote: "The authority
> section will contain an SOA record, or there will be no NS records
> there."
>
> That is not how I interpreted those lines. My understanding of the
> part after the "or" is that a response with an empty ANSWER and AUTH
> section also indicates NODATA (as confirmed by response type 3).
>
> > I doubt saying
> > don’t do those old forms will make any difference.  Everything out there 
> > has had 25 years
> > to comply.
> I understand updating the specs by itself does not fix compliance.
> However clarifying that "or" would be useful.
>
> >
> > > On 15 Apr 2023, at 09:06, Puneet Sood 
> > >  wrote:
> > >
> > > On the topic of authoritative server behavior as seen in the DNS
> > > responses, a few areas for improvement below (not touching DNSSEC).
> > > This is written from the perspective of a resolver using the auth
> > > responses to answer user queries.
> > >
> > > * responding correctly to requests with certain flags, EDNS options.
> > > This is covered well by RFC 8906. Now we wait for compliance.
> > >
> > > * proper glue
> > > This I-D clarifies the need to supply *all the glue* and to set TC=1
> > > correctly. Improve the specification for what to do with sibling or
> > > cyclic glue. Ideally recommend against publishing and/or depending on
> > > cyclic, sibling glue.
> > >
> > > * NODATA responses
> > > RFC 2308 section 2.2 - No Data
> > > [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
> > > different ways an NS response could indicate NODATA. Types 1 and 2
> > > include a SOA record which is helpful in determining TTLs and start of
> > > the zone cut (this matters when the same auth server is authoritative
> > > for consecutive labels in a qname). Type 3 with no SOA while usable by
> > > resolvers is not very helpful.
> > >
> > > Tightening of the specification to require type 1 or 2 responses for
> > > NODATA will be beneficial (drop type 3).
> > >
> > > In addition two additional types of responses appear to show up in the
> > > wild. Tightening the spec likely won't help here.
> > > Type 4. SOA in Answer section
> > > Non-compliant but a resolver can kind of figure this out and use it to
> > > generate a NODATA answer.
> > >
> > > Implementation note: Viktor has done work on this topic so we should
> > > have some data to share in a few weeks.
> > >
> > > Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
> > > Generally treated as LAME.
> > >
> > > Questions for the working group:
> > > Is there interest in updating existing specifications around glue and
> > > NODATA responses?
> > >
> > > Are there other related auth response specifications which would
> > > benefit from updates?
> > >
> > > Thanks for reading.
> > >
> > > -Puneet
> > >
> > > On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
> > >>
> > >> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  
> > >> wrote:
> > >>>
> > >>>
> > >>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> > 
> > 
> > 
> >  On 3/28/23 03:14, Shumon Huque wrote:
> > > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni 
> > > mailto:ietf-d...@dukhovni.org>> wrote:
> > >
> > >On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > >Can we at least state that domains with cyclic dependencies are a 
> > > bad
> > >idea, and may not be supported by all resolvers.  In other words, 
> > > that
> > >the domain owner can't **rely** on the sibling glue recommended to 
> > > be
> > >sent in this draft to save the day.
> > >
> > >My strong preference is still to delete all reference in the draft 
> > > to
> > >cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > >sibling glue primarily as a performance optimisation, and 
> > > secondarily
> > >as a last resort when the nameserver IP addresses are wrong or gone
> > >from the authoritative zone (another bad practice).
> > >
> > >
> > > Viktor - I've so far not seen many other people speak up in support 
> > > of your
> > > position. I suspect this is because this draft was discussed to death 
> > > many
> > > months ago during long discussion threads on the list, and there is 
> > > likely
> > > already rough consensus for the current content. Personally, I would 
> > > be ok
> > > with adding a statement that configurations involving cyclic 
> > > dependencies

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews  wrote:
>
> RFC 2038 already says add the SOA so negative answers can be cached. The 
> other responses
> where to show what was out there so that they where not misinterpreted.
I believe you are referring to this sentence? Quote: "The authority
section will contain an SOA record, or there will be no NS records
there."

That is not how I interpreted those lines. My understanding of the
part after the "or" is that a response with an empty ANSWER and AUTH
section also indicates NODATA (as confirmed by response type 3).

> I doubt saying
> don’t do those old forms will make any difference.  Everything out there has 
> had 25 years
> to comply.
I understand updating the specs by itself does not fix compliance.
However clarifying that "or" would be useful.

>
> > On 15 Apr 2023, at 09:06, Puneet Sood  
> > wrote:
> >
> > On the topic of authoritative server behavior as seen in the DNS
> > responses, a few areas for improvement below (not touching DNSSEC).
> > This is written from the perspective of a resolver using the auth
> > responses to answer user queries.
> >
> > * responding correctly to requests with certain flags, EDNS options.
> > This is covered well by RFC 8906. Now we wait for compliance.
> >
> > * proper glue
> > This I-D clarifies the need to supply *all the glue* and to set TC=1
> > correctly. Improve the specification for what to do with sibling or
> > cyclic glue. Ideally recommend against publishing and/or depending on
> > cyclic, sibling glue.
> >
> > * NODATA responses
> > RFC 2308 section 2.2 - No Data
> > [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
> > different ways an NS response could indicate NODATA. Types 1 and 2
> > include a SOA record which is helpful in determining TTLs and start of
> > the zone cut (this matters when the same auth server is authoritative
> > for consecutive labels in a qname). Type 3 with no SOA while usable by
> > resolvers is not very helpful.
> >
> > Tightening of the specification to require type 1 or 2 responses for
> > NODATA will be beneficial (drop type 3).
> >
> > In addition two additional types of responses appear to show up in the
> > wild. Tightening the spec likely won't help here.
> > Type 4. SOA in Answer section
> > Non-compliant but a resolver can kind of figure this out and use it to
> > generate a NODATA answer.
> >
> > Implementation note: Viktor has done work on this topic so we should
> > have some data to share in a few weeks.
> >
> > Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
> > Generally treated as LAME.
> >
> > Questions for the working group:
> > Is there interest in updating existing specifications around glue and
> > NODATA responses?
> >
> > Are there other related auth response specifications which would
> > benefit from updates?
> >
> > Thanks for reading.
> >
> > -Puneet
> >
> > On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
> >>
> >> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  
> >> wrote:
> >>>
> >>>
> >>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> 
> 
> 
>  On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > > wrote:
> >
> >On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> >Can we at least state that domains with cyclic dependencies are a bad
> >idea, and may not be supported by all resolvers.  In other words, 
> > that
> >the domain owner can't **rely** on the sibling glue recommended to be
> >sent in this draft to save the day.
> >
> >My strong preference is still to delete all reference in the draft to
> >cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> >sibling glue primarily as a performance optimisation, and secondarily
> >as a last resort when the nameserver IP addresses are wrong or gone
> >from the authoritative zone (another bad practice).
> >
> >
> > Viktor - I've so far not seen many other people speak up in support of 
> > your
> > position. I suspect this is because this draft was discussed to death 
> > many
> > months ago during long discussion threads on the list, and there is 
> > likely
> > already rough consensus for the current content. Personally, I would be 
> > ok
> > with adding a statement that configurations involving cyclic 
> > dependencies
> > are not recommended, but others will likely have to also speak up in 
> > support
> > of this too.
> 
>  I support adding such a statement about cyclic dependencies.
> >>>
> >>>
> >>> As do I.
> >>>
> >>>
> 
> 
>  In addition, I would support saying that data suggests that, while 
>  (non-cyclic) glue records may have a benefit in certain cases, they 
>  frequently are a source of harm (time-outs), and the trade-off remains 

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Mark Andrews]

RFC 2038 already says add the SOA so negative answers can be cached. The other 
responses
where to show what was out there so that they where not misinterpreted. I doubt 
saying
don’t do those old forms will make any difference.  Everything out there has 
had 25 years
to comply.

> On 15 Apr 2023, at 09:06, Puneet Sood  
> wrote:
> 
> On the topic of authoritative server behavior as seen in the DNS
> responses, a few areas for improvement below (not touching DNSSEC).
> This is written from the perspective of a resolver using the auth
> responses to answer user queries.
> 
> * responding correctly to requests with certain flags, EDNS options.
> This is covered well by RFC 8906. Now we wait for compliance.
> 
> * proper glue
> This I-D clarifies the need to supply *all the glue* and to set TC=1
> correctly. Improve the specification for what to do with sibling or
> cyclic glue. Ideally recommend against publishing and/or depending on
> cyclic, sibling glue.
> 
> * NODATA responses
> RFC 2308 section 2.2 - No Data
> [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
> different ways an NS response could indicate NODATA. Types 1 and 2
> include a SOA record which is helpful in determining TTLs and start of
> the zone cut (this matters when the same auth server is authoritative
> for consecutive labels in a qname). Type 3 with no SOA while usable by
> resolvers is not very helpful.
> 
> Tightening of the specification to require type 1 or 2 responses for
> NODATA will be beneficial (drop type 3).
> 
> In addition two additional types of responses appear to show up in the
> wild. Tightening the spec likely won't help here.
> Type 4. SOA in Answer section
> Non-compliant but a resolver can kind of figure this out and use it to
> generate a NODATA answer.
> 
> Implementation note: Viktor has done work on this topic so we should
> have some data to share in a few weeks.
> 
> Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
> Generally treated as LAME.
> 
> Questions for the working group:
> Is there interest in updating existing specifications around glue and
> NODATA responses?
> 
> Are there other related auth response specifications which would
> benefit from updates?
> 
> Thanks for reading.
> 
> -Puneet
> 
> On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
>> 
>> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
>>> 
>>> 
>>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
 
 
 
 On 3/28/23 03:14, Shumon Huque wrote:
> On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > wrote:
> 
>On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
>Can we at least state that domains with cyclic dependencies are a bad
>idea, and may not be supported by all resolvers.  In other words, that
>the domain owner can't **rely** on the sibling glue recommended to be
>sent in this draft to save the day.
> 
>My strong preference is still to delete all reference in the draft to
>cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
>sibling glue primarily as a performance optimisation, and secondarily
>as a last resort when the nameserver IP addresses are wrong or gone
>from the authoritative zone (another bad practice).
> 
> 
> Viktor - I've so far not seen many other people speak up in support of 
> your
> position. I suspect this is because this draft was discussed to death many
> months ago during long discussion threads on the list, and there is likely
> already rough consensus for the current content. Personally, I would be ok
> with adding a statement that configurations involving cyclic dependencies
> are not recommended, but others will likely have to also speak up in 
> support
> of this too.
 
 I support adding such a statement about cyclic dependencies.
>>> 
>>> 
>>> As do I.
>>> 
>>> 
 
 
 In addition, I would support saying that data suggests that, while 
 (non-cyclic) glue records may have a benefit in certain cases, they 
 frequently are a source of harm (time-outs), and the trade-off remains 
 unclear.
>>> 
>>> 
>>> I would support this as well.
>>> 
>>> In my anecdotal experience as an operator, I routinely encounter mismatches 
>>> in sibling glue and child zone NS sets that appear to be due to the glue 
>>> being forgotten.  My assumption is that, because it's not necessary to 
>>> operate, when operators fail to update it they don't receive any kind of 
>>> signal that something is wrong.
>>> 
>>> Viktor's numbers are pretty clear data, though, so nobody should need my 
>>> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
>>> in some cases, given how poorly maintained it is it seems to cause more 
>>> problems than it solves.
>>> 
>> 
>> I'd like to remind folks that the scope of this draft 

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

On the topic of authoritative server behavior as seen in the DNS
responses, a few areas for improvement below (not touching DNSSEC).
This is written from the perspective of a resolver using the auth
responses to answer user queries.

* responding correctly to requests with certain flags, EDNS options.
This is covered well by RFC 8906. Now we wait for compliance.

* proper glue
This I-D clarifies the need to supply *all the glue* and to set TC=1
correctly. Improve the specification for what to do with sibling or
cyclic glue. Ideally recommend against publishing and/or depending on
cyclic, sibling glue.

* NODATA responses
RFC 2308 section 2.2 - No Data
[https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three
different ways an NS response could indicate NODATA. Types 1 and 2
include a SOA record which is helpful in determining TTLs and start of
the zone cut (this matters when the same auth server is authoritative
for consecutive labels in a qname). Type 3 with no SOA while usable by
resolvers is not very helpful.

Tightening of the specification to require type 1 or 2 responses for
NODATA will be beneficial (drop type 3).

In addition two additional types of responses appear to show up in the
wild. Tightening the spec likely won't help here.
Type 4. SOA in Answer section
Non-compliant but a resolver can kind of figure this out and use it to
generate a NODATA answer.

Implementation note: Viktor has done work on this topic so we should
have some data to share in a few weeks.

Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :()
Generally treated as LAME.

Questions for the working group:
Is there interest in updating existing specifications around glue and
NODATA responses?

Are there other related auth response specifications which would
benefit from updates?

Thanks for reading.

-Puneet

On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
>
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
>>
>>
>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
>>>
>>>
>>>
>>> On 3/28/23 03:14, Shumon Huque wrote:
>>> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni >> > > wrote:
>>> >
>>> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
>>> > Can we at least state that domains with cyclic dependencies are a bad
>>> > idea, and may not be supported by all resolvers.  In other words, that
>>> > the domain owner can't **rely** on the sibling glue recommended to be
>>> > sent in this draft to save the day.
>>> >
>>> > My strong preference is still to delete all reference in the draft to
>>> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
>>> > sibling glue primarily as a performance optimisation, and secondarily
>>> > as a last resort when the nameserver IP addresses are wrong or gone
>>> > from the authoritative zone (another bad practice).
>>> >
>>> >
>>> > Viktor - I've so far not seen many other people speak up in support of 
>>> > your
>>> > position. I suspect this is because this draft was discussed to death many
>>> > months ago during long discussion threads on the list, and there is likely
>>> > already rough consensus for the current content. Personally, I would be ok
>>> > with adding a statement that configurations involving cyclic dependencies
>>> > are not recommended, but others will likely have to also speak up in 
>>> > support
>>> > of this too.
>>>
>>> I support adding such a statement about cyclic dependencies.
>>
>>
>> As do I.
>>
>>
>>>
>>>
>>> In addition, I would support saying that data suggests that, while 
>>> (non-cyclic) glue records may have a benefit in certain cases, they 
>>> frequently are a source of harm (time-outs), and the trade-off remains 
>>> unclear.
>>
>>
>> I would support this as well.
>>
>> In my anecdotal experience as an operator, I routinely encounter mismatches 
>> in sibling glue and child zone NS sets that appear to be due to the glue 
>> being forgotten.  My assumption is that, because it's not necessary to 
>> operate, when operators fail to update it they don't receive any kind of 
>> signal that something is wrong.
>>
>> Viktor's numbers are pretty clear data, though, so nobody should need my 
>> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
>> in some cases, given how poorly maintained it is it seems to cause more 
>> problems than it solves.
>>
>
> I'd like to remind folks that the scope of this draft when it was adopted by 
> the working group was very narrow. Mainly to say that 'required' glue must 
> set TC=1 if it doesn't fit into the DNS response payload. That required 
> talking about other types of non-mandatory glue like sibling, but has not 
> proposed to change authoritative server behavior in those areas.
>
> If folks want to deprecate sibling glue entirely, it would be best to write 
> another draft saying that and see if we can get consensus on that.
>
> Shumon.
>
> 

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Puneet Sood]

I wanted to respond to this thread earlier, so apologies in advance
for late posting and if this is a no-op at this point. Me getting
confused about the last call for this draft
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/)
and https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/
being combined didn't help either.

The draft does not contain any reference to the rfc8499bis I-D or to
RFC 8499. It would be helpful to have a reference.

On Tue, Mar 28, 2023 at 9:54 PM Shumon Huque  wrote:
>
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
>>
>>
>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
>>>
>>>
>>>
>>> On 3/28/23 03:14, Shumon Huque wrote:
>>> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni >> > > wrote:
>>> >
>>> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
>>> > Can we at least state that domains with cyclic dependencies are a bad
>>> > idea, and may not be supported by all resolvers.  In other words, that
>>> > the domain owner can't **rely** on the sibling glue recommended to be
>>> > sent in this draft to save the day.
>>> >
>>> > My strong preference is still to delete all reference in the draft to
>>> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
>>> > sibling glue primarily as a performance optimisation, and secondarily
>>> > as a last resort when the nameserver IP addresses are wrong or gone
>>> > from the authoritative zone (another bad practice).
>>> >
>>> >
>>> > Viktor - I've so far not seen many other people speak up in support of 
>>> > your
>>> > position. I suspect this is because this draft was discussed to death many
>>> > months ago during long discussion threads on the list, and there is likely
>>> > already rough consensus for the current content. Personally, I would be ok
>>> > with adding a statement that configurations involving cyclic dependencies
>>> > are not recommended, but others will likely have to also speak up in 
>>> > support
>>> > of this too.
>>>
>>> I support adding such a statement about cyclic dependencies.
>>
>>
>> As do I.
>>
>>
>>>
>>>
>>> In addition, I would support saying that data suggests that, while 
>>> (non-cyclic) glue records may have a benefit in certain cases, they 
>>> frequently are a source of harm (time-outs), and the trade-off remains 
>>> unclear.
>>
>>
>> I would support this as well.
>>
>> In my anecdotal experience as an operator, I routinely encounter mismatches 
>> in sibling glue and child zone NS sets that appear to be due to the glue 
>> being forgotten.  My assumption is that, because it's not necessary to 
>> operate, when operators fail to update it they don't receive any kind of 
>> signal that something is wrong.
>>
>> Viktor's numbers are pretty clear data, though, so nobody should need my 
>> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
>> in some cases, given how poorly maintained it is it seems to cause more 
>> problems than it solves.

If it's not too late in the process:
Given the numbers presented upthread, at a minimum could we have one
sentence in section 2.3 Glue Cyclic Sibling Domain Name Server,
discouraging implementers from doing this?

>>
>
> I'd like to remind folks that the scope of this draft when it was adopted by 
> the working group was very narrow. Mainly to say that 'required' glue must 
> set TC=1 if it doesn't fit into the DNS response payload. That required 
> talking about other types of non-mandatory glue like sibling, but has not 
> proposed to change authoritative server behavior in those areas.
>
> If folks want to deprecate sibling glue entirely, it would be best to write 
> another draft saying that and see if we can get consensus on that.

This is a reasonable position. Sending a separate email.

-Puneet

>
> Shumon.
>
> ___
> 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] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Tim Wicinski]

To follow up with Shumon and Duane's comments, the title of the document
was changed over time to "DNS Glue Requirements in Referral Responses" to
more accurately reflect the document's contents.
The datatracker name did not change to reflect that.
tim


On Tue, Mar 28, 2023 at 9:58 PM Wessels, Duane  wrote:

>
>
> > On Mar 29, 2023, at 10:53 AM, Shumon Huque  wrote:
> >
> > On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett 
> wrote:
> >
> > On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> >
> >
> > On 3/28/23 03:14, Shumon Huque wrote:
> > > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni <
> ietf-d...@dukhovni.org > wrote:
> > >
> > > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > > Can we at least state that domains with cyclic dependencies are a
> bad
> > > idea, and may not be supported by all resolvers.  In other words,
> that
> > > the domain owner can't **rely** on the sibling glue recommended to
> be
> > > sent in this draft to save the day.
> > >
> > > My strong preference is still to delete all reference in the draft
> to
> > > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > > sibling glue primarily as a performance optimisation, and
> secondarily
> > > as a last resort when the nameserver IP addresses are wrong or gone
> > > from the authoritative zone (another bad practice).
> > >
> > >
> > > Viktor - I've so far not seen many other people speak up in support of
> your
> > > position. I suspect this is because this draft was discussed to death
> many
> > > months ago during long discussion threads on the list, and there is
> likely
> > > already rough consensus for the current content. Personally, I would
> be ok
> > > with adding a statement that configurations involving cyclic
> dependencies
> > > are not recommended, but others will likely have to also speak up in
> support
> > > of this too.
> >
> > I support adding such a statement about cyclic dependencies.
> >
> > As do I.
> >
> >
> > In addition, I would support saying that data suggests that, while
> (non-cyclic) glue records may have a benefit in certain cases, they
> frequently are a source of harm (time-outs), and the trade-off remains
> unclear.
> >
> > I would support this as well.
> >
> > In my anecdotal experience as an operator, I routinely encounter
> mismatches in sibling glue and child zone NS sets that appear to be due to
> the glue being forgotten.  My assumption is that, because it's not
> necessary to operate, when operators fail to update it they don't receive
> any kind of signal that something is wrong.
> >
> > Viktor's numbers are pretty clear data, though, so nobody should need my
> anecdotes to be convinced.  While sibling glue may be a useful optimisation
> in some cases, given how poorly maintained it is it seems to cause more
> problems than it solves.
> >
> >
> > I'd like to remind folks that the scope of this draft when it was
> adopted by the working group was very narrow. Mainly to say that 'required'
> glue must set TC=1 if it doesn't fit into the DNS response payload. That
> required talking about other types of non-mandatory glue like sibling, but
> has not proposed to change authoritative server behavior in those areas.
> >
> > If folks want to deprecate sibling glue entirely, it would be best to
> write another draft saying that and see if we can get consensus on that.
> >
>
> I agree with this position.  The scope of the draft is about message size
> and behavior when glue records don’t fit.  Although the “glue is not
> optional” name is catchy, in hindsight I think a different name would
> better reflect the intent of the document.
>
> DW
>
>
> ___
> 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] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Wessels, Duane]

> On Mar 29, 2023, at 10:53 AM, Shumon Huque  wrote:
> 
> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:
> 
> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
> 
> 
> On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > > wrote:
> > 
> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > Can we at least state that domains with cyclic dependencies are a bad
> > idea, and may not be supported by all resolvers.  In other words, that
> > the domain owner can't **rely** on the sibling glue recommended to be
> > sent in this draft to save the day.
> > 
> > My strong preference is still to delete all reference in the draft to
> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > sibling glue primarily as a performance optimisation, and secondarily
> > as a last resort when the nameserver IP addresses are wrong or gone
> > from the authoritative zone (another bad practice).
> > 
> > 
> > Viktor - I've so far not seen many other people speak up in support of your
> > position. I suspect this is because this draft was discussed to death many
> > months ago during long discussion threads on the list, and there is likely
> > already rough consensus for the current content. Personally, I would be ok
> > with adding a statement that configurations involving cyclic dependencies
> > are not recommended, but others will likely have to also speak up in support
> > of this too.
> 
> I support adding such a statement about cyclic dependencies.
> 
> As do I. 
>  
> 
> In addition, I would support saying that data suggests that, while 
> (non-cyclic) glue records may have a benefit in certain cases, they 
> frequently are a source of harm (time-outs), and the trade-off remains 
> unclear.
> 
> I would support this as well.
> 
> In my anecdotal experience as an operator, I routinely encounter mismatches 
> in sibling glue and child zone NS sets that appear to be due to the glue 
> being forgotten.  My assumption is that, because it's not necessary to 
> operate, when operators fail to update it they don't receive any kind of 
> signal that something is wrong.
> 
> Viktor's numbers are pretty clear data, though, so nobody should need my 
> anecdotes to be convinced.  While sibling glue may be a useful optimisation 
> in some cases, given how poorly maintained it is it seems to cause more 
> problems than it solves.
> 
> 
> I'd like to remind folks that the scope of this draft when it was adopted by 
> the working group was very narrow. Mainly to say that 'required' glue must 
> set TC=1 if it doesn't fit into the DNS response payload. That required 
> talking about other types of non-mandatory glue like sibling, but has not 
> proposed to change authoritative server behavior in those areas.
> 
> If folks want to deprecate sibling glue entirely, it would be best to write 
> another draft saying that and see if we can get consensus on that.
> 

I agree with this position.  The scope of the draft is about message size and 
behavior when glue records don’t fit.  Although the “glue is not optional” name 
is catchy, in hindsight I think a different name would better reflect the 
intent of the document.

DW


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Shumon Huque]

On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett  wrote:

>
> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:
>
>>
>>
>> On 3/28/23 03:14, Shumon Huque wrote:
>> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni > > wrote:
>> >
>> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
>> > Can we at least state that domains with cyclic dependencies are a
>> bad
>> > idea, and may not be supported by all resolvers.  In other words,
>> that
>> > the domain owner can't **rely** on the sibling glue recommended to
>> be
>> > sent in this draft to save the day.
>> >
>> > My strong preference is still to delete all reference in the draft
>> to
>> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
>> > sibling glue primarily as a performance optimisation, and
>> secondarily
>> > as a last resort when the nameserver IP addresses are wrong or gone
>> > from the authoritative zone (another bad practice).
>> >
>> >
>> > Viktor - I've so far not seen many other people speak up in support of
>> your
>> > position. I suspect this is because this draft was discussed to death
>> many
>> > months ago during long discussion threads on the list, and there is
>> likely
>> > already rough consensus for the current content. Personally, I would be
>> ok
>> > with adding a statement that configurations involving cyclic
>> dependencies
>> > are not recommended, but others will likely have to also speak up in
>> support
>> > of this too.
>>
>> I support adding such a statement about cyclic dependencies.
>>
>
> As do I.
>

>
>>
>> In addition, I would support saying that data suggests that, while
>> (non-cyclic) glue records may have a benefit in certain cases, they
>> frequently are a source of harm (time-outs), and the trade-off remains
>> unclear.
>>
>
> I would support this as well.
>
> In my anecdotal experience as an operator, I routinely encounter
> mismatches in sibling glue and child zone NS sets that appear to be due to
> the glue being forgotten.  My assumption is that, because it's not
> necessary to operate, when operators fail to update it they don't receive
> any kind of signal that something is wrong.
>
> Viktor's numbers are pretty clear data, though, so nobody should need my
> anecdotes to be convinced.  While sibling glue may be a useful optimisation
> in some cases, given how poorly maintained it is it seems to cause more
> problems than it solves.
>
>
I'd like to remind folks that the scope of this draft when it was adopted
by the working group was very narrow. Mainly to say that 'required' glue
must set TC=1 if it doesn't fit into the DNS response payload. That
required talking about other types of non-mandatory glue like sibling, but
has not proposed to change authoritative server behavior in those areas.

If folks want to deprecate sibling glue entirely, it would be best to write
another draft saying that and see if we can get consensus on that.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Matthew Pounsett]

On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen  wrote:

>
>
> On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni  > wrote:
> >
> > On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > Can we at least state that domains with cyclic dependencies are a bad
> > idea, and may not be supported by all resolvers.  In other words,
> that
> > the domain owner can't **rely** on the sibling glue recommended to be
> > sent in this draft to save the day.
> >
> > My strong preference is still to delete all reference in the draft to
> > cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> > sibling glue primarily as a performance optimisation, and secondarily
> > as a last resort when the nameserver IP addresses are wrong or gone
> > from the authoritative zone (another bad practice).
> >
> >
> > Viktor - I've so far not seen many other people speak up in support of
> your
> > position. I suspect this is because this draft was discussed to death
> many
> > months ago during long discussion threads on the list, and there is
> likely
> > already rough consensus for the current content. Personally, I would be
> ok
> > with adding a statement that configurations involving cyclic dependencies
> > are not recommended, but others will likely have to also speak up in
> support
> > of this too.
>
> I support adding such a statement about cyclic dependencies.
>

As do I.


>
> In addition, I would support saying that data suggests that, while
> (non-cyclic) glue records may have a benefit in certain cases, they
> frequently are a source of harm (time-outs), and the trade-off remains
> unclear.
>

I would support this as well.

In my anecdotal experience as an operator, I routinely encounter mismatches
in sibling glue and child zone NS sets that appear to be due to the glue
being forgotten.  My assumption is that, because it's not necessary to
operate, when operators fail to update it they don't receive any kind of
signal that something is wrong.

Viktor's numbers are pretty clear data, though, so nobody should need my
anecdotes to be convinced.  While sibling glue may be a useful optimisation
in some cases, given how poorly maintained it is it seems to cause more
problems than it solves.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Peter Thomassen]

On 3/28/23 03:14, Shumon Huque wrote:

On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni mailto:ietf-d...@dukhovni.org>> wrote:

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
Can we at least state that domains with cyclic dependencies are a bad
idea, and may not be supported by all resolvers.  In other words, that
the domain owner can't **rely** on the sibling glue recommended to be
sent in this draft to save the day.

My strong preference is still to delete all reference in the draft to
cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
sibling glue primarily as a performance optimisation, and secondarily
as a last resort when the nameserver IP addresses are wrong or gone
from the authoritative zone (another bad practice).


Viktor - I've so far not seen many other people speak up in support of your
position. I suspect this is because this draft was discussed to death many
months ago during long discussion threads on the list, and there is likely
already rough consensus for the current content. Personally, I would be ok
with adding a statement that configurations involving cyclic dependencies
are not recommended, but others will likely have to also speak up in support
of this too.


I support adding such a statement about cyclic dependencies.

In addition, I would support saying that data suggests that, while (non-cyclic) 
glue records may have a benefit in certain cases, they frequently are a source 
of harm (time-outs), and the trade-off remains unclear.

FWIW, I hold this opinion because I find Viktor's numbers pretty convincing. 
However, as I've never operated a resolver, I'm convinced solely based on what 
I've read (to the best of my ability), not based on what I've experienced. 
Others' first-hand experience may be more material.

~Peter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Shumon Huque]

On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni 
wrote:

> On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> > The cyclic dependency based sibling glue (Section 2.3) is arguably
> > a bit of a corner case, and in past discussions some folks have expressed
> > the view that we shouldn't make accommodations to support it. I
> > think I can agree with that, but there were opposing views that we also
> > shouldn't break configurations that currently work. So it was left in.
>
> Can we at least state that domains with cyclic dependencies are a bad
> idea, and may not be supported by all resolvers.  In other words, that
> the domain owner can't **rely** on the sibling glue recommended to be
> sent in this draft to save the day.
>
> My strong preference is still to delete all reference in the draft to
> cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> sibling glue primarily as a performance optimisation, and secondarily
> as a last resort when the nameserver IP addresses are wrong or gone
> from the authoritative zone (another bad practice).
>

Viktor - I've so far not seen many other people speak up in support of your
position. I suspect this is because this draft was discussed to death many
months ago during long discussion threads on the list, and there is likely
already rough consensus for the current content. Personally, I would be ok
with adding a statement that configurations involving cyclic dependencies
are not recommended, but others will likely have to also speak up in support
of this too.

What should really happen is that broken sibling glue should be
> regularly purged from public suffix registries (probably requires
> gaining support for this in the RRR community more than IETF), and only
> then does the remaining valid sibling glue become more of a help than a
> hindrance.


Yes, I agree that this is the real area of work that could improve the
situation,
but probably outside of the scope of what the IETF can influence. If you
want
to organize an effort to do something about this in the ICANN/RRR community,
I suspect you might be able to recruit some of us into helping.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:

> > These “rare” cases where the domain is not resolvable when a glue is not
> > present are the ones this draft is done for. So did you look how rare
> > they were in your dataset? Being able to resolve instead of not resolving
> > IMHO has value even if the number is not big.
> >
> > We all know that a lot of data in the DNS is garbage, that should not
> > stop us from using the good data.
> 
> The cyclic dependency based sibling glue (Section 2.3) is arguably
> a bit of a corner case, and in past discussions some folks have expressed
> the view that we shouldn't make accommodations to support it. I
> think I can agree with that, but there were opposing views that we also
> shouldn't break configurations that currently work. So it was left in.

Can we at least state that domains with cyclic dependencies are a bad
idea, and may not be supported by all resolvers.  In other words, that
the domain owner can't **rely** on the sibling glue recommended to be
sent in this draft to save the day.

My strong preference is still to delete all reference in the draft to
cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
sibling glue primarily as a performance optimisation, and secondarily
as a last resort when the nameserver IP addresses are wrong or gone
from the authoritative zone (another bad practice).

What should really happen is that broken sibling glue should be
regularly purged from public suffix registries (probably requires
gaining support for this in the RRR community more than IETF), and only
then does the remaining valid sibling glue become more of a help than a
hindrance.

- Please, if at all possible, drop the cyclic dependency anti-pattern from the 
draft.

- The "right" justification for sibling glue (in the minority of cases
  that is is valid, by domain cardinality, though admittedly perhaps not
  a minority by query volume) is then lower latency/cost to reach a
  usable server.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Fri, Feb 17, 2023 at 01:55:40PM +0900, Masataka Ohta wrote:

> Viktor Dukhovni wrote:
> 
>  > The draft states that in rare cases sibling glue could be useful, as a
>  > result of cyclic dependency loops.
> 
> Interesting. Such dependency existed between two TLDs (IIRC
> "edu" and "org") 20 or 30 years ago and I thought and still
> think there are redundancy issues.
> 
> That is, the example in the draft is insufficient and, at least, the
> following should be an additional example:
> 
> bar.test.  86400   IN NS  ns1.foo.test.
> bar.test.  86400   IN NS  ns2.foo.test.
> 
> foo.test.  86400   IN NS  ns1.foo.test.
> foo.test.  86400   IN NS  ns1.bar.test.
> foo.test.  86400   IN NS  ns2.bar.test.
> 
> in which case, without sibling glue, if ns1.foo.test goes down, name
> resolutions of both zones become impossible, which should not satisfy
> minimum required redundancy of DNS.

This is a very weak argument, because the two domains need not be in the
same TLD, and then sibling glue never happens.  The sibling glue IMHO
accomodates corner cases that are marginal to careless.

> >  In late 2021 the authors analyzed zone file data available from
> >  ICANN's Centralized Zone Data Service [CZDS] and found 222 out of
> >  approximately 209,000,000 total delegations that had only sibling
> >  domain NS RRs in a cyclic dependency as above.
> 
> "only sibling domain NS RRs"?
> 
> If my examples above are considered, there should be more cases.

And yet, because it is particularly badly maintained, the overall
effect is IMHO negative.

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:

> The cyclic dependency based sibling glue (Section 2.3) is arguably a
> bit of a corner case, and in past discussions some folks have
> expressed the view that we shouldn't make accommodations to support
> it. I think I can agree with that, but there were opposing views that
> we also shouldn't break configurations that currently work. So it was
> left in.

Sure, a parent domain *may* serve sibling glue if it so chooses, but I
would not lump it in with a "glue is not optional" RFC.  This gives
sibling glue too much "weight", and sets expectations that it SHOULD
be used when provided, but I'd be inclined to downplay its importance,
and any expectation that it will save the day when all else fails.

> The case of normal (non-circular) sibling glue, described in Section
> 2.2 is in my opinion useful though, and also extremely common - where
> it isn't necessarily required for resolution but allows resolvers to
> obviate additional follow-on queries (to the same servers) to obtain
> the sibling glue.  Previous lengthy discussions on this topic indicate
> a consensus to retain them, but not mandate their inclusion (or set
> TC=1 if message size limits are exceeded).

Can we leave its availability and treatment as *unspecified*?  I don't
have a rock solid case for never sending it, but I do think we'd be
better of if as little as possible of it were in fact provided and as
few as possible relied on it.

> Note that this document does not place any requirements on DNS
> resolvers, so if a resolver implementer chooses to, they can ignore
> sibling glue in referral responses, and/or explicitly fetch them.

And so my take is that it is in fact "optional".

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Shumon Huque]

On Tue, Feb 21, 2023 at 5:50 AM Ralf Weber  wrote:

>
> These “rare” cases where the domain is not resolvable when a glue is not
> present are the ones this draft is done for. So did you look how rare
> they were in your dataset? Being able to resolve instead of not resolving
> IMHO has value even if the number is not big.
>
> We all know that a lot of data in the DNS is garbage, that should not
> stop us from using the good data.
>
> So long
> -Ralf
>

The cyclic dependency based sibling glue (Section 2.3) is arguably
a bit of a corner case, and in past discussions some folks have expressed
the view that we shouldn't make accommodations to support it. I
think I can agree with that, but there were opposing views that we also
shouldn't break configurations that currently work. So it was left in.

The case of normal (non-circular) sibling glue, described in Section
2.2 is in my opinion useful though, and also extremely common - where
it isn't necessarily required for resolution but allows resolvers to obviate
additional follow-on queries (to the same servers) to obtain the sibling
glue.
Previous lengthy discussions on this topic indicate a consensus to
retain them, but not mandate their inclusion (or set TC=1 if message
size limits are exceeded).

Note that this document does not place any requirements on DNS
resolvers, so if a resolver implementer chooses to, they can ignore
sibling glue in referral responses, and/or explicitly fetch them.

As far as bad data, I agree with Ralph. It shouldn't prevent us from
being able to use the good data. My employer has tons of domains that
use (working) sibling glue.

There was extensive discussion previously about incorrect glue,
and other types of issues ("orphaned glue"), and what could be
said to get registries/registrants to cleanup referral data in
zones. But we were strongly advised by folks deeply familiar with
TLD operations to not try to tackle that can of worms here. The
draft does make the following suggestion though: "The IETF may
want to consider a separate update to the requirements for including
glue in zone data, beyond those given in [RFC1034] and [RFC1035]."

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Tue, Feb 21, 2023 at 11:49:40AM +0100, Ralf Weber wrote:

> > This leaves 6,466 cases to examine more closely:
> >
> >1. 3,773 are in complete agreement with the authoritative A/
> >   records.
> >
> >2. 1,447 have authoritative A/ records completely distinct
> >   from the sibling glue.
> >
> >3. 1,414 return NXDOMAIN from the auth zone!
> >
> >4. 74 return NODATA from the auth zone for both A and !
> >
> >5. 213 return SERFAIL from the auth zone A and  lookups.
> >
> > Of the above, case "1" could perhaps reduce latency, but is otherwise
> > redundant (modulo exceedingly rare cyclic depedendencies).
> 
> These “rare” cases where the domain is not resolvable when a glue is not
> present are the ones this draft is done for. So did you look how rare
> they were in your dataset? Being able to resolve instead of not resolving
> IMHO has value even if the number is not big.

Sure, there is *almost* one loop:

tsort: -: input contains a loop:
tsort: frogsoft.org.
tsort: frogid-server.org.

In the form of:

frogsoft.org. IN NS frogid-server.org.
frogid-server.org. IN NS frogsoft.org.
frogid-server.org. IN NS atelier-frogsoft.org.
atelier-frogsoft.org. IN NS frogid-server.org.
atelier-frogsoft.org. IN NS ns344725.ip-37-187-251.eu.
;
frogsoft.org. IN A 37.187.251.101
frogid-server.org. IN A 213.186.33.5
atelier-frogsoft.org. IN A  5.39.70.108

but the loop is not fully closed, because the ".eu" NS host is live
and returns:

atelier-frogsoft.org. IN A 37.187.251.101

The remaining glue IPs are either timing out or returning REFUSED, so
again, on the whole, the glue is worse than nothing.

> We all know that a lot of data in the DNS is garbage, that should not
> stop us from using the good data.

Sure, if the garbage were harmless, but, more frequently than not, the
sibling glue is worse than ignoring it and resolving the nameserver
addresses explicitly.  The basic problem is that largely nobody is
minding the sibling glue, it just rots away, while "child-centric"
resolvers may do well by discarding it.

The case for resolving loops is particularly weak, perhaps someone
wants to instead motivate this based on the occasional success for
the otherwise non-resolving names?  (I am still not convinced...)

Let the domain owners fix the garbage.  We don't need to bend over
backwards serving muck just because some users are lazy.  That only
delays the inevitable breakage, nobody is minding the farm.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Ralf Weber]

Moin!

On 21 Feb 2023, at 6:32, Viktor Dukhovni wrote:
> This leaves 6,466 cases to examine more closely:
>
>1. 3,773 are in complete agreement with the authoritative A/
>   records.
>
>2. 1,447 have authoritative A/ records completely distinct
>   from the sibling glue.
>
>3. 1,414 return NXDOMAIN from the auth zone!
>
>4. 74 return NODATA from the auth zone for both A and !
>
>5. 213 return SERFAIL from the auth zone A and  lookups.
>
> Of the above, case "1" could perhaps reduce latency, but is otherwise
> redundant (modulo exceedingly rare cyclic depedendencies).

These “rare” cases where the domain is not resolvable when a glue is not
present are the ones this draft is done for. So did you look how rare
they were in your dataset? Being able to resolve instead of not resolving
IMHO has value even if the number is not big.

We all know that a lot of data in the DNS is garbage, that should not
stop us from using the good data.

So long
-Ralf
——-
Ralf Weber

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Thu, Feb 16, 2023 at 09:15:35PM -0500, Viktor Dukhovni wrote:

> There are many more.  We see a steady stream of sibling-glue-related
> lookup failures, that are only resolved after going to the authoritative
> source for the actual IP addresses of the nameservers in question.

I undertook a more comprehensive look, with the .ORG TLD as a case in
point.  There I find:

   1. 349,332 unique host objects with one or more A or  records.

   2. 80,427 are in-bailiwick nameservers of their domain.

   3. 6,466 are not nameservers of an ancestor .org name so only
  useful as "sibling glue".

   4. The remaining 262,575 appear to be garbage, detached from any .org
  delegation's nameserver name!  Why these are still in the zone is
  rather a mystery.

This leaves 6,466 cases to examine more closely:

   1. 3,773 are in complete agreement with the authoritative A/
  records.

   2. 1,447 have authoritative A/ records completely distinct
  from the sibling glue.

   3. 1,414 return NXDOMAIN from the auth zone!

   4. 74 return NODATA from the auth zone for both A and !

   5. 213 return SERFAIL from the auth zone A and  lookups.

Of the above, case "1" could perhaps reduce latency, but is otherwise
redundant (modulo exceedingly rare cyclic depedendencies).

So the question is whether in "2" the authoritative or sibling glue IPs
are in practice correct, and whether the auth A/ resolution failures
from "3", "4" and "5" are better served by the sibling glue.

To that end, I took a random sample of 20 sibling NS names.  These had
25 auth addresses and 21 sibling glue addresses.

Querying a domain each host is supposed to serve yields the below stats:

  AUTH | GLUE
+--|-
   LIVE | 8| 2
   LAME | 4| 0
TIMEOUT | 13   | 19

Of the 2 working sibling glue cases, one was also handled by the
corresponding auth IP.

So in this random sample, the sibling glue was only "better" 1 in 20
times, with 7 worse and the rest no difference (mostly timeouts).  So
far, this does not look like a compelling argument for serving sibling
glue...

For cases "3", "4" and "5" I took 20 random nameservers of each type,
for a total of 62 associated sibling glue IPs.  Querying each for
a name it is expected to serve the stats are:

NOERROR:  6
TIMEOUT: 44
REFUSED: 10
   SERVFAIL:  2

Again, the sibling glue is mostly no better than nothing, but ~10% of
the sampled cases worked out.

Overall, I think the world would be better served without the sibling
glue, the incentives to keep it accurate are poorly aligned.  As
suspected, where it differs from the authoritative data, it is almost
entirely junk.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Masataka Ohta]

Viktor Dukhovni wrote:

> The draft states that in rare cases sibling glue could be useful, as a
> result of cyclic dependency loops.

Interesting. Such dependency existed between two TLDs (IIRC
"edu" and "org") 20 or 30 years ago and I thought and still
think there are redundancy issues.

That is, the example in the draft is insufficient
and, at least, the following should be an additional
example:

   bar.test.  86400   IN NS  ns1.foo.test.
   bar.test.  86400   IN NS  ns2.foo.test.

   foo.test.  86400   IN NS  ns1.foo.test.
   foo.test.  86400   IN NS  ns1.bar.test.
   foo.test.  86400   IN NS  ns2.bar.test.

in which case, without sibling glue, if ns1.foo.test goes
down, name resolutions of both zones become impossible,
which should not satisfy minimum required redundancy
of DNS.

If zones have local redundancy policy to allow two or more (N)
name servers simuntaneously go down, which should be the cases
with zones having (N+1) name servers, more examples can be
constructed. For example:

   bar.test.  86400   IN NS  ns1.foo.test.
   bar.test.  86400   IN NS  ns2.foo.test.
   bar.test.  86400   IN NS  ns1.bar.test.

   foo.test.  86400   IN NS  ns1.foo.test.
   foo.test.  86400   IN NS  ns1.bar.test.
   foo.test.  86400   IN NS  ns2.bar.test.

suffers, if two in-zone name servers go down.


 In late 2021 the authors analyzed zone file data available from
 ICANN's Centralized Zone Data Service [CZDS] and found 222 out of
 approximately 209,000,000 total delegations that had only sibling
 domain NS RRs in a cyclic dependency as above.


"only sibling domain NS RRs"?

If my examples above are considered, there should be more cases.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Thu, Feb 16, 2023 at 09:15:35PM -0500, Viktor Dukhovni wrote:

> Perhaps we'll find that we can't distinguish sibling glue from still
> required "orphan glue" (mention of which I see got removed from
> draft-02), and need the sibling glue as a last resort when the forward
> lookup of the out-of-bailiwick name fails.  That would I guess be
> unforunate, because I'd much rather see all "unnatural" glue disappear
> from DNS delegation zones.

Actually, orphan glue is of course not a problem and not needed as
sibling glue, since as part of the parent domain's authoritative data it
is in fact easily resolved via an explicit query.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop