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 j...@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
_______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages