Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification

[Neil Cook <[e-mail]>]

> On 31 Aug 2020, at 07:50, Martin Thomson <[e-mail]> wrote:
> 
> I agree with Ben on all points (*) and would prefer to see none of the proposed amendments published.
> 

I think a broader question is necessary in response to this statement. Do you think that  RFC8484 provides enough information for DNS client and servers to implement redirection in an interoperable way? Is redirection necessary? If so do you have any other proposals for how it could be done?

> (*) I think that the push qualification is not necessary, but it is not as clearly a misunderstanding as Ben suggests.  It clearly limits this to configured URIs, which seems in line with original intent.
>  However, it likely denies access to server push in several cases, including after redirects.

I’m not sure it does, however some additional language to extend “configured URIs” to include followed redirects would suffice I imagine.

> 
> On Sat, Aug 29, 2020, at 00:41, Ben Schwartz wrote:
> [...]
>> The ".well-known" proposal (Section 6) does what RFC 8484 avoided 
>> doing: it proposes an alternative encoding of DNS records in JSON.
> 
> I would suggest that authors join the "resolver info" beauty contest.  The use of .well-known rather than (for example) a link relation is clearly inferior for the reasons Ben mentions.  But I tend to think that resource records are more appropriate for this particular application, as they work in more cases.

I understand the concern about encoding RRs; the glue records could be encoded as per a regular DNS response for example. However given that these are glue-style RRs, why would they need to extend beyond A and AAAA? This isn’t a general purpose proposal for encoding DNS records in JSON.

I welcome alternative proposals to using .well-known.

> 
>> The 3XX proposal (Section 7) sends DNS records in the body of a 3XX 
>> response.
> 
> A client that doesn't follow a redirect isn't much use, so the question for me is whether the client gets the extra info it needs.  It seems to me like clients will follow the redirect and discard any content.  That would lead to the extra stuff being dropped.  I would expect a DoH client to make a separate query if it needed more information to follow the redirect.
> 

Doing followup queries is one option, however if that also leads to redirect responses, then there is a major problem.

> A superior design would be to push necessary A/AAAA/CNAME records.  If the client makes a query that ends up at the pushed URI, then this will save time without having to invent novel handling for HTTP messages.
> 

The origin draft actually proposed using server push to push the necessary records. However it was taken out for various reasons, including perceived lack of support for server push in DNS clients.

Neil