Use Domain Override to have a site resolve with google instead of Unbound?
-
Try this at a shell prompt:
rm /var/log/resolver.log
ls -l /var/log
Get the size of the other logs default is 511488
clog -i -s 511488 /var/log/resolver.log
chmod 600 /var/log/resolver.log
bounce unbound
Thanks! That did the trick! I had assumed that they were just ordinary text files but that makes a lot more sense haha.
Strangely enough….. now my DNS query return is different AND www.aviationweather.gov loads immediately with no problems... :o
The only thing I did different than the last post is accidentally screw up my resolver.log and then get it back up with Derelicts instruction.
Why would a log have any effect at all? Assuming it must have been something else but I can't imagine what? I had already restarted Unbound & rebooted the system a couple of times so that wasn't new.
dig is different now too:
bash@DESKTOP:~$ dig www.aviationweather.gov ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> www.aviationweather.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26880 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.aviationweather.gov. IN A ;; ANSWER SECTION: www.aviationweather.gov. 120 IN CNAME aviationweather.ncep.noaa.gov. aviationweather.ncep.noaa.gov. 7 IN CNAME aviationweather.cp.ncep.noaa.gov. aviationweather.cp.ncep.noaa.gov. 86107 IN A 140.90.101.207 ;; AUTHORITY SECTION: ncep.noaa.gov. 86107 IN NS ns-e.noaa.gov. ncep.noaa.gov. 86107 IN NS ns-mw.noaa.gov. ncep.noaa.gov. 86107 IN NS ns-nw.noaa.gov. ;; Query time: 115 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Mar 19 12:26:55 DST 2017 ;; MSG SIZE rcvd: 200 bash@DESKTOP:~$ dig ns-e.noaa.gov ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ns-e.noaa.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44300 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ns-e.noaa.gov. IN A ;; ANSWER SECTION: ns-e.noaa.gov. 86079 IN A 140.90.33.237 ;; AUTHORITY SECTION: noaa.gov. 86400 IN NS ns-e.noaa.gov. noaa.gov. 86400 IN NS ns-mw.noaa.gov. noaa.gov. 86400 IN NS ns-nw.noaa.gov. ;; ADDITIONAL SECTION: ns-e.noaa.gov. 86079 IN AAAA 2610:20:8000:8c00::237 ns-mw.noaa.gov. 86079 IN A 140.172.17.237 ns-mw.noaa.gov. 86079 IN AAAA 2610:20:8800:8c00::237 ns-nw.noaa.gov. 86079 IN A 161.55.32.2 ns-nw.noaa.gov. 86079 IN AAAA 2610:20:8c00:8c00::2 ;; Query time: 74 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Mar 19 12:27:23 DST 2017 ;; MSG SIZE rcvd: 228
-
It wasn't the log. It is probably just resolving for you now.
-
May never know what what going on, since you can not seem to grasp how to do a directed query.. In all the nonsense you posted.. Not one of them was a query to one of the NS authoritative for that domain…
Just like you query @yourpfsenseIP
Do you query direct to one of their NS.. as I did in my example.. And why and the F are you doing a query for "www.aviation.gov"
Glad its working for you - since troubleshooting to where the problem actual is with what your posting would be fruitless..
-
May never know what what going on, since you can not seem to grasp how to do a directed query.. In all the nonsense you posted.. Not one of them was a query to one of the NS authoritative for that domain…
Just like you query @yourpfsenseIP
Do you query direct to one of their NS.. as I did in my example.. And why and the F are you doing a query for "www.aviation.gov"
Glad its working for you - since troubleshooting to where the problem actual is with what your posting would be fruitless..
Eh, yeah. I have literally zero background in IT or anything computer or networking related. If I haven't read it for fun or been told something, I don't know it. So it doesn't surprise me I got it wrong, I do apologize though, I appreciate that you've taken your time out to help me.
I was querying aviationweather.gov because it's the only site that I've ever had trouble with, and the reason I started this thread.
EDIT: reading back I see you mean why i mistyped "aviation.gov" instead of "aviationweather.gov" and posted that output, that was totally unintentional, I was tired!I thought that the following was the Name Server for aviationweather.gov (which is what I assumed you meant by NS?)since it was listed in the return for aviationweather.gov, and start with "ns".
bash@DESKTOP:~$ dig ns-e.noaa.govI don't even know what you mean by this?
Just like you query @yourpfsenseIP
I think the only IP i queried was:
bash@DESKTOP:~$ dig 140.90.33.237Network information
IP address 140.90.33.237
Reverse DNS (PTR record) ns-e.noaa.govIs that what you mean?
I'd be happy to learn if you're willing to educate me, but I also totally understand if you're no longer interested.
Either way, thank you for taking your time and I apologize for the frustration. -
"dig 140.90.33.237"
All that did was query you default dns for that IP..
Thee are 3 NS listed for this domain.. If you want to ask them directly then you would use the @
So
dig @140.90.33.237 then what you want to ask it..
so
dig @140.90.33.237 www.aviationweather.gov
dig @140.90.33.237 www.aviationweather.gov
; <<>> DiG 9.11.0-P3 <<>> @140.90.33.237 www.aviationweather.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9718
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 7
;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.aviationweather.gov. IN A;; ANSWER SECTION:
www.aviationweather.gov. 120 IN CNAME aviationweather.ncep.noaa.gov.
aviationweather.ncep.noaa.gov. 300 IN CNAME aviationweather.cp.ncep.noaa.gov.
aviationweather.cp.ncep.noaa.gov. 86400 IN A 140.90.101.207;; AUTHORITY SECTION:
ncep.noaa.gov. 86400 IN NS ns-mw.noaa.gov.
ncep.noaa.gov. 86400 IN NS ns-nw.noaa.gov.
ncep.noaa.gov. 86400 IN NS ns-e.noaa.gov.;; ADDITIONAL SECTION:
ns-e.noaa.gov. 86400 IN A 140.90.33.237
ns-e.noaa.gov. 86400 IN AAAA 2610:20:8000:8c00::237
ns-mw.noaa.gov. 86400 IN A 140.172.17.237
ns-mw.noaa.gov. 86400 IN AAAA 2610:20:8800:8c00::237
ns-nw.noaa.gov. 86400 IN A 161.55.32.2
ns-nw.noaa.gov. 86400 IN AAAA 2610:20:8c00:8c00::2;; Query time: 35 msec
;; SERVER: 140.90.33.237#53(140.90.33.237)
;; WHEN: Mon Mar 20 05:19:59 Central Daylight Time 2017
;; MSG SIZE rcvd: 332 -
OK, thank you! It is once again not working for me.
bash@DESKTOP:~$ dig @140.90.33.237 www.aviationweather.gov ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @140.90.33.237 www.aviationweather.gov ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reachedI also attached the resolver log.
[dns resolver log.zip](/public/imported_attachments/1/dns resolver log.zip)
-
Well that dig command says you could not reach that NS
"connection timed out; no servers could be reached"
So its either down, or your isp is having issues talking to that network. I do not show any problems talking to any of them.. Try one of the 2 others ones..
ns-e.noaa.gov. 86400 IN A 140.90.33.237
ns-mw.noaa.gov. 86400 IN A 140.172.17.237
ns-nw.noaa.gov. 86400 IN A 161.55.32.2dig @140.90.33.237 www.aviationweather.gov +short
aviationweather.ncep.noaa.gov.
aviationweather.cp.ncep.noaa.gov.
140.90.101.207dig @140.172.17.237 www.aviationweather.gov +short
aviationweather.ncep.noaa.gov.
aviationweather.cp.ncep.noaa.gov.
140.90.101.207dig @161.55.32.2 www.aviationweather.gov +short
aviationweather.ncep.noaa.gov.
aviationweather.cp.ncep.noaa.gov.
140.90.101.207Simple solution would be prob to just put in a host override for www.aviationweather.gov to point to the IP 140.90.101.207, while they have a really short ttl 120 seconds, and then 300 seconds for that cname the IP has not changed since this thread has started 140.90.101.207..
edit: BTW I don't see anything in that log for aviationweather.gov
If you queried it directly unbound would not have any knowledge of that or log that..
-
Yeah it's down for me again. I don't get why I can't get to those DNS servers?
bash@DESKTOP:~$ dig @140.90.33.237 ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @140.90.33.237 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3772 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 77610 IN NS e.root-servers.net. . 77610 IN NS k.root-servers.net. . 77610 IN NS l.root-servers.net. . 77610 IN NS g.root-servers.net. . 77610 IN NS c.root-servers.net. . 77610 IN NS i.root-servers.net. . 77610 IN NS f.root-servers.net. . 77610 IN NS h.root-servers.net. . 77610 IN NS j.root-servers.net. . 77610 IN NS d.root-servers.net. . 77610 IN NS m.root-servers.net. . 77610 IN NS b.root-servers.net. . 77610 IN NS a.root-servers.net. ;; Query time: 0 msec ;; SERVER: 140.90.33.237#53(140.90.33.237) ;; WHEN: Tue Mar 21 10:55:07 DST 2017 ;; MSG SIZE rcvd: 239 bash@DESKTOP:~$ dig @140.172.17.237 ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @140.172.17.237 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41634 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 77590 IN NS e.root-servers.net. . 77590 IN NS k.root-servers.net. . 77590 IN NS l.root-servers.net. . 77590 IN NS g.root-servers.net. . 77590 IN NS c.root-servers.net. . 77590 IN NS i.root-servers.net. . 77590 IN NS f.root-servers.net. . 77590 IN NS h.root-servers.net. . 77590 IN NS j.root-servers.net. . 77590 IN NS d.root-servers.net. . 77590 IN NS m.root-servers.net. . 77590 IN NS b.root-servers.net. . 77590 IN NS a.root-servers.net. ;; Query time: 15 msec ;; SERVER: 140.172.17.237#53(140.172.17.237) ;; WHEN: Tue Mar 21 10:55:27 DST 2017 ;; MSG SIZE rcvd: 239 bash@DESKTOP:~$ dig @161.55.32.2 ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @161.55.32.2 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51936 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 77571 IN NS e.root-servers.net. . 77571 IN NS k.root-servers.net. . 77571 IN NS l.root-servers.net. . 77571 IN NS g.root-servers.net. . 77571 IN NS c.root-servers.net. . 77571 IN NS i.root-servers.net. . 77571 IN NS f.root-servers.net. . 77571 IN NS h.root-servers.net. . 77571 IN NS j.root-servers.net. . 77571 IN NS d.root-servers.net. . 77571 IN NS m.root-servers.net. . 77571 IN NS b.root-servers.net. . 77571 IN NS a.root-servers.net. ;; Query time: 15 msec ;; SERVER: 161.55.32.2#53(161.55.32.2) ;; WHEN: Tue Mar 21 10:55:46 DST 2017 ;; MSG SIZE rcvd: 239 bash@DESKTOP:~$ dig @140.90.33.237 www.aviationweather.gov +short ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @140.90.33.237 www.aviationweather.gov +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached bash@DESKTOP:~$ dig @140.172.17.237 www.aviationweather.gov +short ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @140.172.17.237 www.aviationweather.gov +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached bash@DESKTOP:~$ dig @161.55.32.2 www.aviationweather.gov +short ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @161.55.32.2 www.aviationweather.gov +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached bash@DESKTOP:~$ dig 140.90.101.207 ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> 140.90.101.207 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22888 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;140.90.101.207. IN A ;; AUTHORITY SECTION: . 3287 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017032102 1800 900 604800 86400 ;; Query time: 31 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Mar 21 10:57:50 DST 2017 ;; MSG SIZE rcvd: 118 -
If you can not get to those servers then yeah your not going to be able to resolve records they are authoritative for. And since the ttl they have on them are very short.. This problem is going to come up all the time..
Can you ping them??
-
No, I cannot ping them.
>ping 140.90.33.237 Pinging 140.90.33.237 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 140.90.33.237: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >ping 140.172.17.237 Pinging 140.172.17.237 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 140.172.17.237: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >ping 161.55.32.2 Pinging 161.55.32.2 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 161.55.32.2: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >ping 140.90.101.207 Pinging 140.90.101.207 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 140.90.101.207: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >ping 139.130.4.5 Pinging 139.130.4.5 with 32 bytes of data: Reply from 139.130.4.5: bytes=32 time=169ms TTL=114 Reply from 139.130.4.5: bytes=32 time=171ms TTL=114 Reply from 139.130.4.5: bytes=32 time=168ms TTL=114 Reply from 139.130.4.5: bytes=32 time=169ms TTL=114 Ping statistics for 139.130.4.5: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 168ms, Maximum = 171ms, Average = 169ms >ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=48ms TTL=60 Reply from 8.8.8.8: bytes=32 time=47ms TTL=60 Reply from 8.8.8.8: bytes=32 time=47ms TTL=60 Reply from 8.8.8.8: bytes=32 time=47ms TTL=60 Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 47ms, Maximum = 48ms, Average = 47ms >ping 4.2.2.2 Pinging 4.2.2.2 with 32 bytes of data: Reply from 4.2.2.2: bytes=32 time=15ms TTL=55 Reply from 4.2.2.2: bytes=32 time=14ms TTL=55 Reply from 4.2.2.2: bytes=32 time=14ms TTL=55 Reply from 4.2.2.2: bytes=32 time=13ms TTL=55 Ping statistics for 4.2.2.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 13ms, Maximum = 15ms, Average = 14ms -
well that is a bad test - I should of tried pinging them first before suggesting that.. they don't seem to answer ping.. But not having any problems doing dns queries to them..
-
Weird, it's in and out for me. I also have no issues with them when not using the resolver. I'll do the override and deal with it I suppose.
Thank you again for taking your time to help me out!
-
But you can plainly see using proper DNS diagnostic tools like dig that the problem is not in the resolver, but in the ability to reach their authoritative servers.
Maybe their name servers are overloaded because of the short-ass TTLs they're using.
It used to be bad form to use such short TTLs.
Still is, IMHO, for most anything but DDNS (which could be debated is no solution at all) and in advance of known, pending changes.
-
I would think such a site gets quite a bit of traffic.. Using 120 second ttl has got to just be crazy for the amount dns queries their servers are taking.. which then points to another cname - that has a ttl of 300.. Really freaking stupid if you ask me!!
And to top it all off that ending IP has not changed..
And then to top of that one of their IPv6 is just down..
Whoever is running their dns seems to be a sleep at the wheel..
You could try sending them a message here
https://www.aviationweather.gov/contact -
I was assuming that it worked when I don't use the resolver because public DNS has the IP cached already? Seems like doing a host override is basically doing the same thing until their IP changes?
Thanks, I will send them a message!
-
Yes using the forwarder would have you just get what they have cached.. But its going to have to be asking them ever 120 seconds as well ;)
Your going to get something shorter as your answer because it will come from their cache.. So see when I ask googledns the ttls on the records are something shorter then what the authoritative servers set them too. While if I ask one of the authoritative servers I get the full ttl to cache.
I don't see that site changing.. might as well just put in a override for it vs some domain override to ask google or opendns.. Since your just going to be asking them over and over again just like your doing with the authoritative servers your having problem talking too. While if you put in an override you can set the ttl to whatever you want so that clients just ask pfsense very X seconds..
I think the default host overrides are 3600 seconds. But you can always put in whatever ttl you want if you use the custome/advanced box to put in the record.
-
Very short TTLs are used for certain sites like akamai where they are used for additional load balancing and redundancy. On this type of site it's lunacy though, it's only going to bog down the authoritative servers that are most likely not very beefy this being a US government site.
-
Sure a CDN with thousands of servers and sites that point to multiple IPs in a round robin, etc. etc. They have a network to support such short ttls..
Look at the # of NS for just their parent domain
;; QUESTION SECTION:
;akamai.net. IN NS;; ANSWER SECTION:
akamai.net. 89805 IN NS zb.akamaitech.net.
akamai.net. 89805 IN NS ns3-193.akamaitech.net.
akamai.net. 89805 IN NS a12-193.akamaitech.net.
akamai.net. 89805 IN NS a22-193.akamaitech.net.
akamai.net. 89805 IN NS ns4-193.akamaitech.net.
akamai.net. 89805 IN NS a3-193.akamaitech.net.
akamai.net. 89805 IN NS zd.akamaitech.net.
akamai.net. 89805 IN NS a6-193.akamaitech.net.
akamai.net. 89805 IN NS a5-193.akamaitech.net.
akamai.net. 89805 IN NS zc.akamaitech.net.
akamai.net. 89805 IN NS ns2-193.akamaitech.net.
akamai.net. 89805 IN NS a1-193.akamaitech.net.
akamai.net. 89805 IN NS ns5-193.akamaitech.net.Here are the NS for just 1 subdomain
;; QUESTION SECTION:
;g.akamai.net. IN NS;; ANSWER SECTION:
g.akamai.net. 1000 IN NS n0g.akamai.net.
g.akamai.net. 1000 IN NS n1g.akamai.net.
g.akamai.net. 1000 IN NS n2g.akamai.net.
g.akamai.net. 1000 IN NS n3g.akamai.net.
g.akamai.net. 1000 IN NS n4g.akamai.net.
g.akamai.net. 1000 IN NS n5g.akamai.net.
g.akamai.net. 1000 IN NS n6g.akamai.net.
g.akamai.net. 1000 IN NS n7g.akamai.net.They know what they are doing ;) And I am quite sure they have tweaked and configured for optimal ttls and bandwidth for people looking up the shit they host on their networks, etc..
-
Thanks, I put in the override and all is well!
I also sent them a message and got a very quick response! It didn't make much sense to me but then I don't know what I'm talking about.
NCEP AWCWEB - NOAA Service Account ncep.awcweb@noaa.govOne key issue … is that the "www" is required to be properly resolved in the current WEB Farm.
http://www.aviationweather.gov/I am passing this along the the developers as well.
Meteorologist/WEB Development team
Aviation Weather Center
http://www.aviationweather.gov/You received feedback from:
Subject: Issues Accessing Website due to your DNS Server Settings
MessageI am having issues accessing www.aviationweather.gov and I believe that it is due to your DNS servers setup.
Specifically your DNS servers TTL is abnormally short, resulting in for more queries to your server than are necessary.
As a result my queries often time out and I cannot access aviationweather.gov to check weather for my flights.
You can see discussion and network testing of your DNS servers here: https://forum.pfsense.org/index.php?topic=127400.0
Please forward this to the relevant people and ask them to adjust your DNS server settings to be more efficient and reliable, thank you!/ncep.awcweb@noaa.gov -
well just some idiot passing it on.. The developers prob have zero to do with the dns most likely.. And its a given in your email to them you were using the www ;)
But hopefully it will work up the chain.
