Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt

From: Neil Cook <[email-masked]>
Date: Fri, 11 Oct 2019 14:41:00 +0100

I have some comments on this draft.

I’m particularly concerned about the extremely common use-case where a DNS proxy is used in front of the actual resolver; this is the case for many home routers/CPEs, particularly those provided by ISPs. They tend to give out DNS via DHCP on a private IP address e.g. 192.168.0.x, and then use dnsmasq (or homegrown software) to proxy to the actual resolver of the ISP located in the network on a public IP address.

TL;DR - there are two mechanisms defined in this draft. The first mechanism "Retrieving Resolver Information by DNS” seems like it would work ok with the above scenario. The second mechanism "Retrieving Resolver Information by Well-Known URI” would require changes to every CPE of the type described above, which IMO makes it unworkable for that scenario. (BTW for CPE insert any kind of DNS proxy/forwarder, which would have the same issue).

My main concern is that given that there are two mechanisms specified, clients may choose only to implement one of them. The draft doesn’t appear to specify that client authors must implement one or the other, or both. So I’d like to see the draft mandate that if only one of the mechanisms is implemented, it must be the "Retrieving Resolver Information by DNS” method.

I’d like to see the draft give due consideration to this very common use-case, (both CPEs and the more general case of DNS proxies/forwarders). 

A few additional comments which I think need to be considered:

- For the Well-Known URI mechanism by resolver IP, clearly private IP addresses can never get valid certificates, so even if CPEs were to implement this mechanism, they can never be authenticated.

- For the DNS method, given that a resolver never knows if DNS proxies are being used (in CPEs or elsewhere) or indeed what IP addresses are being used behind those proxies, I would imagine that at a minimum it would need to answer RESINFO queries for *all* RFC1918 addresses. This does then lead to the question, why include the IP address in the query at all? I assume the answer is “DNSSEC”, but see below for some more questions/comments on that.

- There is an acknowledgement "Erik Kline suggested using "<reverse-ip>.{in-addr,ip6}.arpa" as the
   domain name to allow for the possibility of DNSSEC-signed responses.”

I think it’s worth noting that RESINFO queries for private IP addresses will never be able to generate DNSSEC-signed responses. Also given the restriction "Authoritative servers MUST NOT answer queries that are defined in this protocol.” it seems unlikely that many resolvers would be capable of generating DNSSEC-signed responses, especially given that resolvers and authoritative servers tend to be completely separate entities these days.

This also begs the question, why create that restriction at all? Why must Authoritative Servers not answer those queries? The draft also states that "if the resolver can be configured to also be authoritative for some zones, it can use that configuration to actually be authoritative for the addresses on which it responds.” Which seems to contradict the previous MUST NOT - surely this is an implementation detail that should not be mentioned in an IETF draft?

Neil Cook

> On 19 Aug 2019, at 20:28, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>        Title           : DNS Resolver Information Self-publication
>        Authors         : Puneet Sood
>                          Roy Arends
>                          Paul Hoffman
> 	Filename        : draft-ietf-dnsop-resolver-information-00.txt
> 	Pages           : 9
> 	Date            : 2019-08-19
> 
> Abstract:
>   This document describes methods for DNS resolvers to self-publish
>   information about themselves, such as whether they perform DNSSEC
>   validation or are available over transports other than what is
>   defined in RFC 1035.  The information is returned as a JSON object.
>   The names in this object are defined in an IANA registry that allows
>   for light-weight registration.  Applications and operating systems
>   can use the methods defined here to get the information from
>   resolvers in order to make choices about how to send future queries
>   to those resolvers.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-information/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Neil Cook <[email-masked]>
Date: Mon, 28 Oct 2019 16:03:31 +0000

I was quite surprised that there was no reaction to my comments. Are they not worth replying to, or is there just not enough interest in this draft? 

Resolver discovery seems like such an important topic given what is happening with DoH and DoT, I can’t believe that folks aren’t interested in progressing this, and I think ensuring that it works for the extremely widely deployed use-case of a DNS proxy/forwarder is very important.

Neil

> On 11 Oct 2019, at 14:41, Neil Cook <[email-masked]> wrote:
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 28 Oct 2019 11:39:12 -0700

