On Jul 9, 2019, at 3:46 AM, tirumal reddy <kond...@gmail.com> wrote:
> 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?
One example is that the stub or browser may want to change DoH servers, such as
if it has discovered one that has a better security policy.
> 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 ?
It will not. This has always been the problem with DHCP, and efforts to make
DHCP authenticated have not borne fruti.
> 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 [tools.ietf.org]
That document does not preclude future configuration options. I don't see any
reason for this spec to do so.
> 4) Any specific reason for picking I-JSON ?
Absolutely. I-JSON is more likely to be interoperable than plain JSON: that's
why it exists. Given that the developers of the clients for this protocol will
be different than the developers of the servers, greater interoperability
should be an emphasis.
> 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
> [tools.ietf.org]. The pros and cons of both approaches need to be discussed
> in the WG.
Agree. If that document progresses, it will certainly have an effect on the
protocol proposed here.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
