Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been reading about the kaminsky DNS bug, trying to better understand how it works. I think I have the gist of it, but Dan mentions bailiwicks, being used to target DNS servers behind firewalls.

Can someone explain what a bailiwick is, and give an example of how it is used to target servers behind firewalls to exploit the kaminsky bug?

share|improve this question
This Linux Journal article has a good explanation of the bug, with emphasis on what part Bailiwicks play: – Ehtyar Jul 15 '09 at 0:47
up vote 3 down vote accepted


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
;; ANSWER SECTION:    120      IN    A

;; AUTHORITY SECTION:        86400    IN    NS        86400    IN    NS

;; ADDITIONAL SECTION:    604800   IN    A    604800   IN    A


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. '') is triggered.
  • The attacking server responds with a CNAME record for the domain its trying to poison (e.g. ''). This causes a DNS query from the target to ''.
  • As soon as the attacking server sends the CNAME referal it starts streaming in spoofed DNS responses that include an additional response (e.g. '' pointing to the IP address of '').
  • If the transaction Id in the response is correctly guessed, the server behind the firewall now thinks '' 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.

share|improve this answer
The fact that the DNS server is behind a firewall or not is irrelevant here: the attack works anyway. And your explanation is wrong since, precisely, is NOT in the bailiwick of The Linux Journal article you mention explains it correctly. – bortzmeyer Jul 20 '09 at 10:38
@bortzmeyer you're correct, I've missed a step in the attack. I think its correct now. – Luke Quinane Jul 21 '09 at 9:25

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 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.)

share|improve this answer

The bailiwick of a DNS server is the set of domains (or subdomains) it is authoritative for.

I'm not sure what firewalls have to do with the Kaminksy attack, other than possibly stomping on source port randomization with poor NAT/PAT implementations.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.