IIRC Ben Schwartz at the mic (Prague? Montreal?) mentioned he was
interested in seeing something like "traceroute but for DNS", which (a) is
what your described scenario sounds like to me and (b) is a
separate objective from this draft.  I think it's just...unrelated.  I
don't think we have DNS hop-by-hop -type semantics, which would make the
discovery of intermediate resolvers/forwarders easier.

On Mon, Oct 28, 2019 at 9:03 AM Neil Cook <[email-masked]> wrote:

> I was quite surprised that there was no reaction to my comments. Are they
> not worth replying to, or is there just not enough interest in this draft?
>
> Resolver discovery seems like such an important topic given what is
> happening with DoH and DoT, I can’t believe that folks aren’t interested in
> progressing this, and I think ensuring that it works for the extremely
> widely deployed use-case of a DNS proxy/forwarder is very important.
>
> Neil
>
> > I’m particularly concerned about the extremely common use-case where a
> DNS proxy is used in front of the actual resolver; this is the case for
> many home routers/CPEs, particularly those provided by ISPs. They tend to
> give out DNS via DHCP on a private IP address e.g. 192.168.0.x, and then
> use dnsmasq (or homegrown software) to proxy to the actual resolver of the
> ISP located in the network on a public IP address.
> >
> > TL;DR - there are two mechanisms defined in this draft. The first
> mechanism "Retrieving Resolver Information by DNS” seems like it would work
> ok with the above scenario. The second mechanism "Retrieving Resolver
> Information by Well-Known URI” would require changes to every CPE of the
> type described above, which IMO makes it unworkable for that scenario. (BTW
> for CPE insert any kind of DNS proxy/forwarder, which would have the same
> issue).
> >
> > My main concern is that given that there are two mechanisms specified,
> clients may choose only to implement one of them. The draft doesn’t appear
> to specify that client authors must implement one or the other, or both. So
> I’d like to see the draft mandate that if only one of the mechanisms is
> implemented, it must be the "Retrieving Resolver Information by DNS” method.
> >
> > I’d like to see the draft give due consideration to this very common
> use-case, (both CPEs and the more general case of DNS proxies/forwarders).
> >
> > - For the Well-Known URI mechanism by resolver IP, clearly private IP
> addresses can never get valid certificates, so even if CPEs were to
> implement this mechanism, they can never be authenticated.
> >
> > - For the DNS method, given that a resolver never knows if DNS proxies
> are being used (in CPEs or elsewhere) or indeed what IP addresses are being
> used behind those proxies, I would imagine that at a minimum it would need
> to answer RESINFO queries for *all* RFC1918 addresses. This does then lead
> to the question, why include the IP address in the query at all? I assume
> the answer is “DNSSEC”, but see below for some more questions/comments on
> that.
> >
> > I think it’s worth noting that RESINFO queries for private IP addresses
> will never be able to generate DNSSEC-signed responses. Also given the
> restriction "Authoritative servers MUST NOT answer queries that are defined
> in this protocol.” it seems unlikely that many resolvers would be capable
> of generating DNSSEC-signed responses, especially given that resolvers and
> authoritative servers tend to be completely separate entities these days.
> >
> > This also begs the question, why create that restriction at all? Why
> must Authoritative Servers not answer those queries? The draft also states
> that "if the resolver can be configured to also be authoritative for some
> zones, it can use that configuration to actually be authoritative for the
> addresses on which it responds.” Which seems to contradict the previous
> MUST NOT - surely this is an implementation detail that should not be
> mentioned in an IETF draft?
> >
> > Neil Cook
> >
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 28 Oct 2019 14:55:16 -0400

On Mon, Oct 28, 2019 at 2:40 PM Erik Kline <[email-masked]> wrote:

> separate objective from this draft.  I think it's just...unrelated.
>

I'm not sure that it's unrelated.  I hazily imagined something like an
"upstream" field in the RESINFO object, which contains the upstream
resolver's RESINFO object (etc.).  In other words, I think that use case
might be well-served by this design.

