Unbound and DNSSEC

ewhac

Last night, my sweetie was reporting that she couldn't visit PayPal; the Web site wasn't coming up properly. This apparently had been happening for a couple of days. I eventually discovered that www.paypalobjects.com wasn't resolving. There was also indirect evidence that pfSense itself was also having trouble contacting its own servers to check for available updates.

I have pfSense set up to use a local caching DNS resolver (unbound) that forwards requests to my ISPs DNS servers. dig-ing against various external DNS servers reported the correct entries for www.paypalobjects.com, but the local unbound server reported a failure.

After turning up the logging level, it looked like the DNSSEC entries for paypalobjects weren't validating correctly. I eventually found a thread on unbound's mailing list suggesting that unbound may be too strict in validating DNSKEYs, but the spec isn't entirely clear on how paranoid one should be. The bug report filed also mentions that a new config file setting for unbound may help with the issue, but which isn't exposed in the pfSense UI (too new?).

My DNS-fu is not strong, so I don't know whether I've configured unbound improperly, or if PayPal (and pfSense?) recently pushed out a botched set of DNSKEYs. I've temporarily patched the issue by turning DNSSEC validation off; PayPal and pfSense updates are now working. I don't want to keep it like this because obviously, but I'm wondering if anyone else has seen such issues, and how they addressed them. I'm running pfSense 2.3.2-p1.

johnpoz

I show some issues for the cnames related to that paypalobjects

CNAME to www.paypalobjects.com.edgekey.net

and dnssec, they don't have it setup.. But that does not stop the default unbound config with dnssec enabled from resolving it..

"I have pfSense set up to use a local caching DNS resolver (unbound) that forwards requests to my ISPs DNS servers."

That is not how pfsense is setup out of the box, out of the box unbound is in resolver mode - not forwarder mode. Once you put it into forwarder mode all bets are off for dnssec and where you forward to has to support dnssec.

I can tell you unbound using dnssec in resolver mode has no issues resolving that FQDN, even though some of domains that the cnames point to are not dnssec signed.

http://dnssec-debugger.verisignlabs.com/www.paypalobjects.com

ewhac

@johnpoz:

"I have pfSense set up to use a local caching DNS resolver (unbound) that forwards requests to my ISPs DNS servers."

That is not how pfsense is setup out of the box, out of the box unbound is in resolver mode - not forwarder mode. Once you put it into forwarder mode all bets are off for dnssec and where you forward to has to support dnssec.

Sorry; perhaps I misspoke. pfSense lists two DNS services; a DNS Forwarder and a DNS Resolver. I have the resolver enabled, and inside that I've enabled forwarding mode. I did it this way because I have a number of machines on my LAN to which I've assigned names and static IPs. I want these names to resolve locally so I can visit https://big-media-nas/ from any device in the house and have it work.

Again: No one on the LAN experienced any such issues until a few days ago, and up until then the pfSense setup hadn't been touched in months.

I can tell you unbound using dnssec in resolver mode has no issues resolving that FQDN, even though some of domains that the cnames point to are not dnssec signed.

http://dnssec-debugger.verisignlabs.com/www.paypalobjects.com

Again, my DNS-fu is not strong. Based on that page, would it be accurate to say the complete chain of trust hasn't worked its way all the way down to the content distribution farm(s)?

chrcoluk

my unbound forwards to a private dns server I run, which is also unbound with dnssec enabled.

I did used to in the past have the unbound on the router configured with dnssec but did find that was problematic, I found out by accident that having the forwarder dnssec enabled still gives dnssec security and with it disabled on the router's unbound nothing seems to break.

So I agree with the first reply that dnssec should only be turned on if the unbound itself is carrying out the dns lookups on the internet.

in the custom box in dns resolver settings you can add this line to change the unbound behaviour.

harden-algo-downgrade: no

can test with this url

https://dnssec.vs.uni-due.de/

johnpoz

"I have the resolver enabled, and inside that I've enabled forwarding mode. I did it this way because I have a number of machines on my LAN to which I've assigned names and static IPs. I want these names to resolve locally so I can visit https://big-media-nas/ from any device in the house and have it work."

Wanting to resolve local stuff has nothing to with unbound being in forwarder mode. Unless you want to forward to some internal NS that resolves those for you vs having pfsense resolve them either via dhcp/static entries or host overrides, etc.

Unbound is in resolver mode and I have no issues resolving local names.. Forwarder or Resolver mode is only for when it has to ask someone else for a fqdn that it does not know about.. So I ask it for say storage.local.lan - it knows about this and returns its IP. If it doesn't know storage.local.lan then it would either attempt to resolve - or it would forward that request. Once your in forwarder mode your at the mercy of who your forwarding to for dnssec..

