kaminsky bug - bailiwicks

Bailiwick

The Linux Journal article that Ehtyar posted has a pretty good explaination of what a bailiwick is and how it relates to DNS. Basically, extra records are added to a DNS response to help find delegate DNS servers. To quote the example from the article:

$ dig @ns1.example.com www.example.com
;; ANSWER SECTION:
www.example.com.    120      IN    A    192.168.1.10

;; AUTHORITY SECTION:
example.com.        86400    IN    NS   ns1.example.com.
example.com.        86400    IN    NS   ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    604800   IN    A    192.168.2.20
ns2.example.com.    604800   IN    A    192.168.3.30

Attack

Details on the attack are in Dan's slides (see slides 24/25). To attack a server behind a firewall:

• A lookup for a subdomain of a domain the attacker controls (e.g. '1.badguy.com') is triggered.
• The attacking server responds with a CNAME record for the domain its trying to poison (e.g. 'debian.org'). This causes a DNS query from the target to 'debian.org'.
• As soon as the attacking server sends the CNAME referal it starts streaming in spoofed DNS responses that include an additional response (e.g. 'security.debian.org' pointing to the IP address of 'badguy.com').
• If the transaction Id in the response is correctly guessed, the server behind the firewall now thinks 'security.debian.org' resolves to the bad guy's address.

There are plenty of ways to get the server behind the firewall to lookup an IP address, internal client requests, resolving IP addresses in server logs, etc. As bortzmeyer mentions the firewall is largely irrelevant in this attack.

As mentioned by Mark Johnson, the bailiwick of a DNS server is the set of domains it is authoritative for. At a time, recursive name servers accepted out-of-bailiwick data from authorititative name servers. So, the name server authoritative for foo.example could add additional data in his answer stating the IP address of www.bar.example and he was believed. This was the basis of the Kashpureff attack. For a long time, name servers no longer believe out-of-bailiwick data, as instructed by RFC 2181, section 5.4.1.

The Kaminsky attack does not use out-of-bailiwick data and therefore worked with recent name servers as well. The Linux Journal article mentioned by Luke Quinane explains it very well (but the rest of the Luke Quinane's post, specially about firewalls, is questionable.)

Regarding firewalls, this is mostly an unrelated issue. If a name server wants to receive answers to its queries, it needs to be reachable so, whether it has a firewall or nor in front of it does not matter: the Kaminsky attack needs only one channel, the DNS one.

Since the Kaminsky attack is on the name server that client machines will use, whether these machines are protected or not by the firewall does not matter. (A good example of why a firewall is not a magic device and does not protect everything.)