Unbound cache poisoning question
-
@cmb:
Since unbound is a resolver and not just a forwarder, can its cache be poisoned?
Yes. The means of doing so will vary depending on whether it's doing its own recursion or not, but for things that aren't DNSSEC-enabled (assuming you have DNSSEC enabled) it's still possible to cache poison.
If so if I have two isolated network segments with pfsense between them, could one end poison the cache such that things resolve incorrectly on the other?
In this circumstance, assuming there's a separate third interface WAN where all the DNS queries are resolved (which would be the case whether you're in forwarding mode or having unbound do recursion), no, neither of those networks can cache poison.
So in my scenario, I had DNSSEC and Forwarding mode off.
I have two networks, which in two different interfaces off pfsense and there's no communication between them.
Any issues with DNS are upstream, no chance something in Network A affected unbound such that it gave incorrect information to Network B? -
Any issues with DNS are upstream, no chance something in Network A affected unbound such that it gave incorrect information to Network B?
Correct. What it replies with when forwarding is off is the replies it obtains from the name servers of the domain in question. That should strictly be via WAN in that case (assuming you're not also using either of those LANs as an Internet connection), so neither LAN can affect that traffic.
-
@cmb:
Any issues with DNS are upstream, no chance something in Network A affected unbound such that it gave incorrect information to Network B?
Correct. What it replies with when forwarding is off is the replies it obtains from the name servers of the domain in question. That should strictly be via WAN in that case (assuming you're not also using either of those LANs as an Internet connection), so neither LAN can affect that traffic.
Nope, only the WAN provides the internet connection, as well as WAN is the only thing selected for "Outgoing Network Interfaces".
Which is even more worrysome as I've now had this issue with Google DNS and Level3 DNS.
And the only device between me and the internet is a modem (not even a wireless gateway, just a docsis3 modem w/ voice) -
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'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.