If anyone still wants changes to the -01 draft's text on Additional section processing by the Authoritative server ( https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-01#section-4.1), please reply. Otherwise, I'll assume that Mark and Tony's logic has been convincing, and we'll leave this as-is.
Personally, I think that text, which encourages Additional section processing and provides a hint about what's worth including, is sufficient, and we should be able to define improved answering strategies in a future draft if necessary. On Tue, Aug 11, 2020 at 9:31 PM Ben Schwartz <[email protected]> wrote: > > > On Tue, Aug 11, 2020 at 9:16 PM Mark Andrews <[email protected]> wrote: > >> >> >> > On 12 Aug 2020, at 10:25, Ben Schwartz <bemasc= >> [email protected]> wrote: >> > >> > On Tue, Aug 11, 2020 at 6:18 PM Tony Finch <[email protected]> wrote: >> > Ben Schwartz <[email protected]> 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? > > > It means "I completed this defined procedure so anything that's missing > doesn't exist". The recipient doesn't even need to look at the SOA RDATA; > it's just acting as a flag. The recipient _does_ need to know about the > procedure, but it's essentially the same as the recursive resolver followup > procedure in the next section. > > >> What if one can’t fit some of these RRsets but can fit a SOA? >> > > The proposal text says "If the server does not complete this procedure > (e.g. due to response size limits), it MUST remove any SOA records from the > Additional section." > > >> 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? >> > > I think support for AAAA is probably a prerequisite for implementing this > (optional) procedure. > > >> 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 > > > That seems like a fine solution to me, though it certainly would need a > separate draft. > > >> 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. >> > > FWIW, draft-ietf-svcb-https-01 already recommends this. > > >> > On Tue, Aug 11, 2020 at 6:38 PM Tony Finch <[email protected]> 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 <[email protected]> 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 >> > [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 <+61%202%209871%204742> INTERNET: >> [email protected] >> >>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
