On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews <[email protected]> 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 <[email protected]> > > 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 <[email protected]> wrote: > >> > >> On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett <[email protected]> > >> wrote: > >>> > >>> > >>> On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen <[email protected]> wrote: > >>>> > >>>> > >>>> > >>>> On 3/28/23 03:14, Shumon Huque wrote: > >>>>> On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni <[email protected] > >>>>> <mailto:[email protected]>> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > > DNSOP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