>   I don't think we have DNS hop-by-hop -type semantics, which would make
> the discovery of intermediate resolvers/forwarders easier.
>
FWIW, I've previously stated a preference for dropping the use
of ".well-known" entirely, and using draft-00's "resolver-info.arpa" name
instead of reverse-IP, in order to improve support for passive forwarders.
I understand this was changed in the hope of offering some kind of security
here with DNSSEC, but I think it's unlikely to work in practice, and we're
better off keeping things simple.

---

From: Neil Cook <[email-masked]>
Date: Tue, 29 Oct 2019 07:54:07 +0000

The scenario I describe isn’t about discovering intermediate resolvers, it’s about ensuring that you can use the described protocol to get the actual resolver info when there’s an intermediate resolver in the path. That can be achieved with the DNS-based mechanism in the draft, but not with the HTTPS-based mechanism.

Neil

> On 28 Oct 2019, at 18:39, Erik Kline <[email-masked]> wrote:
> 
> IIRC Ben Schwartz at the mic (Prague? Montreal?) mentioned he was interested in seeing something like "traceroute but for DNS", which (a) is what your described scenario sounds like to me and (b) is a separate objective from this draft.  I think it's just...unrelated.  I don't think we have DNS hop-by-hop -type semantics, which would make the discovery of intermediate resolvers/forwarders easier.
> 
> On Mon, Oct 28, 2019 at 9:03 AM Neil Cook <[email-masked] <mailto:[email-masked]>> wrote:
> > On 11 Oct 2019, at 14:41, Neil Cook <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> On 19 Aug 2019, at 20:28, [email-masked] <mailto:[email-masked]> wrote:
> >> 
> >> 
> >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-information/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-information/>
> >> 
> >> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-00 <https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-00>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-00 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-00>
> >> 
> >> 
> >> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >> 
> >> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> >> 
> > 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Neil Cook <[email-masked]>
Date: Tue, 29 Oct 2019 07:57:09 +0000

> On 28 Oct 2019, at 18:55, Ben Schwartz <[email-masked]> wrote:

> FWIW, I've previously stated a preference for dropping the use of ".well-known" entirely, and using draft-00's "resolver-info.arpa" name instead of reverse-IP, in order to improve support for passive forwarders.  I understand this was changed in the hope of offering some kind of security here with DNSSEC, but I think it's unlikely to work in practice, and we're better off keeping things simple.

I completely agree. I’d much rather see something like "resolver-info.arpa" instead of reverse-IP.

Neil

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Oct 2019 19:04:40 -0400 (EDT)

On Tue, 29 Oct 2019, Neil Cook wrote:

>       FWIW, I've previously stated a preference for dropping the use of ".well-known" entirely, and using draft-00's "resolver-info.arpa" name instead of reverse-IP, in order to improve support for
>       passive forwarders.  I understand this was changed in the hope of offering some kind of security here with DNSSEC, but I think it's unlikely to work in practice, and we're better off keeping
>       things simple.
> 
> 

Throwing DNSSEC under the bus for a "simpler" name seems rather
excessive. I for one would like to see DNSSEC in the reverse
support when possible. For a future where not everything is
chained to a single all-powerful LetsEncrypt root CA.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 Oct 2019 21:10:40 -0400

On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters <[email-masked]> wrote:

> instead of reverse-IP, in order to improve support for
> >       passive forwarders.  I understand this was changed in the hope of
> offering some kind of security here with DNSSEC, but I think it's unlikely
> to work in practice, and we're better off keeping
> >       things simple.
> >
> >
> > I completely agree. I’d much rather see something like
> "resolver-info.arpa" instead of reverse-IP.
>

The concern here is not "simplicity" as such.  The main concern is the
large fraction of devices whose configured DNS server is actually a
forwarder (usually with an RFC 1918 address).  Even if the actual recursive
implements RESINFO support, these devices will not be able to retrieve the
information, because they won't be querying the reverse address that the
recursive resolver thinks it owns.

This can be solved if the forwarder implements some sort of RESINFO query
rewriting, but it certainly won't work for the existing install base.  I
think this is the crux: should the upstream RESINFO be available through a
naive forwarder, or only through a forwarder that actively works to support
RESINFO?  I prefer the former, because I think serving the existing install
base is worthwhile.

