> On 12 Aug 2020, at 10:25, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> > wrote: > > On Tue, Aug 11, 2020 at 6:18 PM Tony Finch <d...@dotat.at> wrote: > Ben Schwartz <bemasc=40google....@dmarc.ietf.org> wrote: > ... > > In this procedure, "all returned records" for follow-up queries are added > > to the Additional section. Therefore, there could be SOA records in the > > Additional section. > > I thought the target types were just A, AAAA, SVCB, so where does the SOA > come from? > > If one of the follow-up queries for those types returns NODATA, there could > be an SOA in the Authority section. "all returned records" includes all > sections, so it would be copied into the Additional section (in this > procedure).
The negative caching of NODATA/NXDOMAIN indication is tied directly the QNAME, QTYPE and rcode. In the Additional section there is such linkage. See RFC 2308. If I have "example.net SVBC 0 www.example.net” and “example.net SOA …” what exactly does the SOA record mean? There is no records at www.example.net? There is no SVBC record at www.example.net? There is no A or AAAA record at www.example.net? There is no CNAME at www.example.net? What if one can’t fit some of these RRsets but can fit a SOA? What happens when you know there isn’t a SVBC, have a A RRset and know nothing about AAAA? Do you add the SOA or leave it out? If you add it then what does it imply? If one wants to have negative answers, included in the additional section then I would suggest defining a EDNS option the returns <SOA Record sans class and rdlen><target name><rcode><typelist-if-nodata> for unsigned zones and NSEC/NSEC3 negative data proofs for signed zones and require clients to be DNSSEC aware. RFC 2308, while it doesn’t state it, only adds SOA records so non-DNSSEC clients/non-DNSSEC zones will get a cacheable response. There is enough information in the NSEC/NSEC3 proofs to maintain a negative cache entries if all clients where DNSSEC aware. > On Tue, Aug 11, 2020 at 6:38 PM Tony Finch <d...@dotat.at> wrote: > .... > > > It seems to me that returning a (downward) delegation could actually be > > useful. So why not include that? > > Additional section processing does not normally include referrals. > > Do you know why not? It seems like a logical thing to include, if you > predict that the resolver will be making a followup query for which you have > a delegation. > That > would be weird and new. I thought the point of the SVCB record was to > appear to existing auth and recursive DNS servers as much as possible like > a bog standard RR type, i.e. just wire and presentation format and a bit > of normal additional section processing. > > Is there a standard for "normal additional section processing"? My > impression is that it is RR-type-dependent, so defining what should go there > is in the purview of this draft. > > Which is basically what the draft > says now, though it unnecessarily respecifies additional section > processing. > > Yes, the intent is to work well with "normal additional section processing", > but Pieter and Brian requested some behaviors or clarifications in this > thread, related to CNAME and SOA records, that are either unclear or not > supported with "normal additional section processing". Hence this proposal, > which would leave us in the following position: > * Auths are not required to do any additional section processing > * Auths SHOULD do some kind of additional section processing, details > unspecified > * Auths MAY do this specific form of additional section processing, which > follows CNAME chains, enables negative caching, and (maybe) even provides > referrals when appropriate. > > Do you think this proposal would not actually work? Or do you think that it > is simply too inconvenient to implement? > > I would also like to hear Pieter's perspective, since the proposal is based > on his request in this thread. > > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ > Mull of Kintyre to Ardnamurchan Point: Variable, mainly north or northwest, 2 > to 4, occasionally 5 near the Mull of Kintyre and Tiree. Slight, occasionally > smooth in shelter, becoming slight or moderate later. Fog patches developing. > Moderate or good, occasionally very poor. > _______________________________________________ > 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
