Re: [dns-privacy] [Ext] Common Features for Encrypted Recursive to Authoritative DNS

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: dns-privacy <[e-mail]> On Behalf Of Paul
> Hoffman
> Sent: Thursday, May 6, 2021 11:21 PM
> To: Ben Schwartz <bemasc=[e-mail]>
> Cc: DNS Privacy Working Group <[e-mail]>
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Common Features for Encrypted
> Recursive to Authoritative DNS
> 
> On May 3, 2021, at 2:06 PM, Ben Schwartz
> <bemasc=[e-mail]> 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
> <shollenbeck=[e-mail]> 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