4.3 NS Hijacking

Using ‘server blocking’ the attacker can ‘fix’ the target name server. If the attacker compromised that server then the attack is very damaging. Server fixing can be useful for other attacks too, e.g., to degrade efficiency (if the target server is the slowest), for traffic analysis, e.g., if the attacker has man-in-the-middle capabilities but only on the path to that ‘fixed’ server, but not to other servers for that domain.

Server fixing in tandem with DNS poisoning can allow the attacker to force the resolver to use a malicious name server which the attacker controls, we call this ‘NS hijacking’.

This attack is most relevant when DNSSEC is properly deployed.  
If the DNSSEC is not deployed correctly,  then the attacker can simply hijack the domain.

The attack is combined of two phases: (1) poisoning the A (or respectively NS) record in the DNS response (by changing the authentic IP to the IP controlled by the at- tacker), then (2) applying server blocking by ruining re- sponses from all other name servers so that the resolver marks those authentic servers as non-responsive.

Note that phase (2), i.e., server blocking, is not es sential and the poisoning attack by itself implies NS hi- jacking. This is due to the fact that the TTL of the poi- soned RR is higher than the TTL of the records cached from previous responses, therefore, once those authentic records expire from cache, the resolver will not request them and will use the poisoned cached NS RR.

As a result of this attack the resolver will only query the server of the attacker (as it is the only one that responds).

However, the attacker cannot produce valid signatures for the records that it returns, and therefore it responds to resolver’s queries with records that are not protected with DNSSEC.

This attack has the ‘cache-or-crash’ effect, i.e., the resolver will either cache those responses, or will timeout and not be able to provide responses (since this is the only name server that the resolver has for the victim domain).

The response depends on the specific resolver in question, e.g., Unbound 1.4.1 in permissive mode caches such responses, while Bind9 times-out and does not.