I would agree with your statement that since some of the records involved in doing a query for that FQDN are not dnssec signed then no you do not have a full chain of dnssec.. But unbound default settings can still resolve because the zone the cname points to is not signed.. Can tell you for sure if your expecting to only resolve things that have dnssec enabled your going to have a hard time resolving a large portion of the internet ;)

Unbound with dnssec will resolve unsigned stuff just fine - what it wont do is return records that have a "broken" dnssec setup.. To resolve those you would need to reduce the security.. But to be honest if your going to take that step why even bother using dnssec in the first place ;) The whole point of using dnssec is to stop from resolving stuff that dnssec does not validate, ie broken. But if the domain has not setup dnssec at all then yeah out of the box unbound will resolve those fine.

The case of this is the domains the cname point to have not setup dnssec - its not that its an invalid or broken. Which if it was unbound would balk at for sure..

harden-algo-downgrade: <yes or="" no="">Harden against algorithm downgrade when multiple algorithms are
advertised in the DS record. If no, allows the weakest algo-
rithm to validate the zone. Default is no. Zone signers must
produce zones that allow this feature to work, but sometimes
they do not, and turning this option off avoids that validation
failure.

I would assume that since the default is NO, I don't see anything in the gui that suggest pfsense default has set this to yes. So not sure why you would need to add that as custom option? You can view the pfsense config of unbound here /var/unbound/unbound.conf

That setting is not in there with yes, so it would be its default of no.

The only harden entries I see in the conf are
harden-dnssec-stripped: yes
harden-glue: yes

harden-dnssec-stripped: <yes or="" no="">Require DNSSEC data for trust-anchored zones, if such data is
absent, the zone becomes bogus. If turned off, and no DNSSEC
data is received (or the DNSKEY data fails to validate), then
the zone is made insecure, this behaves like there is no trust
anchor. You could turn this off if you are sometimes behind an
intrusive firewall (of some sort) that removes DNSSEC data from
packets, or a zone changes from signed to unsigned to badly
signed often. If turned off you run the risk of a downgrade
attack that disables security for a zone. Default is on.

harden-glue: <yes or="" no="">Will trust glue only if it is within the servers authority.
Default is on.

As you can see from the attached going to that test site listed, I pass their dnssec test ;) That test shows if your dns is checking dnssec, does not test a specific domain or fqdn dnssec info - for that you can use the url I listed above for your paypalobjects.

dnssectest.jpg_thumb </yes></yes></yes>

chrcoluk

the test has nothing to do with the setting, it just tests if your dns lookups are dnssec enabled :)

I pass the test even tho unbound on my pfsense box has dnssec disabled.

Regarding the default setting of 'harden-algo-downgrade' it was at some point default enabled :) but there was a request to change the default, I was unaware they agreed to the request, so sorry for that. Of course setting it to no in the custom options box wont harm anything it would just anchor the no setting in place should the default change again.

ewhac

@chrcoluk:

So I agree with the first reply that dnssec should only be turned on if the unbound itself is carrying out the dns lookups on the internet.

So if unbound does full lookups from the root servers, DNSSEC works; but if I forward requests to my ISP's DNS server(s), DNSSEC may or may not work.

Should I ask my ISP about this? Or is DNSSEC simply designed to assume the client is performing all lookups from the root servers?

in the custom box in dns resolver settings you can add this line to change the unbound behaviour.
harden-algo-downgrade: no

I will give that a try; thank you.

@johnpoz:

Wanting to resolve local stuff has nothing to with unbound being in forwarder mode.

Right, but as a home user forwarder mode is the "polite" thing to do. Otherwise I'm hammering on the root servers for every uncached name.

chrcoluk

I cannot say if it will work when forwarding to another resolver, all I can say is in my own personal experience it was problematic.

johnpoz

"Otherwise I'm hammering on the root servers for every uncached name."

Huh? you should not be asking roots for your local stuff. Pretty sure the roots can handle a few queries from your home ;) Even if you fully loaded your upload pipe and it was gig they wouldn't even notice. It wouldn't even be a fly buzzing around their head sort of thing ;)

Keep in mind unbound will cache, your local machine will cache, your browser will cache. In the big picture even if your home had 1000's of devices and you had an unlimited pipe up you couldn't generate enough traffic for "roots" to even notice you..

I wouldn't worry that at all.. You do understand even when you forward to something - if they do not have it cached, they are going to have to ask roots anyway.. So your query for something that is not cached will still generate a query to "roots" So while if you were looking for something.domain.tld that someone else had asked the forwarder you would get a cache.. If nobody else had asked, its going to have to be resolved at some point. And roots will be involved..

kpa

@ewhac:

Right, but as a home user forwarder mode is the "polite" thing to do. Otherwise I'm hammering on the root servers for every uncached name.

Absolutely not. DNS is designed and implented to be used exactly like that and you're never going be able to cause any harm to the root servers with your low bandwidth home DNS resolver that only asks for the NS records of the top level domains from the root servers.