> -----Original Message----- > From: Neil Cook <neil.c...@noware.co.uk> > Sent: Wednesday, November 27, 2019 7:48 PM > To: Konda, Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com> > Cc: Phillip Hallam-Baker <ph...@hallambaker.com>; dns-privacy@ietf.org > Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery' > > CAUTION: External email. Do not click links or open attachments unless you > recognize the sender and know the content is safe. > > > > > On 27 Nov 2019, at 14:09, Konda, Tirumaleswar Reddy > <tirumaleswarreddy_ko...@mcafee.com> wrote: > >> > >>> On 26 Nov 2019, at 17:35, Phillip Hallam-Baker > >>> <ph...@hallambaker.com> > >> wrote: > >>> > >>> So what I see is a requirement for DNS resolver configuration. We > >>> already > >> have rfc6763 to tell us how to get from a DNS label to an Internet service. > >> Albeit one that presupposes the existence of a resolution mechanism. > >> I don't see it being problematic to use the local DNS to do this > >> resolution provided that 1) we have the means to authenticate the > >> connection and 2) we only use this mechanism once, to perform initial > configuration. > >>> > >> > >> How will the connection to the local resolver be authenticated? Also, > >> presumably this mandates the use of DNSSEC by the client? > > > > The client can validate the server certificate signed by a CA, and it will > > work > for Enterprise deployments. However, it will be challenging for the DNS > forwarder co-located on the home router to get the certificate signed by CA > today but may be possible in future with ACME > https://tools.ietf.org/html/draft-ietf-acme-ip-08 and IPv6. > > > > If the client is connecting to the local resolver in order to bootstrap > finding a > DoH server, which is what the above proposal says, then it’s talking DNS53 > and there’s no authentication. Unless the resolver and client both support > DoT, in which case the server is still being contacted via IP address. If the > resolver is a forwarder on an RFC1918 IP address, like many/most home > routers, then authentication is a non-starter (I don’t see how the above draft > helps with that). > > So authentication would work in non-enterprise scenarios, assuming both > client and resolver/forwarder support DoT, and the resolver/forwarder is not > using an RFC1918 address.
Yup, we are in the same page. -Tiru > > > -Tiru > > > >> > >> Neil > >> _______________________________________________ > >> dns-privacy mailing list > >> dns-privacy@ietf.org > >> https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
