Unbound cache poisoning question
-
I'm imagining by now you have enabled DNSSEC, removed all other DNS servers, purge DNS Cache everywhere, rebooted pfsense and checked to see if problem remains?
And the result is?
I've enabled DNSSEC, removed all but OpenDNS (so pfsense can still resolve and provide DNS), purged DNS Cache, and rebooted.
The problem isn't actively happening 100% of the time, so its very hard to test. I won't know if the problem remains until it starts happening again (if it happens again)
-
Why run OpenDNS? To test fate?
Do you believe they know something the root servers do not? -
Why run OpenDNS? To test fate?
Do you believe they know something the root servers do not?Ok, I've removed them all.
Let's see what happens now.
FYI " Do not use the DNS Forwarder as a DNS server for the firewall " was NEVER on. -
ONLY unbound, not in forwarder mode and with DNSSEC and nothing else.
Is there a reason you wish to have more than that running?
-
ONLY unbound, not in forwarder mode and with DNSSEC and nothing else.
Is there a reason you wish to have more than that running?
No, the DNS servers in general were left over from when I was using dnsmasq.
My settings now are DNSSEC on, Forwarder off, specific interfaces to respond on, WAN only in outgoing, and one custom host for an internal site, and DHCP and Static Registration on.
If it happens again, I know 100% it's upstream, though from what I've been told, it has to be.
But if it's upstream, what's the next step :\ -
http://en.wikipedia.org/wiki/Carrier_pigeon
-
http://en.wikipedia.org/wiki/Carrier_pigeon
Hmm, I tried that before. The transmission size was excellent, but the latency and packet loss left a lot to be desired.
-
Ultimately you will probably find that networks can only be trusted if they are limited to a LAN and there is no access to the internet.
I'm sure whatever measures I take to make things more secure are at best an annoyance to any well funded highly motivated agency, group of criminals or bored teen-age kid.
-
Ultimately you will probably find that networks can only be trusted if they are limited to a LAN and there is no access to the internet.
I'm sure whatever measures I take to make things more secure are at best an annoyance to any well funded highly motivated agency, group of criminals or bored teen-age kid.
For now I put 2 floating block rules against that whole subnet that the DNS gets redirected to. Hopefully even if the DNS gets messed with somehow still, it'll prevent people from trying to load those sites.
-
You can also block 0.0.0.0/0 and 0::0/0
That would do it for sure… (kidding)
Seriously though, I thing its fixed now.
-
You can also block 0.0.0.0/0 and 0::0/0
That would do it for sure… (kidding)
Seriously though, I thing its fixed now.
If it's fixed now, I still want to know what was happening to cause it….
-
If it's fixed now, I still want to know what was happening to cause it….
Based on what people have reported thus far, I'm thinking there is some successful cache poisoning happening against Google and Level 3's public DNS. By the nature of how such anycasted services work, it would probably be very hit and miss if it were successful on occasion. Not sure, as I haven't seen it happen myself, but there are enough reports and details within them here that show switching away from 8.8.8.8/8.8.4.4/4.2.2.2/4.2.2.1 fixes their issues that it appears the most likely cause. It's also possible someone's hijacking 8.8.8.0/24, 8.8.4.0/24, etc. routes in Internet BGP with some degree of success, but a glance at some BGP looking glasses makes that seem unlikely.
-
@cmb:
If it's fixed now, I still want to know what was happening to cause it….
Based on what people have reported thus far, I'm thinking there is some successful cache poisoning happening against Google and Level 3's public DNS. By the nature of how such anycasted services work, it would probably be very hit and miss if it were successful on occasion. Not sure, as I haven't seen it happen myself, but there are enough reports and details within them here that show switching away from 8.8.8.8/8.8.4.4/4.2.2.2/4.2.2.1 fixes their issues that it appears the most likely cause. It's also possible someone's hijacking 8.8.8.0/24, 8.8.4.0/24, etc. routes in Internet BGP with some degree of success, but a glance at some BGP looking glasses makes that seem unlikely.
So best practice here would be to simply not use those and have unbound strictly deal with the roots?
-
So best practice here would be to simply not use those and have unbound strictly deal with the roots?
Yes, less susceptibility to this type of thing in that case. Granted, what's apparently happening here should really never happen, but there have been instances of cache poisoning a number of times in the past with such DNS services.
-
If you see its the same domains that are always being affected then there may be a possibility that the NS's themselves have data that differs from one another.