Hi Paul,
My comments below:
1) Unless a DNS request for <reverse-ip>.{in-addr,ip6}.arpa/IN/RESINFO,
or a subdomain, as described in Section 2 is sent over DNS-over-TLS
(DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], or unless the
<reverse-ip>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
response is susceptible to forgery.
Comment> If the stub resolver is already using DoH with the recursive
resolver, why does it have to determine the URI template of the DoH server?
2) DHCP clients typically have no secure and trusted relationships to DHCP
servers, how will the client know it is communicating with the recursive
resolver hosted in the attached network ?
3)
In the future, DHCP and/or DCHPv6 and/or RA may have options that
allow the configuration to contain the domain name of a resolver. If
so, this can be used for matching the domain name in the TLS
certificate.
Comment> Same comment as above, Please see
https://tools.ietf.org/html/rfc8310#section-7.3.1
4) Any specific reason for picking I-JSON ?
5) The resolver information can also be provided in the server certificate
itself, for example see
https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1.
The
pros and cons of both approaches need to be discussed in the WG.
Cheers,
-Tiru
On Fri, 28 Jun 2019 at 00:14, Paul Hoffman <paul.hoff...@icann.org> wrote:
> Greetings. We have again updated draft-sah-resolver-information based on
> comments from this mailing list. We think that this is ready for adoption
> by the WG so that the initial use of the protocol (to be able to determine
> the URI template of the DoH server preferred by your current resolver) can
> move forward as well.
>
> --Paul Hoffman
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : DNS Resolver Information Self-publication
> Authors : Puneet Sood
> Roy Arends
> Paul Hoffman
> Filename : draft-sah-resolver-information-02.txt
> Pages : 9
> Date : 2019-06-27
>
> 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-sah-resolver-information/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-sah-resolver-information-02
> https://datatracker.ietf.org/doc/html/draft-sah-resolver-information-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-sah-resolver-information-02
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
