[dns-operations] new public DNS service: 9.9.9.9

[Mark Andrews]

And that ends up breaking things because a standard recursive server is not what all the clients are expecting to talk to.  You have to things like behaving like recursion is always on.  Passing through AXFR/IXFR to the original destination.  Passing through SIG(0) and TSIG signed requests to the original destination.  Some of this requires kernel help to pass the original destination to the intercepting server.

Most hotels nets get this terribly wrong because they just don’t understand the DNS well enough to do the job correctly.

Mark

> On 22 Nov 2017, at 5:49 am, Jared Mauch <jared at puck.nether.net> wrote:
> 
> 
> 
>> On Nov 21, 2017, at 11:25 AM, Ray Bellis <ray at isc.org> wrote:
>> 
>> On 21/11/2017 16:12, Stephane Bortzmeyer wrote:
>> 
>>> RTT measurement is also a good idea. If Google Public DNS suddenly
>>> gets much closer, it may mean Google added a server… or that your ISP
>>> hijacked 8.8.8.8
>> 
>> It was observed during RIPE that DNS lookups to F root from the Conrad
>> hotel's network were being intercepted, although traceroutes were not.
>> 
>> It was possible to observe this (among other means) by seeing that the
>> ping RTT was much higher than the DNS RTT.
>> 
> 
> Yup, it’s as easy as:
> 
> /sbin/iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 1.2.3.4
> 
> /sbin/iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to-destination 1.2.3.4
> 
> where 1.2.3.4 is your local resolver you want to intercept things with.
> 
> - Jared
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org