Latest version: 2.1.0
If NDPMon captures a Router Advertisement from a legitimate router (or believed so) but the params of the DNS options do not correspond to those stored in the router list, it may be an attack to redirect compatible host towards false DNS servers and malicious hosts or servers via bogus name resolution.
First, when a wrong RDNSS or DNSSL option is detected, a RA is sent with 0 lifetime to deprecate this wrong announce, via the derived countermeasures cm_kill_wrong_nameserver and cm_kill_wrong_domain. These 2 additional countermeasures follow the same politic and use the same guard as cm_propagate_router_dns.
Then, the counter measure reacts to this attack by sending a RA for the legitimate router with all parameters set according to those stored in the router list entry. We make the assumption that RA parameters are not re-configured by the administrator once NDPMon has finished it's learning phase.
This ensures that all compatible hosts listening on the link reset their DNS parameters to the intended ones.
This counter measure was tested with scapy6:
We have configured NDPMon to expect 2 nameservers fd75:7c74:2274:1::53 and fd75:7c74:2274:1::5353 with 900 seconds lifetime. When receiving the previous RA, NDPMon complained about an advertised nameserver different from what it learned during learning phase: