It looks to me, when querying Belkin's setup directly, they are returning RR A records. (Please pay attention to the "QUESTION SECTION" below, as it's going to become relevant): $ dig @a.gtld-servers.net ns belkin.com. ;; QUESTION SECTION: ;belkin.com. IN NS ;; AUTHORITY SECTION: belkin.com. 172800 IN NS ns1.p06.dynect.net. belkin.com. 172800 IN NS ns3.p06.dynect.net. belkin.com. 172800 IN NS ns2.p06.dynect.net. belkin.com. 172800 IN NS ns4.p06.dynect.net. $ dig @ns1.p06.dynect.net a heartbeat.belkin.com. ;; QUESTION SECTION: ;heartbeat.belkin.com. IN A ;; ANSWER SECTION: heartbeat.belkin.com. 3600 IN A 54.87.220.73 heartbeat.belkin.com. 3600 IN A 54.242.182.61 heartbeat.belkin.com. 3600 IN A 54.161.217.33 heartbeat.belkin.com. 3600 IN A 54.163.72.1 heartbeat.belkin.com. 3600 IN A 54.163.87.225 heartbeat.belkin.com. 3600 IN A 54.163.115.57 heartbeat.belkin.com. 3600 IN A 54.87.180.46 heartbeat.belkin.com. 3600 IN A 54.163.74.132 heartbeat.belkin.com. 3600 IN A 54.227.172.225 heartbeat.belkin.com. 3600 IN A 174.129.92.187 heartbeat.belkin.com. 3600 IN A 54.196.247.165 heartbeat.belkin.com. 3600 IN A 23.20.47.97 heartbeat.belkin.com. 3600 IN A 54.83.179.150 And here's the SOA -- note the serial (it's in YYYYMMDDxx notation): $ dig @ns1.p06.dynect.net soa belkin.com. ;; QUESTION SECTION: ;belkin.com. IN SOA ;; AUTHORITY SECTION: belkin.com. 3600 IN SOA ns1.p06.dynect.net. DNSDomainAdmin.belkin.com. 2010071117 3600 600 604800 3600 However using 8.8.8.8 doing the exact same queries doesn't return RR A, it only returns a single record: $ dig @8.8.8.8 ns belkin.com ;; QUESTION SECTION: ;belkin.com. IN NS ;; ANSWER SECTION: belkin.com. 21010 IN NS ns4.p06.dynect.net. belkin.com. 21010 IN NS ns1.p06.dynect.net. belkin.com. 21010 IN NS ns2.p06.dynect.net. belkin.com. 21010 IN NS ns3.p06.dynect.net. $ dig @8.8.8.8 a heartbeat.belkin.com ;; QUESTION SECTION: ;heartbeat.belkin.com. IN A ;; ANSWER SECTION: heartbeat.belkin.com. 8336 IN A 67.20.176.130 Change the query type to ANY (rather than A) and suddenly: $ dig @8.8.8.8 any heartbeat.belkin.com ;; QUESTION SECTION: ;heartbeat.belkin.com. IN ANY ;; ANSWER SECTION: heartbeat.belkin.com. 3195 IN A 23.20.47.97 heartbeat.belkin.com. 3195 IN A 54.163.72.1 heartbeat.belkin.com. 3195 IN A 54.227.172.225 heartbeat.belkin.com. 3195 IN A 54.161.217.33 heartbeat.belkin.com. 3195 IN A 54.87.180.46 heartbeat.belkin.com. 3195 IN A 54.163.74.132 heartbeat.belkin.com. 3195 IN A 54.196.247.165 heartbeat.belkin.com. 3195 IN A 54.242.182.61 heartbeat.belkin.com. 3195 IN A 54.83.179.150 heartbeat.belkin.com. 3195 IN A 54.163.87.225 heartbeat.belkin.com. 3195 IN A 54.87.220.73 heartbeat.belkin.com. 3195 IN A 54.163.115.57 heartbeat.belkin.com. 3195 IN A 174.129.92.187 $ dig @8.8.8.8 soa belkin.com. ;; QUESTION SECTION: ;belkin.com. IN SOA ;; ANSWER SECTION: belkin.com. 21121 IN SOA ns1.p06.dynect.net. DNSDomainAdmin.belkin.com. 2010071117 3600 600 604800 3600 Who knows what Google is doing under the hood here. Gut feeling is they have something cached -- this would imply Belkin was using a single A record originally, then all this happened, and it forced them to move to RR A records, but something within Google's own DNS infrastructure is still returning the old cached copy. Note that 67.20.176.130 doesn't even appear in the RR list. I wouldn't be surprised if somehow this was tickled by someone at Belkin botching a DNS update (forgetting to increment serial, for example). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | On Tue, Oct 07, 2014 at 02:14:41PM -0700, Grant Ridder via Outages wrote:
Your large host list looks like it is just your local resolver.
host heartbeat.belkin.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
heartbeat.belkin.com has address 67.20.176.130
On Tue, Oct 7, 2014 at 1:48 PM, Paul Miller via Outages <outages@outages.org
wrote:
On Tue, Oct 07, 2014 at 02:43:13PM -0400, Nick Olsen via Outages wrote:
The current thought (Around the NOC here) is that DNS is breaking due to another user friendly feature. Where the router forwards you to it's config page automatically, if it thinks you have no internet..
I still don't have a clear answer on this at my little ISP here. I think the above quote is exactly the problem though. I had a few people start working after a router reboot with the ping trick in place and others that couldn't get going after the reboot.
I suspect the "bad firmware" that may also be (is also?) out there prevents it from connecting — though DHCP seems to complete ACK before it goes dead and you never hear from the IP again.
Interestingly, it seems it's not just one IP anymore.
host heartbeat.belkin.com heartbeat.belkin.com has address 54.163.87.225 heartbeat.belkin.com has address 54.163.74.132 heartbeat.belkin.com has address 54.87.180.46 heartbeat.belkin.com has address 174.129.92.187 heartbeat.belkin.com has address 54.242.182.61 heartbeat.belkin.com has address 23.20.47.97 heartbeat.belkin.com has address 54.161.217.33 heartbeat.belkin.com has address 54.83.179.150 heartbeat.belkin.com has address 54.163.115.57 heartbeat.belkin.com has address 54.87.220.73 heartbeat.belkin.com has address 54.227.172.225 heartbeat.belkin.com has address 54.196.247.165 heartbeat.belkin.com has address 54.163.72.1
-Paul _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
_______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages