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 <ma...@isc.org> 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 <pune...@google.com> 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 <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 > > -- > 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 -- 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
