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

[Paul Hoffman <[e-mail]>]

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://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-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.

--Paul Hoffman