Use Domain Override to have a site resolve with google instead of Unbound?
-
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.
