DNS resolver "fails" but forwarding "resolves"
-
My pfSense out of box was configured to use DNS resolver service.
I needed to go to a website with a nic.in (technically second level) domain (if you do a google advanced search for nic.in site or domain, a series of India government websites will pop up).
pfSense would not resolve any one of them. Then I enabled "DNS Query Forwarding" (I tried OpenDNS and google, both work). Now these websites resolve fine.
I can think of 2 possible explanations for what's happening
- pfSense is not doing a good job of resolving these domains (so I should switch to forwarding permanently)
OR
- There's something messed up about these websites and pfSense is trying to protect me (so I should keep using pfSense as a resolver because forwarding is inherently less secure)
Which one is it and what's really happening? or is the truth something completely different?
thanks,
-
Hi,
Good news : nic.in resolves just fine using pfSense default DNS settings. At least, I guess, as I'm using the resolver using default setting (except the DHCP lease inclusion who could kill unbound's activities if you have a brain dead DHCP client).
Remember : the resolvers questions (one of) the Internet 13 root servers. If these can't be questioned by your network or network setting, all Internet will collapse.
Bad news : Your settings ... or some 'settings' above you (ISP ? - ISP router ? ) doesn't wasn't you to resolve ==access the main 13 impossible => that's bad.edit : nic.fr is IPv6 complaint.
@DrPhil said in DNS resolver "fails" but forwarding "resolves":
pfSense is trying to protect me
Except for the bogons list (list with IP that do not exist - make no sense ) pfSense behaves like the post office, or phone company.
It's sets up the communication and doesn't care what is communicated.@DrPhil said in DNS resolver "fails" but forwarding "resolves":
pfSense is not doing a good job of resolving these domains.....
That would be known - new - ....
But as showed above, not the case.Remember : even if you forward, to 'something', this something will wind up resolving.
unbound is rock solid for years. -
Yeah I can't replicate that either. Are you still seeing the issue? It may have been something temporary.
My first thought here was dnssec but it resolves for me with that enabled.
Something intercepting your DNS queries that breaks dnssec?
Steve
-
I just tried it again. The issue is still there. DNS resolver will only resolve it in forwarding mode.
And I can only observe this issue with nic.in
I did a google search on .in websites, and randomly tried a bunch of them (from top 10 on google). Everything resolves fine.
PS: I am fairly new to pfSense, so my settings are mostly default. I did try to install pfBlockerNG, but I wasn't able to make it work so I reverted to a previous version (and still had to delete pfBlocker). Could that have left a fragment that is misbehaving?
-
Did you try without DNSSec enabled?
-
@stephenw10 said in DNS resolver "fails" but forwarding "resolves":
Did you try without DNSSec enabled?
I hadn't. Now I did. And it works.
So I can access the website that I want either by disabling DNSSEC or by forwarding to OpenDNS. Is one of these two options better / safer?
-
Hmm, well the best option is find exactly what that DNSSec issue is and report it so it gets fixed.
Curious that I don't see a DNSSec issue testing from here.
You could try turning up the logging in Unbound so you can see the error when using DNSSec.
I won't pretend to be a DNS expert though.Forwarding to OpenDNS should be safe enough. You might want to consider a server that supports DNS over TLS and make use of that. It appears OpenDNS does not.
Steve
-
nic.in passes dnssec.
https://dnssec-analyzer.verisignlabs.com/nic.in
And btw opendns does dnssec out of the box... So if its working with opendns, they are automatically doing dnssec.. Most of the major public dns do.. google, quad9, cloudflare, etc.
Resolves just fine here... If its failing with unbound when you have dnssec on, then maybe your having an issue talking to something in the chain for dnssec.. Or something else wrong with your unbound.. Are you trying to do dot with unbound?
Here you can validate that opendns is actually doing dnssec out of the box.. see how this fails
$ dig @208.67.222.222 www.dnssec-failed.org ; <<>> DiG 9.16.5 <<>> @208.67.222.222 www.dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1597 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 55 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Sat Aug 22 09:29:38 Central Daylight Time 2020 ;; MSG SIZE rcvd: 50But if ask NS that is not doing dnssec it works.
So for example quad9 provides 9.9.9.10 that does no such testing.
$ dig @9.9.9.10 www.dnssec-failed.org ; <<>> DiG 9.16.5 <<>> @9.9.9.10 www.dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34406 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7200 IN A 68.87.109.242 www.dnssec-failed.org. 7200 IN A 69.252.193.191 ;; Query time: 68 msec ;; SERVER: 9.9.9.10#53(9.9.9.10) ;; WHEN: Sat Aug 22 09:34:43 Central Daylight Time 2020 ;; MSG SIZE rcvd: 82So while you might be having an issue resolve, its not bad dnssec for the fqdn in general.. Might be something wrong with your connection to actually validate the dnssec, or sure possible thing in your path trying to do interception of something that is causing you problem... You can normally test if something doing interception with a simple query to authoritative ns for a domain.
So example... Simple query to authoritative ns for netgate.com, when I query that directly since it is authoritative.. I should get back that flag showing it - see the aa listed..
I then setup pfsense to redirect dns to my pihole, this is sim to what say an isp would do in dns interception... I now query.. And what no aa flag, something wrong! Also notice that the authoritative ns set to send back lots of extra info.. But my pihole is not, so you can see the difference in what is returned.. That might not always be the case for sure not all NS send back that extra info, etc. But if your talking to an authoritative ns for a domain, they should for see the aa..
Now is this a smoking gun sort of test? No It could be possible I guess to send back aa, even when your doing interception.. But it for sure is a simple test to see if just basic interception is being done.. There are a few other ways to detect interception as well, but this is the easy simple quick way to test.. Just doing a query to any authoritative ns for domain its authoritative for should return the aa flag.. if you don't see that, then you didn't actually talk to the authoritative ns for that domain.
Another quick way to spot interception.. When you talk to authoritative ns you should always get back the full TTL.. If your getting back something that clearly is not at typical ttl.. Something is off, and you got that from cache.. When you talk directly to an authoritative NS, you will get back the actual ttl set on the record, not some counting down cached entry.
if you see the ttl going down, when you should be talking to the authoritative ns directly via subsequent queries, then yeah your not talking to the actual authoritative ns that is for sure.
-
@johnpoz, thank you. I am honored by such a thorough response.
For full disclosure, it's all Greek to me. I am not an engineer. I am just a suburban dad, trying to have a secure home network and have some control / tracking of my kids' internet activity. Until about a month ago, I had only ever run a router / wifi combo device (and I didn't even know there are devices that specialize in each function).
Is there a simple test that can tell whether this is a scenario that the software didn't envision (and should be accounted for), or it's an idiosyncrasy of my network (that the software should continue to ignore)? I am happy to run that for the sake of the community.
For my own need, forwarding to OpenDNS is perfectly acceptable.
-
@DrPhil said in DNS resolver "fails" but forwarding "resolves":
pfSense would not resolve any one of them.
And right now mine is not resolving it either. but it has nothing to do with dnssec, it has to do with there is no entry for nic.in any more. Not from google, not from opendns, not from the SOA even..
; <<>> DiG 9.16.5 <<>> @8.8.8.8 nic.in ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 379 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;nic.in. IN A ;; AUTHORITY SECTION: nic.in. 529 IN SOA nicnet.nic.in. nsadmin.nic.in. 2020082302 1800 600 1209600 14400 ;; Query time: 22 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Aug 23 06:04:02 Central Daylight Time 2020 ;; MSG SIZE rcvd: 86But there is for www.nic.in
$ dig www.nic.in ; <<>> DiG 9.16.5 <<>> www.nic.in ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20504 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.nic.in. IN A ;; ANSWER SECTION: www.nic.in. 3185 IN CNAME www.nic.in-v1.akamaized.net. www.nic.in-v1.akamaized.net. 21185 IN CNAME a1825.dscd.akamai.net. a1825.dscd.akamai.net. 3185 IN A 24.96.54.98 a1825.dscd.akamai.net. 3185 IN A 24.96.54.97can you resolve that?
BTW - posts are not always for the OP.. They are for the next guy as well.. The information I posted is basic understanding of how dns works.. Most users won't get it - but users of pfsense are normally not "most" users.. .