I don't see significant value in DNSSEC for this application, because an
adversary who can forge DNS responses (the DNSSEC adversary) can also forge
DNS configuration messages (DHCP or RA).  What good does it do me to prove
that 1.2.0.192.in-addr.arpa is authentically publishing this RESINFO, if
the attacker forged the DNS configuration message that said 192.0.2.1?

---

From: Erik Kline <[email-masked]>
Date: Tue, 29 Oct 2019 18:32:42 -0700

> the attacker forged the DNS configuration message that said 192.0.2.1?

But this sounds more like you want to lookup RESINFO for resinfo.arpa with
some DNS hop count decrementing and get back a CNAME to the rev-addr
RESINFO record.

I don't know how we do DNS hop count decrementing, but it could be done by
convention (i.e. "0.resinfo.arpa", "1.resinfo.arpa", "2.resinfo.arpa",
...).  (But still, it just sounds like want you want is somewhat orthogonal
to/separable from what's discussed in this draft.)

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 Oct 2019 22:01:26 -0400

On Tue, Oct 29, 2019 at 9:32 PM Erik Kline <[email-masked]> wrote:

>>> >       passive forwarders.  I understand this was changed in the hope
>>> of offering some kind of security here with DNSSEC, but I think it's
>>> unlikely to work in practice, and we're better off keeping
>>> >       things simple.
>>> >
>>> >

That sounds pretty complicated.  What's the benefit over just serving
RESINFO on resolver-info.arpa?

> to/separable from what's discussed in this draft.)

FWIW, I think reverse-IP is just the wrong conceptual model here.  The stub
isn't asking abstract questions about the recursive resolver on some IP
address; it's asking for info about its current resolution setup.  I
mentioned RFC 1918 addresses as one case where this is clear.  For another
case, consider a recursive resolver whose behavior depends on the client IP
(e.g. OpenDNS filtering policy
<https://support.opendns.com/hc/en-us/articles/227988047-Web-Content-Filtering-and-Security>).
If filtering policies were encoded in RESINFO (as has been proposed), I
would expect OpenDNS's RESINFO response to depend on the exact client IP.
If you make this reverse-IP RESINFO query through a recursive resolver,
you'll get the wrong answer.  That's a _really_ weird RR.

Really, the whole concept of a QNAME doesn't apply to RESINFO, but unless
we start a new QCLASS I think hardcoding the QNAME to "resolver-info.arpa."
is about as good as we're likely to do.

---

From: Neil Cook <[email-masked]>
Date: Wed, 30 Oct 2019 09:15:20 +0000

> On 29 Oct 2019, at 23:04, Paul Wouters <[email-masked]> wrote:
> 

I’m certainly not against DNSSEC per-se. I do question what it’s actually being used for in this situation and if it could actually work the way it is currently specified. I’ve included my original comments on this below:

Neil

---

From: Brian Dickson <[email-masked]>
Date: Thu, 31 Oct 2019 16:26:37 -0500

Top-reply to highlight a question:
I think there may be a different rationale for using some of the novel
ideas that Ben and Neil have raised, and am wondering if putting those in a
different draft makes sense?

I think so, and am very interested in working on those. The current draft
can be useful for a subset of use cases (e.g. where not problems exist and
where security is desired), so they are not completely competing things.

In particular, I'm interested in a DNS-only approach, which provides more
information with traditional DNS RR types.

More noodling follows, about what/how etc, stuff that probably can go into
a potential new draft.

The goals of the alternate draft for resolver discovery, are (IMHO):

   - Work in backward compatible, incremental deployment scenarios
   - Provide signed (DNSSEC) information as much as possible
   - Handle clients moving between networks (laptops would be a
   typical client with these kinds of requirements)
   - Handle forwarders/resolvers with no public DNS name, and no public IP
   address, but ALSO handle forwarders/resolvers that have public DNS names
   and/or public IP addresses
   - Provide enough information to identify topologies and places where
   conflicts might first occur (especially overlapping DHCP/NAT addresses)
   - Enable clients to identify viable resolver choices that support
   requested transport and are directly reachable (e.g. DoT, DoH, UDP)

The basic nuts and bolts that IMHO would be required are:

   - A forwarder/resolver doing "this" would :
      - have a name for itself, that it already has been assigned (FQDN) or
      that it "picks" at random with local-only significance (high-entropy name
      to minimize collision risk, a la ULA in IPv6)
      - have a trust anchor for a domain at its name (either FQDN or picked
      name), used to DNSSEC sign data it self-publishes (including everything
      listed here)
      - publish the names and/or IP addresses of upstream resolvers (if it
      is a forwarder), or indicate that it is a resolver
      - publish which transport protocols it answers/serves (e.g. DoT, DoH,
      TCP, etc.)
      - publish the TLSA record for its name (FQDN or picked) if
      appropriate (DoT, DoH)
      - have a certificate (either self-generated/self-signed, or issued by
      another party) corresponding to the TLSA record, if appropriate (DoT, DoH)
      - be authoritative for a "well-known" name such as "resolver-id.arpa"
      that is a CNAME to its actual name (FQDN or picked name)
   - Upstream resolver/forwarder discovery would use queries for the above,
   for the configured/assigned resolver address
      - If the upstream is not doing "this", and is a forwarder, the query
      for "resolver-id.arpa" would be forwarded upstream
      - if the upstream is doing "this", all the information would be
      available to populate the "upstream" portion of the published data
      - If the next upstream forwarder doing "this" is NOT the immediate
      upstream, the "upstream" portion would have both the immediate upstream
      (IP) and the next "this" upstream
      - If any upstream forwarder returns NXDOMAIN, the upstream forwarder
      sequence ends at a resolver that does not do "this"
   - Each downstream forwarder would add all the information from the
   upstream to its set
   - The "tail end" forwarder would have an upstream "graph" of names
   and/or IPs, including whether the resolver(s) at the leaf nodes of the
   graph do "this", or not
   - Each leaf node can be evaluated as to whether it does "this", and
   whether it can be reached directly (important for DoT/DoH for network
   connections)
      - The leaf nodes are a "candidate set"; the set of leaf nodes
      directly reachable are the "resolver set". The resolver set may be empty,
      in which case client upgrade is not possible.
   - Changes that occur would require changes to the publication zone (at
   the FQDN or picked-name zone) including change to the SOA serial number.
   This would trigger re-signing, and would be learned by downstream nodes in
   the graph when TTL expires. TTL choice is important, as a result.

The benefits of this scheme include:

   - DNS traceroute
   - Identification of DHCP/NAT conflicts across resolver boundaries
   - If no conflicts occur, the largest possible set of resolvers providing
   $service would be discovered and could be used automatically
   - The discovery mechanism would involved DNSSEC-signed data, preventing
   MITM attacks against resolver selection/identification
   - DoT/DoH certificate validation would be supported even for
   forwarders/resolvers without public names or addresses
   - DNSSEC key rolls could be RFC 5011 compatible, even with these
   self-named resolvers
   - For FQDN-named resolvers, only the single DNS root trust anchor would
   be needed

IMHO, the implementation would not be overly complex, and most of the
operational performance issues are avoided for the discovery aspects
(occasional DNSSEC signing, but mostly just serving signed data in the
clear).
This would not itself alter the DoT/DoH service that a resolver does, it
would only facilitate the discovery/identification/validation steps in
establishing the DoT/DoH connection.

Comments welcome.
(I realize this might not work or scale, but if it does, I think it solves
a number of interesting and important problems for DoX deployment in
small/private environments, including possible consumer-grade devices with
upgraded software, or other methods of deploying/operating resolvers from
within such environments.)

Brian

On Mon, Oct 28, 2019 at 1:56 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

>>> I was quite surprised that there was no reaction to my comments. Are
>>> they not worth replying to, or is there just not enough interest in this
>>> draft?
>>>
>>
>>> > I think it’s worth noting that RESINFO queries for private IP
>>> addresses will never be able to generate DNSSEC-signed responses. Also
>>> given the restriction "Authoritative servers MUST NOT answer queries that
>>> are defined in this protocol.” it seems unlikely that many resolvers would
>>> be capable of generating DNSSEC-signed responses, especially given that
>>> resolvers and authoritative servers tend to be completely separate entities
>>> these days.
>>> >