> On 8 Sep 2020, at 15:41, Ben Schwartz <[email protected]> wrote:
>
> Of course there are many questions that the draft makes no attempt to answer,
> including the question of how best to implement redirection.
I’m not sure how to take the above statement. The draft explicitly tries to
answer how to best implement redirection.
> However, I do not agree that there is an "apparent inconsistency", as the
> authors have previously discussed, e.g.
> https://mailarchive.ietf.org/arch/msg/doh/cH_kL3tjtOs-y_ZqRe2iQ5_P4TQ/
> <https://mailarchive.ietf.org/arch/msg/doh/cH_kL3tjtOs-y_ZqRe2iQ5_P4TQ/>.
From that email thread:
On Mar 31, 2020, at 2:03 AM, [email protected]
<mailto:[email protected]> wrote:
> I'm now more puzzled about the intent of the document with regards to
> redirection:
That's fine, and you are not alone. But the proper resolution of that
puzzlement is not an erratum, it is a document update.
--Paul Hoffman
>>
>> On server push, I think this draft contains a misunderstanding. RFC 8484
>> says that clients must not accept and use DNS records that were pushed from
>> some arbitrary server that is not the client's configured DoH resolver.
>> (That would obviously be unsafe.) It does not forbid accepting unsolicited
>> records that were pushed from the configured DoH server. (In some
>> configurations, unsolicited records of this type would live in a local HTTP
>> cache, invisible to the DNS client layer until a matching query is issued.)
>>
>
> That might be your understanding. It is not universal, hence the need for the
> clarification.
>
> I'm referring to the line "[RFC8484] does not ... clarify that unsolicited
> messages from a configured DoH server should be excluded". This seems
> backwards: the requirement does not exist, so there is nothing to clarify.
> In fact, such a requirement would be unimplementable in the cache
> architecture that RFC 8484 describes.
>
Actually that is a bug. It should say “not be excluded”.
> ...
>> I would encourage the authors to avoid assumptions about specific RR types,
>> and also to explain why CNAME or Alt-Svc is not sufficient for server
>> changes.
>
> The document goes into detail about why Alt-Svc is not sufficient - the first
> part of Section 5 as well as Appendix A.
>
> This explanation only goes one step, by noting that Alt-Svc requires the
> destination to be authoritative for the origin.
It also explains that Alt-Svc suffers from the bootstrapping problem, which is
discussed in multiple places in the draft.
> The question is: why do you need to redirect the user to a different origin?
> There's a hint about "redirecting the client to a locally administered DoH
> server", but I wasn't able to understand the motivation. What is the system
> architecture you are trying to enable, and why?
One of the original motivations was to enable redirection from a central DoH
server to a DoH forwarder running on e.g. a home router (in this case managed
and provided by the operator of the central DoH server). Thus you might start
off talking to “https://example.com/whatever <https://example.com/whatever>”
and you would be redirected to “https://cpe1234.example.com/whatever
<https://cpe1234.example.com/whatever>”. That’s why this draft was in the ADD
WG before dprive.
>>
>> This proposal seems to assume that there is only one DoH service on the
>> domain that is hosting this JSON file. This is not required by RFC 8484,
>> and is already false for some major deployments (e.g. NextDNS).
>>
>
> I’m not sure what you mean by this.
>
> DoH URIs are full URIs, not merely domain names, so there can be an unlimited
> number of DoH servers on a single domain, at different paths, with different
> behaviors. An example of an existing domain with this behavior is
> dns.nextdns.io <http://dns.nextdns.io/>, which has one such DoH path for
> every user. The proposed .well-known structure does not appear to support
> this configuration: it would collapse all these disparate paths onto a single
> destination template.
Yeah understood.
>> The 3XX proposal (Section 7) sends DNS records in the body of a 3XX
>> response. This is interesting but definitely unusual: "The server's
>> response payload usually contains a short hypertext note with a hyperlink to
>> the new URI(s)." [2]. Also, since following redirects is optional, a server
>> using this mechanism would risk losing any non-redirect-following clients.
>> That's acceptable if the query would otherwise have to fail, but needs to be
>> mentioned in the draft.
>>
>
> Surely any DoH server returning a 3XX would risk losing any
> non-redirect-following clients already, regardless of this draft?
>
> Yes, but the draft is encouraging servers to do this, so it needs a warning
> label.
>
> On Tue, Sep 8, 2020 at 7:43 AM Neil Cook
> <[email protected]
> <mailto:[email protected]>> wrote:
> Do you think that RFC8484 provides enough information for DNS client and
> servers to implement redirection in an interoperable way?
>
> Yes, insofar as it "might" work, which is all that can be said, since
> redirection itself is optional.
It “might" work isn’t enough to develop clients and servers that interoperate.
HTTP redirects are not designed for the situation where the redirect requires
DNS to function, but the DNS server itself is the service returning the
redirect.
If a redirection response is received by a DoH client, should it:
a) Lookup the required DNS records using the same DoH server? What if they lead
to further redirect responses?
b) Fallback to unencrypted DNS?
c) Something else?
RFC8484 says nothing on the above, hence the motivation for this draft.
>
> Is redirection necessary?
>
> I'm not aware of an important use case for redirection.
If nobody in this WG is convinced that DoH redirection is important enough to
work on, then that’s fine. But if this WG think that it’s important, then
RFC8484 is not enough IMO.
>
> If so do you have any other proposals for how it could be done?
>
> Servers can redirect any query except those needed to follow the redirect.
I’m not sure if that could be easily implementable in a DNS server (the
redirect might lead to a long chain of CNAMEs for example, and the server would
need to maintain state across queries), but I’d be interested to see if it
could be. If so, it would certainly be a more attractive approach.
>
> ...
> 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.
>
> As I noted, your proposal already breaks client-side DNSSEC validation, and
> would prevent use of the new HTTPS RR. The set of "glue-style" RRs that
> might be needed here is evolving, and may continue to evolve.
Sure, so using standard DNS encoding would address that.
Neil
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
