DNS not resolving some sites
-
Problem:
Hosts on my LAN cannot resolve "coder.show" Most other sites seem to be OK.
If I type "coder.show" (w/out the quotes of course) into https://192.168.1.1/diag_dns.php it resolves to the correct address.
My configuration is fairly vanilla except that I've configured to use Cloudflare DNS by using the following Custom options
server: forward-zone: name: "." forward-ssl-upstream: yes forward-addr: 1.1.1.1@853 forward-addr: 1.0.0.1@853
in https://192.168.1.1/services_unbound.php
Other settings are:
Network Interfaces: ALL
Outgoing Network Interfaces: WAN
System Domain Local Zone Type: Transparent
DNSSEC: Enabled
DNS Query Forwarding: disabled
DHCP Registration (Register DHCP leases in the DNS Resolver): Enabled
Static DHCP: enabled
OpenVPN Clients: disabledI'm pretty sure that Advanced Settings and Access Lists are unchanged from default.
I updated earlier today from 2.4.3 to 2.4.3_1 (which now identifies itself as 2.4.3-RELEASE-p1) and results are unchanged.
From the command line (on other PCs on my LAN) this host cannot be resolved.
hbarta@olive:~/Documents/purchase$ nslookup coder.show ;; Got SERVFAIL reply from 192.168.1.1, trying next server Server: 2601:249:e00:3813:201:2eff:fe6f:f9f9 Address: 2601:249:e00:3813:201:2eff:fe6f:f9f9#53 ** server can't find coder.show: SERVFAIL hbarta@olive:~/Documents/purchase$ nslookup coder.show 1.1.1.1 Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: coder.show canonical name = hosted.fireside.fm. Name: hosted.fireside.fm Address: 96.126.99.139 hbarta@olive:~/Documents/purchase$ nslookup coder.show 192.168.1.1 Server: 192.168.1.1 Address: 192.168.1.1#53 ** server can't find coder.show: SERVFAIL hbarta@olive:~/Documents/purchase$ nslookup google.com Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: google.com Address: 108.177.112.100 Name: google.com Address: 108.177.112.101 Name: google.com Address: 108.177.112.102 Name: google.com Address: 108.177.112.113 Name: google.com Address: 108.177.112.138 Name: google.com Address: 108.177.112.139
I'm baffled by what could cause this and how to proceed with debugging. I looked in the general and DNS logs and don't see anything that gives me a clue about what is going on.
Thanks for any suggestions.
-
Hi,
C:\Users\Réception-Gauche>nslookup coder.show Serveur : pfsense.brit-hotel-fumel.net Address: 2001:470:1f13:5c0:2::1 Réponse ne faisant pas autorité : Nom : hosted.fireside.fm Address: 96.126.99.139 Aliases: coder.show
Who is "192.168.1.1" ? make your DNS work on that device, because the PC where you are running nslookup was told to use it.
Note : it's ok to move from the default Resolver, and set up something different - using "8..8.8.8" or Cloudfare or whatever. But : finish the setup ;)
-
Hi,
Who is "192.168.1.1" ? make your DNS work on that device, because the PC where you are running nslookup was told to use it.
Note : it's ok to move from the default Resolver, and set up something different - using "8..8.8.8" or Cloudfare or whatever. But : finish the setup ;)
Sorry, I should have mentioned that the pfsense host is at 192.168.1.1 and it does resolve coder.show using the management web page https://192.168.1.1/diag_dns.php.
thanks,
hank -
Hi,
I have set up DNS resolver on pfsense and can see the same behavior. When I point my client to pfsense for DNS resolving, sometimes certain websites will not resolve. When I try the diagnostic option in pfsense the domain resolve just fine. I am not running anything particular like pfblocker or squid. Just basic pfsense with DNS resolver enabled. Logs don't show anything special. When I restart DNS resolver on pfsense everything is fine.
-
I would suggest you troubleshoot the specific fqdn your having issues with by looking at unbound has cached for this record and NS for that domain, etc.
Look to the unbound documentation on how to troubleshoot resolving issues.
If your just forwarding - then lack of resolution is out of your hands and you are at the mercy of who your forwarding to to correctly resolve something. And have no way to troubleshoot what their problem might be.
-
I would suggest you troubleshoot the specific fqdn your having issues with by looking at unbound has cached for this record and NS for that domain, etc.
Look to the unbound documentation on how to troubleshoot resolving issues.
Hi johnpoz,
Thank you for the suggestion. I bumped the log level by 1 for the resolver and found the following in the log when I tried the troublesome name.May 20 10:34:52 unbound 6706:3 info: Could not establish a chain of trust to keys for coder.show. DNSKEY IN May 20 10:34:52 unbound 6706:3 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:52 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: Could not establish a chain of trust to keys for coder.show. DNSKEY IN May 20 10:34:52 unbound 6706:2 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:2 info: reply from <.> 1.1.1.1#853 May 20 10:34:52 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: query response was CNAME May 20 10:34:52 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:52 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: query response was CNAME May 20 10:34:52 unbound 6706:2 info: reply from <.> 1.1.1.1#853 May 20 10:34:52 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:52 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:52 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: query response was CNAME May 20 10:34:52 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:52 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: query response was CNAME May 20 10:34:52 unbound 6706:2 info: reply from <.> 1.1.1.1#853 May 20 10:34:52 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:52 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:52 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: query response was CNAME May 20 10:34:52 unbound 6706:2 info: reply from <.> 1.1.1.1#853 May 20 10:34:52 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: query response was CNAME May 20 10:34:52 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:52 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:2 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:52 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:52 unbound 6706:3 info: query response was nodata ANSWER May 20 10:34:52 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:52 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: query response was CNAME May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: query response was CNAME May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: query response was nodata ANSWER May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: query response was nodata ANSWER May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: query response was CNAME May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: query response was CNAME May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: query response was nodata ANSWER May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: query response was nodata ANSWER May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: query response was CNAME May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:2 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: query response was CNAME May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:3 info: response for coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:2 info: validated DNSKEY show. DNSKEY IN May 20 10:34:51 unbound 6706:2 info: query response was ANSWER May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:2 info: response for show. DNSKEY IN May 20 10:34:51 unbound 6706:3 info: resolving coder.show. DS IN May 20 10:34:51 unbound 6706:3 info: validated DNSKEY show. DNSKEY IN May 20 10:34:51 unbound 6706:3 info: query response was ANSWER May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:3 info: response for show. DNSKEY IN May 20 10:34:51 unbound 6706:2 info: resolving show. DNSKEY IN May 20 10:34:51 unbound 6706:2 info: validated DS show. DS IN May 20 10:34:51 unbound 6706:2 info: query response was ANSWER May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:2 info: response for show. DS IN May 20 10:34:51 unbound 6706:3 info: resolving show. DNSKEY IN May 20 10:34:51 unbound 6706:3 info: validated DS show. DS IN May 20 10:34:51 unbound 6706:3 info: query response was ANSWER May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:3 info: response for show. DS IN May 20 10:34:51 unbound 6706:2 info: resolving show. DS IN May 20 10:34:51 unbound 6706:2 info: query response was ANSWER May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:2 info: response for coder.show. A IN May 20 10:34:51 unbound 6706:3 info: resolving show. DS IN May 20 10:34:51 unbound 6706:3 info: query response was ANSWER May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:3 info: response for coder.show. A IN May 20 10:34:51 unbound 6706:2 info: resolving coder.show. A IN May 20 10:34:51 unbound 6706:2 info: query response was CNAME May 20 10:34:51 unbound 6706:2 info: reply from <.> 1.0.0.1#853 May 20 10:34:51 unbound 6706:2 info: response for coder.show. A IN May 20 10:34:51 unbound 6706:3 info: resolving coder.show. A IN May 20 10:34:51 unbound 6706:3 info: query response was CNAME May 20 10:34:51 unbound 6706:3 info: reply from <.> 1.1.1.1#853 May 20 10:34:51 unbound 6706:3 info: response for coder.show. A IN May 20 10:34:50 unbound 6706:2 info: resolving coder.show. A IN May 20 10:34:50 unbound 6706:3 info: resolving coder.show. A IN
Can I presume that this is a DNSSEC misconfiguration somewhere along the line?
Can I also presume that the Diagnostics -> DNS Lookup page ignores the "Enable DNSSEC Support" setting on the Services -> DNS Resolver page? That would seem to explain why I can resolve from the diagnostics page but not from other hosts on my LAN?
One more bit of the puzzle… The problem may be intermittent. This is a podcast host. The podcast client on my phone did manage to update podcasts from this host some time overnight. It is configured to only update podcasts over WiFi and I don't think it associated with an outside AP during this time, though I cannot rule this out.
I've looked at https://dnslookup.org/coder.show/A/#dnssec and don't really understand the output. At the bottom left of the screen I see "Result is Insecure", but I see the same if I lookup google.com.
What should be my next step?
-
To be honest forwarding and dnssec is kind of pointless.. Your at the mercy of who you forward too do valid dnssec, etc.
There is more going on with coder.show than just an dnssec issue.. I show lots of warnings on that
coder.show/CNAME (NXDOMAIN): The server responded with no OPT record, rather than with RCODE FORMERR. (64.98.148.13, 216.40.47.26, UDP_0_EDNS0_32768_4096, UDP_0_EDNS0_32768_512) coder.show/CNAME (NXDOMAIN): The server returned CNAME for coder.show, but records of other types exist at that name. coder.show/CNAME: The server responded with no OPT record, rather than with RCODE FORMERR. (64.98.148.13, 216.40.47.26, UDP_0_EDNS0_32768_4096) coder.show/CNAME: The server returned CNAME for coder.show, but records of other types exist at that name. coder.show/NS: The server responded with no OPT record, rather than with RCODE FORMERR. (64.98.148.13, 216.40.47.26, UDP_0_EDNS0_32768_4096)
http://dnsviz.net/d/coder.show/dnssec/
I would suggest you try and contact them to FIX their mess..
-
@johnpoz Thanks for the further information. I have asked this question on the unbound mailing list and got the same answer. (I would have posted that here sooner but the site was offline before I left for the weekend and I was not able to log in until this morning.) The discussion on the mailing list can be seen at https://unbound.nlnetlabs.nl/pipermail/unbound-users/2018-May/005237.html
One of the responders on the mailing lists filed a bug report against unbound. (https://gitlab.labs.nic.cz/knot/knot-resolver/issues/359) I believe the "bug" is that unbound does not work well with misconfigured sites.
I have added exceptions in my configuration for the offending sites. I have also contacted the owner of the sites to notify them of the misconfiguration.
To be honest forwarding and dnssec is kind of pointless… Your at the mercy of who you forward too do valid dnssec, etc.
I would like to know more about your comment as I don't fully understand it. I'm expecting two benefits from DNSSEC. First the chain of trust will insure that my border device (running pfsense) will not somehow be spoofed into connecting to the wrong DNS server. (*) Second, my DNS queries cannot be snooped by a nosy ISP.
Incidentally I've blocked DNS (port 53) for hosts on my LAN to enforce the usage of the pfsense device for DNS service.
(*) I see an article about a possible BGP hijack on Hacker News this morning. https://news.ycombinator.com/item?id=17178905#17179014 Wouldn't DNSSEC prevent my device from connecting to a rogue DNS server?
-
dnssec has zero to do with your isp snooping..
dnssec just provides validation that your talking to the correct dns, and the records have been signed by them. When you forward you have your just asking who you forward to to provide you with what they have or what they will "resolve" or "forward" to get said answer.
You never actually talk to any authoritative ns for anything, be them signed or not - you never talk to roots to have the dnssec chain validated, etc. So in "theory" who you forward to could hand you anything and even show it validated with dnssec, etc.
If you want to validate the records you get then resolve, don't forward.
As to a bug with unbound not working with broken dns - how and the F is that a bug?? ;) I will have to read this bug report you linked too.
edit: How is that a bug against unbound?? Looks to be a bug with knot.. I didn't see any mention of unbound at all.. unless you mean where it says "breaks validating forwarders which point to kresd."
-
@hankb said in DNS not resolving some sites:
I would like to know more about your comment as I don’t fully understand it. I’m expecting two benefits from DNSSEC. First the chain of trust will insure that my border device (running pfsense) will not somehow be spoofed into connecting to the wrong DNS server. (*) Second, my DNS queries cannot be snooped by a nosy ISP.
This is what the resolver does. It uses the fastest root level (" . ") DNS servers, to drill down to the top TLD (like ".com") that send you over results, the name servers (at least 2 - or more) and these will finally handle your initial DNS request, like what is the A record of example.com.
If available, DNSSEC will be used.
If root level DNS servers and/or TLD level DNS servers are "hacked", then Internet as a businesses closes down right away.
If the name servers of example.com are hacked, well, contact the site admin, because he is running his own DNS, or using the ones offered by his host company. Stay away from example.com a while and you'll be fine. -
@johnpoz said in DNS not resolving some sites:
As to a bug with unbound not working with broken dns - how and the F is that a bug?? ;) I will have to read this bug report you linked too.
edit: How is that a bug against unbound?? Looks to be a bug with knot.. I didn't see any mention of unbound at all.. unless you mean where it says "breaks validating forwarders which point to kresd."
FWIW I did not (and would not have) filed the bug. And yes, I think you are correct. It is not against unbound but knot. I had not realized that.
thanks,
hank -
Here is the thing - their dns records are not correct... If they expect users to get to them then they need to fix their stuff.
Contact them and tell them to FIX it... Clearly its borked... I gave you as site that will validate all kinds of dns, etc. Just look yourself on any other dns checker - they all show that domain being borked!! With multiple problems... I show more problems now with bad glue, etc.
-
@johnpoz said in DNS not resolving some sites:
Here is the thing - their dns records are not correct... If they expect users to get to them then they need to fix their stuff.
Contact them and tell them to FIX it... Clearly its borked... I gave you as site that will validate all kinds of dns, etc. Just look yourself on any other dns checker - they all show that domain being borked!! With multiple problems... I show more problems now with bad glue, etc.
Yes, I have contacted them and I included the link to dnsvis which you kindly provided. I suggested that he forward that to his network engineer. Thing is, I may be the only one complaining. The network owner can resolve all of the hosts so it looks to him like nothing is wrong. Hopefully he will hand this off to someone who understands and can fix it.
thanks,
hank