Non-forwarding Resolver returns NS records only for some domains
I have a particular public hostname for which my DNS Resolver only returns NS records in the authority section. This exact same hostname resolves correctly with an A record when using Google, Cloudflare, etc. The pfSense resolver works correctly for almost all other hostnames I've tried. Pretty OOTB vanilla configuration of the resolver (no forwarding), except for DNSSEC. I tried turning that off and to no avail.
dig +trace to the local resolver gives reasonable results, including the A records, but without +trace only the NS records are returned.
I'm also using IPv4 + IPv6 dual stack on my LAN if that makes a difference -- and my ISP natively supports IPv6. I do notice that this particular hostname that is having problems does not have any AAAA records.
The domain I'm trying to resolve appears to not pass EDNS compliance tests at: https://ednscomp.isc.org/ednscomp
And when I use the unbound-control lookup tool with the hostname in question, I get "Delegation with 4 names, of which 0 can be examined to query further addresses." I think the EDNS non-compliance of the authoritative name servers for the domain in question is what is causing this -- but I've been having a really hard time trying to debug exactly what Unbound is doing (when I try to set the log verbosity to 5 and the lines retained to 2000 -- I still see nothing related to my query in the logs. And when I try to look at resolver.log directly I don't see anything there either -- it appears clog is yanking things out from underneath me.)
Can any Unbound gurus out there shed any light on debugging or whether this EDNS non-compliance theory holds water? If the latter is correct, is there anything I can set in Unbound to get it to relax its behavior with these non-compliant authoritative name servers?
Any Unbound gurus out there who can suggest how to force it to accept A records from a non-EDNS compliant authoritative server? Other DNS resolvers, like Cloudflare, don't appear to have an issue.
Trying to bump this one last time. Anyone?
KOM last edited by
@johnpoz, you alive?
Hey thanks for calling me @KOM this seems interesting - if your not ok with posting the exact domain your working with.. Please PM it to me and will take a look to what might be causing you grief with resolving.
What version of unbound are you using, are you on 2.4.4p2 or dev - they might have rolled out 1.9 unbound with new dev.. Not sure I don't keep up with the dev snapshots..
But yeah its possible the lack of edns compliance could be causing you grief - its not like these f'ers didn't have freaking notice ;) If you fail to resolve - then you would hope they fix their shit quick.. The lack of actually valid dns setups for major domains is sicking!!! ;)
Send me what your having issues with or post it and be happy to take a look see.
@johnpoz Netgate SG-3100 with pfSense 2.4.4-p2. I have PM'ed you with the specific host information.
Dude why would you think that should resolve - who puts rfc1918 in public space?
snipped.net. 60 IN A 10.60.1.24
snipped.net. 60 IN A 10.60.1.248
Yeah no shit that is not going to resolve with any normal resolve that does any sort of rebind protection..
That is just MORONIC! And the route 53 NS - to be honest, kind of SUCK!! They do not support dnssec, they are not edns compliant, etc. etc. They are always missing glue records for their AAAA NS, etc. etc..
But yeah that is going to fail using unbound in pfsense, because it does rebind protection - if you want that to resolve to 10.x - not sure how your going to get anywhere?? Is that local to you? Do you have some sort of vpn to them? etc..
You could turn off rebind protection, or set the domain as private in the custom options box in unbound.
To be honest that cloudflare or quad resolve it borked as well. They should be doing rebind protection as well.
Is this your domain? Or somewhere your trying to access? If yours - you do not put rfc1918 address in public space for them to resolve.. Its is always a borked solution to some unthought through problem.. If not yours and somewhere your trying to get to.. Contact them and ask them WTF they thinking! ;)
Geez -- don't know why I hadn't noticed that!! So yeah, these IPs are reachable across a VPN. And the VPN gateway is misconfigured to not send queries for hosts in that domain to the VPN's resolver. Sorry for wasting your time! (And no, I'm not the one who configured this.)
But why public resolvers (Cloudflare, Google and Quad9 all happily resolve the names to their private IPs) come back with anything is just whacked, I agree.
If you you need your vpn clients to resolve something that is rfc1918 that is fine.. Sure all day long... But you don't allow for public DNS to resolve rfc1918.. its Borked ;)
Why these be dns resolvers hand it back is beyond me.. They say they are wanting to protect clients against bad shit.. atleast quad9 says it does.. So why would it allow for something as basic as a rebind?
Maybe they think your local forwarder should be the one to protect you? Not sure.. But if your working with that company in any way - I would suggest you let them know its not good idea to have public resolve rfc1918.