> -----Original Message----- > From: dns-privacy <[email protected]> On Behalf Of Paul > Hoffman > Sent: Thursday, May 6, 2021 11:21 PM > To: Ben Schwartz <[email protected]> > Cc: DNS Privacy Working Group <[email protected]> > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Common Features for Encrypted > Recursive to Authoritative DNS > > On May 3, 2021, at 2:06 PM, Ben Schwartz > <[email protected]> wrote: > > Thanks for this draft; I think it's clear and could be a helpful > > introduction. > > > > > If the cache has no positive or negative answers for any DNS SVCB > > record for any of a zone's authoritative servers, the resolver needs > > to send queries for the DNS SVCB records for some or all of the > > zone's authoritative servers. > > > > I think it would be worth rephrasing the words "needs to" here. To me, > this sounds like a normative requirement to perform these queries, but I > suspect that's not what you mean. > > Good catch. In retrospect, this topic is actually not common between the two > use cases, so we'll take it out of the "common" document and expect each > protocol document to deal with what to do if the cache has no positive or > negative answers for any DNS SVCB record for any of a zone's authoritative > servers. > > > > Because some authoritative servers or middleboxes are misconfigured, > > requests for unknown RRtypes might be ignored by them. Resolvers > > should be ready to deal with timeouts or other bad responses to their > > SVCB queries. > > > > This sounds a bit pessimistic. Ralf Weber recently published some figures > showing a ~0.03% failure rate. For security (in the authenticated case), any > mitigations here are very delicate, and I'm a bit concerned about the brief > treatment here. (The SVCB draft has an extensive discussion: > https://secure-web.cisco.com/15G9BV5N6Ayfy89k3tshwvv0Hj- > zjPlc6kJw1CJqi6AgP3dFYb3rxKKH8mi4aa9YeME86836s0ekEY1nApKWIFnccrAv > IZEd6FCFj83J5RDOpPrUmu05qr8Q9AdovzfGTj7OCaECH7_kA7XdSfC_LW1Ldh > T68yxlKSrCBbonEKberR2w0XZ3FpPvQCuROK63spcmNV- > n3kzVu8JE663OkGbqoSrNiKazCnaj6b6to34xrxtNvrtC5Gk2vycrcfE4S- > IKD5bXC2IYoYt563cbwaibm- > zEtpU_H5WIMSebB9l0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtm > l%2Fdraft-ietf-dnsop-svcb-https%23section-3.1.) > > This was a leftover from earlier drafts, and you are right that this is > adequately covered in the SVCB draft itself. We'll remove it. > > > > DNS SVCB records act as advisory information for resolvers about the > > encrypted protocols that are supported. They can be thought of as > > similar to NS records on the parent side of a zone cut: advisory > > enough to act on, but not authoritative. Given this, authoritative > > servers that know the DNS SCVB records associated with NS records for > > any child zones MAY include those DNS SCVB records in the Additional > > section of responses to queries to a parent authoritative server. > > > > This sounds like a restatement of the definition of "glue". Can we simply > declare that these records are "glue"? > > We do not get to redefine a 30-year-old concept just because we have a new > shiny thang. We tried to say "treat similar to glue", and that wording could > maybe be improved. > > On May 4, 2021, at 5:28 AM, Hollenbeck, Scott > <[email protected]> wrote: > > > > [SAH] …and does this imply that we need to extend EPP to populate these > records? > > Wrong working group, Scott. :-) My personal opinion is that there are > mechanisms defined by DNSOP for child-to-parent communication that > would probably work much better than yet another REGEXT WG document.
[SAH] Asking the question here doesn't make this the wrong venue. If these records need to be treated like glue records, publication needs to be addressed _somewhere_. Once a preference is established, the specification work can be handed off to the appropriate WG. Scott _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
