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 protected] 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/
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
