It's not what you access, it's what you block, since reverse DNS is not a good solution in this instance, you need to map the DNS block list to it's IP addresses and block those IPs, and readjust based on TTL, you'll end up blocking more stuff than intended, huge mess, but if you can't trust the DNS to be clean then that's one option to enforce a security policy when browsers are using DoH. This should probably go in draft-livingood-doh-implementation-risks-issues
Jacques >-----Original Message----- >From: Adam Roach <[email protected]> >Sent: March 20, 2019 2:15 PM >To: Jacques Latour <[email protected]>; Jared Mauch ><[email protected]>; Brian Dickson <[email protected]> >Cc: Ted Hardie <[email protected]>; DoH WG <[email protected]>; dnsop ><[email protected]>; paul vixie <[email protected]>; Michael Sinatra ><[email protected]>; Stephen Farrell <[email protected]> >Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator > >On 3/20/19 12:59 PM, Jacques Latour wrote: >> I'm trying to balance in my mind the requirements to protect the DNS >> vs. what is happening on the wire, in the end, the browser will >> connect to an IP address which can be (in most case) mapped to a >> domain name > > >I don't think this second assertion is true in 2019. See if you can make even a >first-order reasonable guess what I'm accessing at 172.217.1.129 or >23.227.38.32 or 52.40.19.98 or 216.105.38.15 or 104.20.1.85. > >(Hint: I took these all from sites I visit frequently, and none are >particularly >obscure sites) > >/a _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
