ANN: DNS resolver changes in yakkety

Marc Deslauriers marc.deslauriers at canonical.com
Wed Jun 1 12:17:36 UTC 2016


On 2016-06-01 03:37 AM, Martin Pitt wrote:
> Stéphane Graber [2016-05-31 17:26 -0400]:
>> So yes, the random transaction ID sure helps, so long as it's actually
>> random and so long as you get a DNS reply reasonably quickly.
> 
> It's reading from /dev/urandom, so pretty much "as random as you can
> get".
> 
>> I think your estimate of a minute isn't anywhere near accurate. One
>> could pretty easily pre-generate all 32768 packets in pcap format, just
>> replace the source address and port once known and then inject the whole
>> pcap onto the network much much faster than that.
> 
> No, that doesn't work, as I explained in my other reply. You only have
> one shot and then have to wait for the cached entry to time out until
> you get another one. I. e. a chance of 1/65536 in say half an hour,
> which is much worse than having a chance every few minutes or seconds
> if the client does not cache DNS queries.

When the resolver gets the packet with the invalid transaction ID, the query is
cancelled, so it doesn't get cached at all.

> 
>>>> 1- a privacy issue. It is trivial for a local user to probe if a site was
>>>> visited by another local user.
>>>
>>> I assume by looking at the time that it takes to get a response?
>>
>> stgraber at dakara:~$ dig www.ubuntu.com @172.17.20.30
>> www.ubuntu.com.     600 IN  A   91.189.89.118
>>
>> stgraber at dakara:~$ dig www.ubuntu.com @127.0.0.1
>> www.ubuntu.com.     594 IN  A   91.189.89.118
>>
>>
>> The first query shows you the TTL for the record from the recursive
>> server used by the local resolver, here we see it's 600 seconds, the
>> second request hits the local cache which returns a TTL of 594 seconds.
>> Meaning that the DNS record was accessed by someone on the machine
>> within the last 6 seconds.
>>
>> Do that with some sensitive website and you can know when someone on the
>> machine accessed it.
>>
>> Note that the above wasn't done through resolved.
> 
> Exactly :-) So this is unrelated as dig doesn't use nsswitch and thus
> isn't affected by how we configure resolved.
> 
> However, you can still look at the time it takes. When I try this with
> a site that I haven't called in ages:
> 
>   $ time host www.cnn.com
>   www.cnn.com is an alias for turner.map.fastly.net.
>   turner.map.fastly.net has address 185.31.19.73
>   real	0m0.170s
> 
>   $ time host www.cnn.com
>   www.cnn.com is an alias for turner.map.fastly.net.
>   turner.map.fastly.net has address 185.31.19.73
>   real	0m0.155s
> 
>   $ time host www.cnn.com
>   www.cnn.com is an alias for turner.map.fastly.net.
>   turner.map.fastly.net has address 185.31.19.73
>   real	0m0.155s
> 
> So there is a measurable time difference when a lookup happens (the
> first time) and when it's cached (the two others).
> 
> However: as you demonstrated with dig, you don't necessarily need to
> get this information from the local resolver -- you can look at the
> TTL at the real DNS servers in /etc/resolv.conf with dig.

Assuming the real DNS servers are used by a large number of users, there is a
privacy difference in being able to tell if a user on the local machine has
visited a particular site versus being able to tell if any one of the large
number of users has queried the DNS server.

> 
> So, the current status is:
> 
>  1) I'm not convinced yet [1] that disabling caching helps against
>     injecting false responses. resolved implements enough of
>     https://tools.ietf.org/html/rfc5452 to make local attacks
>     impossible, and remote attacks actually harder than without a
>     cache.

I think hitting a transaction ID collision within a few seconds with a helper
machine is plausible. Whether caching is enabled or not is the difference
between poisoning your own lookups, or poisoning other user's lookups.

> 
>  2) I acknowledge the timing difference between recently visited and
>     unvisited addresses, but you can get the same information from
>     your real DNS server with more precision.

The real DNS server only allows you to determine if any of your ISP's users have
visited a site. That's quite different than knowing if any local user on a
multiuser machine visited a site.

> 
> Thanks!
> 
> Martin
> 
> P.S. This is a really enjoyable and good discussion, thank you!

Yes, it's quite interesting!

> 
> [1] Note, I don't claim "it's impossible", I'm just saying that the
>     current arguments aren't sufficient.
> 
> 
> 

Marc.




More information about the ubuntu-devel mailing list