On Apr 18, 2005, at 1:35 PM, Chris Adams wrote:

...

Can you imagine what would happen if every time anyone ever looked up any hostname they sent out a DNS query?

That's what most Unix/Linux/*BSD boxes do unless they are running a local caching name service of some time (BIND, nscd, etc.). I wasn't actually aware that Windows had a DNS cache service.

Open a web browser, go to "foo.bar.com" for some hostname you own. Change the record on the authoritative server and clear the cache on the recursive NS. Reload the page. See if the browser goes to the new IP. Most desktop OSes do not re-query for the name again. Sometimes this is a browser issue. Sometimes it is an OS issue. Depends on too many variables to which, or both, is at fault in general. -- TTFN, patrick

On Apr 18, 2005, at 2:02 PM, Chris Adams wrote:

Once upon a time, Patrick W. Gilmore <patrick@ianai.net> said:

...

Most desktop OSes do not re-query for the name again.

Don't confuse apps and OSes. If I run "lynx", it does a DNS lookup for each connect (even when it is the same hostname).

I wasn't. Notice I said: "Sometimes this is a browser issue. Sometimes it is an OS issue." End of day, most OSes do cache DNS replies, and many apps further cache answers. -- TTFN, patrick

Aside from individual OS behavior, doesn't this seem like very bad advice? What sort of DNS cache poisoning attack could possibly work against a workstation that has a caching resolver but no DNS server? If a hacker really wished to do a name resolution attack against workstations, wouldn't they just write some spyware that injected a hosts file? Seems easier. At any rate, wouldn't disabling caching/not paying attention to TTLs have a truly adverse impact on the DNS infrastructure? What is the % difference in incremental DNS server load between a host that obeys TTLs and one that not, but makes a new query each time? A single host wouldn't have much impact - how about a couple million? Is there something I'm missing here that's motivating Yarden's advice? - Dan </head scratching> On 4/18/05 1:35 PM, "Chris Adams" <cmadams@hiwaay.net> wrote:

Once upon a time, Patrick W. Gilmore <patrick@ianai.net> said:

...

Depends on what you call "caching". Does honoring a TTL qualify as caching?

What other kind of DNS caching is there?

...

Can you imagine what would happen if every time anyone ever looked up any hostname they sent out a DNS query?

That's what most Unix/Linux/*BSD boxes do unless they are running a local caching name service of some time (BIND, nscd, etc.). I wasn't actually aware that Windows had a DNS cache service.

On Mon, Apr 18, 2005 at 03:05:55PM -0400, Jason Frisvold said something to the effect of:

On 4/18/05, Daniel Golding <dgolding@burtongroup.com> wrote:

...

Aside from individual OS behavior, doesn't this seem like very bad advice?

I think this is more of a question of who to trust. Caching, in general, isn't a bad thing provided that TTL's are adhered to. If the poisoning attack were to inject a huge TTL value, then that would compromise that cache. (Note, I am no expert on dns poisoning, so I'm not sure if the TTL is "attackable")

However, on the flip side, if nothing is ever cached, then I would expect a huge amount of bandwidth to be eaten up by DNS queries.

You are right. Time spent in security for an ISP yielded many DoS-against-the-DNS-server complaints that turned out to be some query-happy non-cachers pounding away at the server. The solution: block the querying IP from touching the DNS server. Somehow, I think that might have hampered their name resolution efforts...? ;) cache me if you can, --ra

I think a seasoned op knows when to use caching and when to not use caching, but the everyday Joe User has no idea what caching is. If they see a technical article telling them to turn off caching because it will help stop phishing attacks (which they know are bad because everyone says so), then they may try to follow that advice. Aside from the "I broke my computer" syndrome, I expect they'll be very disappointed when their internet access becomes visibly slower because everything requires a new lookup...

Is it possible to "prevent" poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value?

-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com

-- rachael treu gomes rara@navigo.com ..quis custodiet ipsos custodes?.. (this email has been brought to you by the letters 'v' and 'i'.)

* Mikael Abrahamsson:

If one had to repeate the cache poisoning every 10 minutes I guess life would be much harder than if you had to do it once every day?

Not necessarily, because every cache refresh is a new attack opportunity. 8-)

Mikael Abrahamsson wrote:

On Mon, 18 Apr 2005, Jason Frisvold wrote:

...

Is it possible to "prevent" poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value?

It would be very interesting in seeing the difference in DNS traffic for a domain if it sets TTL to let's say 600 seconds or 86400 seconds. This could perhaps be used as a metric in trying to figure out the impact of capping the TTL? Anyone know if anyone did this on a large domain and have some data to share?

First hand experience, I can tell you that decreasing the SORBS NS records TTLs to 600 seconds resulted in 90qps to the primary servers, increating the TTLs to 86400 dropped the query rate to less than 5 per second. (That's just the base zone, not the dnsbl NS records) Regards, Mat

* Jason Frisvold:

I think this is more of a question of who to trust. Caching, in general, isn't a bad thing provided that TTL's are adhered to. If the poisoning attack were to inject a huge TTL value, then that would compromise that cache. (Note, I am no expert on dns poisoning, so I'm not sure if the TTL is "attackable")

I'm not sure if you can poison the entire cache of a stub resolver (which can't do recursive lookups on its own). I would expect that the effect is limited to a particular DNS record, which in turn should expire after the hard TTL limit (surely there is one).

On Monday, 2005-04-18 at 22:08 ZE2, "Peter & Karin Dambier" <peter@peter-dambier.de> wrote:

Preventing poisoning attacks:

I guess most attacks are against windows workstations.

I'm not sure what you mean by this. Cache poisoning applies to machines that are doing caching. It can affect any machine that depends on that cache.

1) Hide them behind a NAT-router. If they cannot see them, they cannot attack them.

I certainly hope that this would not help. I hope that caching machines will not simply take a packet from a random address and source port 53 and use it to update their cache. I hope that the source address, source port, and destination port, at least, are checked to correspond to an outstanding dns query. If those all match, the packet will very likely get through a nat router. In other words, the nat router provides no protection from this attack at all. Why? Because it's an attack based on traffic that the natted machine has initiated.

2) Have your own DSN-server, root-server, authoritative server, cache.

You can have your own root-server: b.root-servers.net and c.root-servers.net as well as f.root-servers.net allow cloning. Just run your Bind 9 as a slave for "." . An authoritative server cannot be poisoned. Only resolvers can.

Certainly authoritative servers can be poisoned, but not for the domains that they're authoritative for. Running your own root only provides protection for the root zone. If I make a query for www.badguy.com and the auth. server for badguy.com returns an answer for www.yahoo.com in the additional data, if I cache it, I'm likely poisoned. That can happen even if I'm auth. for root. Tony Rall