I can't resolve anything for kernel.org from Verizon's 3G network, or from
HE in California. I'm using HE's nameservers, with Google's as a backup.
Neither of them have any records. Anyone know what's up?
I'm seeing the same issue. One of the authoritative name servers is timing
out and the other is not providing an authoritative record.
*# dig kernel.org @130.239.17.16 *
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> kernel.org @130.239.17.16
;; global options: printcmd
;; connection timed out; no servers could be reached
*# dig kernel.org @209.132.180.67*
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> kernel.org @209.132.180.67
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1319
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;kernel.org. IN A
Strange one.
Also fails with my ISP (BE*There in the UK), but, org. nameservers have it fine:
$ dig kernel.org @c0.org.afilias-nst.info.
; <<>> DiG 9.6.-ESV-R3 <<>> kernel.org @c0.org.afilias-nst.info.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32885
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;kernel.org. IN A
;; AUTHORITY SECTION:
kernel.org. 86400 IN NS ns.vger.kernel.org.
kernel.org. 86400 IN NS ns4.kernel.org.
;; ADDITIONAL SECTION:
ns.vger.kernel.org. 86400 IN A 209.132.180.67
ns4.kernel.org. 86400 IN A 130.239.17.16
ns4.kernel.org. 86400 IN AAAA 2001:6b0:e:4017::1:1
;; Query time: 40 msec
;; SERVER: 199.19.53.1#53(199.19.53.1)
;; WHEN: Thu Sep 8 22:46:33 2011
;; MSG SIZE rcvd: 138
Maybe related to the hacking that they discovered recently?
http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised
-Kyle
Here in London on BE*There it was not working, either. But the queries
are coming through now.
$ dig www.kernel.org +short
140.211.169.30
Looks like its fixed already
$ dig kernel.org @8.8.8.8
; <<>> DiG 9.6.-ESV-R3 <<>> kernel.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13079
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;kernel.org. IN A
;; ANSWER SECTION:
kernel.org. 3298 IN A 140.211.169.30
# telnet kernel.org 80
Trying 140.211.169.30...
telnet: Unable to connect to remote host: Connection refused
# telnet kernel.org 21
Trying 140.211.169.30...
^C
# telnet www.kernel.org 80
Trying 140.211.169.30...
telnet: Unable to connect to remote host: Connection refused
# telnet www.kernel.org 21
Trying 140.211.169.30...
^C
...
199.6.1.165 http/ftp is good, 2001:6b0:e:4017:1994:313:1:0 http/ftp is not.
GeoDNS hasn't been working for a few days perhaps since the trouble
they have recently had (do not know if it was previously working
correctly).
IPs are from testing GeoDNS @ around Wed, 07 Sep 2011 19:51 GMT.
(kernel.org would resolve; www.kernel.org would not due to CNAME to
www.geo.kernel.org; attempts to resolve www.geo.kernel.org would
timeout; mirrors.kernel.org suffered a similar fate for me).
-GPG
Perhaps useful (from yesterday's terminal history):
# dig www.us.kernel.org ANY
; <<>> DiG 9.6-ESV-R4 <<>> www.us.kernel.org ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 362
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 7, ADDITIONAL: 8
;; QUESTION SECTION:
;www.us.kernel.org. IN ANY
;; ANSWER SECTION:
www.us.kernel.org. 600 IN A 66.160.172.98
www.us.kernel.org. 600 IN A 128.30.2.36
www.us.kernel.org. 600 IN A 146.137.96.7
www.us.kernel.org. 600 IN A 146.137.96.15
www.us.kernel.org. 600 IN A 155.98.64.81
www.us.kernel.org. 600 IN A 208.69.120.79
www.us.kernel.org. 600 IN A 216.165.129.139
www.us.kernel.org. 600 IN A 216.176.132.235
;; AUTHORITY SECTION:
kernel.org. 86400 IN NS ns0.kernel.org.
kernel.org. 86400 IN NS ns1.kernel.org.
kernel.org. 86400 IN NS ns3.kernel.org.
kernel.org. 86400 IN NS ns2.kernel.org.
kernel.org. 86400 IN NS ns5.kernel.org.
kernel.org. 86400 IN NS ns4.kernel.org.
kernel.org. 86400 IN NS ns.vger.kernel.org.
;; ADDITIONAL SECTION:
ns0.kernel.org. 85692 IN A 140.211.167.34
ns1.kernel.org. 71877 IN A 149.20.20.144
ns1.kernel.org. 600 IN AAAA 2001:4f8:8:10::1:1
ns2.kernel.org. 29867 IN A 149.20.4.80
ns2.kernel.org. 600 IN AAAA 2001:4f8:1:10::1:1
ns3.kernel.org. 15397 IN A 199.6.1.176
ns3.kernel.org. 600 IN AAAA 2001:500:60:10::1:1
ns5.kernel.org. 600 IN A 140.211.167.34
;; Query time: 247 msec
...
;; WHEN: Wed Sep 7 15:03:04 2011
;; MSG SIZE rcvd: 457
From here (near Chicago), ns.vger.kernel.org is reporting that ns7.kernel.org and ns.vger.kernel.org are the authorative servers for kernel.org. But the .org roots are claiming ns.vger.kernel.org and ns4.kernel.org are the authorative servers to use.
ns4.kernel.org is not accessable from here via IPv4 or IPv6.
ns7.kernel.org seems to be giving out sensible answers.
That will cause strange issues across the Internet until the roots match what ns.vger.kernel.org shows or ns4.kernel.org comes back online.
Lyle Giese
LCR Computer Services, Inc.
fatal: Unable to look up git.kernel.org (port 9418) (Name or service not
known)
# dig @8.8.8.8 git.kernel.org
; <<>> DiG 9.7.3-RedHat-9.7.3-2.el6 <<>> @8.8.8.8 git.kernel.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5492
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;git.kernel.org. IN A
;; AUTHORITY SECTION:
kernel.org. 1407 IN SOA ns7.kernel.org.
hostmaster.ns7.kernel.org. 20110908 3600 600 604800 3600
;; Query time: 83 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 9 18:03:02 2011
;; MSG SIZE rcvd: 83
Yep, maybe it's related to that activity?
Chris.
The location of the Linus tree to github is temporary. Linus
has stated that when the kernel.org infrastructure is rebuilt
he will move back, and github will simply be a mirror.
http://article.gmane.org/gmane.linux.kernel/1187922
The move to github was a pragmatic decision, but its
use in the general case does raise some additional
concerns/issues which were mentioned in the announcement.
https://lkml.org/lkml/2011/9/4/92
Gary