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 

[DNSOP] FYI: SVCB and HTTPS RR and DNSSEC signing/validation

[Viktor Dukhovni]

Though this is in fact implicit in RFC4035 Section 6.2, it is perhaps
worth reminding any implementors reading this post (and though absurdly
late, perhaps even adding yet another minor tweak to the document) that
the target name of a SVCB or HTTPS record, though a domain name, MUST
NOT be canonicalised to lower case when signing or validating.

These names are of course (for largely the same reasons) also not
candidates for name compression.

I've seen some evidence that this point is not always obvious to
implementors rushing support for these out the door, and actual
mixed-case targets in signed zones to test against are exceedingly
scarce.  So it is easy to ship a non-interoperable implementation that
will only exhibit problems much later when sufficiently many zone owners
do decide to use mixed case target names for some cosmetic reason.

I am not expecting miracles in terms of document changes, so no flames
please, just do the right thing whatever that might be.  On the other,
if you are implementing or have recently implement support for signing
or validating SVCB/HTTPS records, please make sure that the input to the
hash for signing/validation is not case-folded.

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

[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