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