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 <pune...@google.com> wrote: > > On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews <ma...@isc.org> 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 > > > <puneets=40google....@dmarc.ietf.org> 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 <shu...@gmail.com> wrote: > > >> > > >> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett <m...@conundrum.com> > > >> wrote: > > >>> > > >>> > > >>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen <pe...@desec.io> 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 <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. > > >>> > > >>> > > >>> 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 > > > > > > _______________________________________________ > > > DNSOP mailing list > > > DNSOP@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > _______________________________________________ > > 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
