in-addr.arpa server problems for europe?
I see constant issues where I can't resolve PTR's in Europe. I see no reason for this except that a bunch of servers are either dropping my packets or are permanently f**ked... any other clues gratefully accepted. michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364340 IN NS J.ROOT-SERVERS.NET. . 364340 IN NS K.ROOT-SERVERS.NET. . 364340 IN NS L.ROOT-SERVERS.NET. . 364340 IN NS M.ROOT-SERVERS.NET. . 364340 IN NS A.ROOT-SERVERS.NET. . 364340 IN NS B.ROOT-SERVERS.NET. . 364340 IN NS C.ROOT-SERVERS.NET. . 364340 IN NS D.ROOT-SERVERS.NET. . 364340 IN NS E.ROOT-SERVERS.NET. . 364340 IN NS F.ROOT-SERVERS.NET. . 364340 IN NS G.ROOT-SERVERS.NET. . 364340 IN NS H.ROOT-SERVERS.NET. . 364340 IN NS I.ROOT-SERVERS.NET. ;; Received 332 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364195 IN NS F.ROOT-SERVERS.NET. . 364195 IN NS G.ROOT-SERVERS.NET. . 364195 IN NS H.ROOT-SERVERS.NET. . 364195 IN NS I.ROOT-SERVERS.NET. . 364195 IN NS J.ROOT-SERVERS.NET. . 364195 IN NS K.ROOT-SERVERS.NET. . 364195 IN NS L.ROOT-SERVERS.NET. . 364195 IN NS M.ROOT-SERVERS.NET. . 364195 IN NS A.ROOT-SERVERS.NET. . 364195 IN NS B.ROOT-SERVERS.NET. . 364195 IN NS C.ROOT-SERVERS.NET. . 364195 IN NS D.ROOT-SERVERS.NET. . 364195 IN NS E.ROOT-SERVERS.NET. ;; Received 512 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. ;; Received 224 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 5256 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364138 IN NS E.ROOT-SERVERS.NET. . 364138 IN NS F.ROOT-SERVERS.NET. . 364138 IN NS G.ROOT-SERVERS.NET. . 364138 IN NS H.ROOT-SERVERS.NET. . 364138 IN NS I.ROOT-SERVERS.NET. . 364138 IN NS J.ROOT-SERVERS.NET. . 364138 IN NS K.ROOT-SERVERS.NET. . 364138 IN NS L.ROOT-SERVERS.NET. . 364138 IN NS M.ROOT-SERVERS.NET. . 364138 IN NS A.ROOT-SERVERS.NET. . 364138 IN NS B.ROOT-SERVERS.NET. . 364138 IN NS C.ROOT-SERVERS.NET. . 364138 IN NS D.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. ;; Received 224 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 183 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364091 IN NS D.ROOT-SERVERS.NET. . 364091 IN NS E.ROOT-SERVERS.NET. . 364091 IN NS F.ROOT-SERVERS.NET. . 364091 IN NS G.ROOT-SERVERS.NET. . 364091 IN NS H.ROOT-SERVERS.NET. . 364091 IN NS I.ROOT-SERVERS.NET. . 364091 IN NS J.ROOT-SERVERS.NET. . 364091 IN NS K.ROOT-SERVERS.NET. . 364091 IN NS L.ROOT-SERVERS.NET. . 364091 IN NS M.ROOT-SERVERS.NET. . 364091 IN NS A.ROOT-SERVERS.NET. . 364091 IN NS B.ROOT-SERVERS.NET. . 364091 IN NS C.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. ;; Received 224 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 249 ms ;; connection timed out; no servers could be reached michelle@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364032 IN NS B.ROOT-SERVERS.NET. . 364032 IN NS C.ROOT-SERVERS.NET. . 364032 IN NS D.ROOT-SERVERS.NET. . 364032 IN NS E.ROOT-SERVERS.NET. . 364032 IN NS F.ROOT-SERVERS.NET. . 364032 IN NS G.ROOT-SERVERS.NET. . 364032 IN NS H.ROOT-SERVERS.NET. . 364032 IN NS I.ROOT-SERVERS.NET. . 364032 IN NS J.ROOT-SERVERS.NET. . 364032 IN NS K.ROOT-SERVERS.NET. . 364032 IN NS L.ROOT-SERVERS.NET. . 364032 IN NS M.ROOT-SERVERS.NET. . 364032 IN NS A.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 179 ms ;; connection timed out; no servers could be reached ...and to prove things do work @111.125.160.128/26... michelle@enigma:~/dultools$ dig +trace -x 8.8.8.8 ; <<>> DiG 9.3.3 <<>> +trace -x 8.8.8.8 ;; global options: printcmd . 364040 IN NS C.ROOT-SERVERS.NET. . 364040 IN NS D.ROOT-SERVERS.NET. . 364040 IN NS E.ROOT-SERVERS.NET. . 364040 IN NS F.ROOT-SERVERS.NET. . 364040 IN NS G.ROOT-SERVERS.NET. . 364040 IN NS H.ROOT-SERVERS.NET. . 364040 IN NS I.ROOT-SERVERS.NET. . 364040 IN NS J.ROOT-SERVERS.NET. . 364040 IN NS K.ROOT-SERVERS.NET. . 364040 IN NS L.ROOT-SERVERS.NET. . 364040 IN NS M.ROOT-SERVERS.NET. . 364040 IN NS A.ROOT-SERVERS.NET. . 364040 IN NS B.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 4 ms 8.in-addr.arpa. 86400 IN NS NS1.LEVEL3.NET. 8.in-addr.arpa. 86400 IN NS NS2.LEVEL3.NET. ;; Received 84 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 180 ms 8.8.8.in-addr.arpa. 3600 IN NS ns2.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns3.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns4.google.com. 8.8.8.in-addr.arpa. 3600 IN NS ns1.google.com. ;; Received 120 bytes from 209.244.0.1#53(NS1.LEVEL3.NET) in 175 ms 8.8.8.8.in-addr.arpa. 86400 IN PTR google-public-dns-a.google.com. ;; Received 82 bytes from 216.239.34.10#53(ns2.google.com) in 211 ms
On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan <matthew@sorbs.net> wrote a message of 185 lines which said:
213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms
;; connection timed out; no servers could be reached
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers? (I tried from an US/Datotel/Level3 machine and everything works.)
Stephane Bortzmeyer wrote:
On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan <matthew@sorbs.net> wrote a message of 185 lines which said:
213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms
;; connection timed out; no servers could be reached
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers?
(I tried from an US/Datotel/Level3 machine and everything works.)
Thanks... F**Kin' PIXs! Michelle
Michelle Sullivan wrote:
Stephane Bortzmeyer wrote:
On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan <michelle@sorbs.net> wrote a message of 185 lines which said:
213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms
;; connection timed out; no servers could be reached
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers?
(I tried from an US/Datotel/Level3 machine and everything works.)
Thanks... F**Kin' PIXs!
Then again.... michelle@enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 ; <<>> DiG 9.3.3 <<>> +trace +bufsize=512 -x 81.255.164.225 ;; global options: printcmd . 352606 IN NS L.ROOT-SERVERS.NET. . 352606 IN NS M.ROOT-SERVERS.NET. . 352606 IN NS A.ROOT-SERVERS.NET. . 352606 IN NS B.ROOT-SERVERS.NET. . 352606 IN NS C.ROOT-SERVERS.NET. . 352606 IN NS D.ROOT-SERVERS.NET. . 352606 IN NS E.ROOT-SERVERS.NET. . 352606 IN NS F.ROOT-SERVERS.NET. . 352606 IN NS G.ROOT-SERVERS.NET. . 352606 IN NS H.ROOT-SERVERS.NET. . 352606 IN NS I.ROOT-SERVERS.NET. . 352606 IN NS J.ROOT-SERVERS.NET. . 352606 IN NS K.ROOT-SERVERS.NET. ;; Received 511 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 81.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 81.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 81.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 81.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 81.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. ;; Received 235 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 179 ms ;; connection timed out; no servers could be reached michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52112 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ;; Query time: 320 msec ;; SERVER: 192.134.0.49#53(192.134.0.49) ;; WHEN: Mon Feb 15 23:37:36 2010 ;; MSG SIZE rcvd: 170 michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @SEC3.APNIC.NET ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @SEC3.APNIC.NET ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32853 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. ;; Query time: 200 msec ;; SERVER: 202.12.28.140#53(202.12.28.140) ;; WHEN: Mon Feb 15 23:29:41 2010 ;; MSG SIZE rcvd: 126 michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @ns.ripe.net. ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @ns.ripe.net. ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1316 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 164.255.81.in-addr.arpa. 3600 IN NS proof.rain.fr. 164.255.81.in-addr.arpa. 3600 IN NS bow.rain.fr. ;; Query time: 322 msec ;; SERVER: 193.0.0.193#53(193.0.0.193) ;; WHEN: Mon Feb 15 23:30:03 2010 ;; MSG SIZE rcvd: 101 michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @proof.rain.fr. ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @proof.rain.fr. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5704 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; ANSWER SECTION: 225.164.255.81.in-addr.arpa. 3600 IN PTR mail.pharaon.fr. ;; AUTHORITY SECTION: 164.255.81.in-addr.arpa. 3600 IN NS 194.51.3.65. 164.255.81.in-addr.arpa. 3600 IN NS bow.rain.fr. ;; ADDITIONAL SECTION: bow.rain.fr. 83600 IN A 194.51.3.49 ;; Query time: 326 msec ;; SERVER: 194.51.3.65#53(194.51.3.65) ;; WHEN: Mon Feb 15 23:30:14 2010 ;; MSG SIZE rcvd: 149 michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @bow.rain.fr. ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @bow.rain.fr. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22282 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; ANSWER SECTION: 225.164.255.81.in-addr.arpa. 3600 IN PTR mail.pharaon.fr. ;; AUTHORITY SECTION: 164.255.81.in-addr.arpa. 3600 IN NS 194.51.3.65. 164.255.81.in-addr.arpa. 3600 IN NS bow.rain.fr. ;; ADDITIONAL SECTION: bow.rain.fr. 83600 IN A 194.51.3.49 ;; Query time: 340 msec ;; SERVER: 194.51.3.49#53(194.51.3.49) ;; WHEN: Mon Feb 15 23:30:54 2010 ;; MSG SIZE rcvd: 149 michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @SNS-PB.ISC.ORG ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @SNS-PB.ISC.ORG ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9273 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ;; Query time: 183 msec ;; SERVER: 192.5.4.1#53(192.5.4.1) ;; WHEN: Mon Feb 15 23:31:20 2010 ;; MSG SIZE rcvd: 170 michelle@enigma:~$ dig -x 81.255.164.225 @SNS-PB.ISC.ORG ; <<>> DiG 9.3.3 <<>> -x 81.255.164.225 @SNS-PB.ISC.ORG ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2301 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ;; Query time: 183 msec ;; SERVER: 192.5.4.1#53(192.5.4.1) ;; WHEN: Mon Feb 15 23:31:37 2010 ;; MSG SIZE rcvd: 159 michelle@enigma:~$ dig +trace +bufsize=4096 -x 81.255.164.225 ; <<>> DiG 9.3.3 <<>> +trace +bufsize=4096 -x 81.255.164.225 ;; global options: printcmd . 352340 IN NS H.ROOT-SERVERS.NET. . 352340 IN NS I.ROOT-SERVERS.NET. . 352340 IN NS J.ROOT-SERVERS.NET. . 352340 IN NS K.ROOT-SERVERS.NET. . 352340 IN NS L.ROOT-SERVERS.NET. . 352340 IN NS M.ROOT-SERVERS.NET. . 352340 IN NS A.ROOT-SERVERS.NET. . 352340 IN NS B.ROOT-SERVERS.NET. . 352340 IN NS C.ROOT-SERVERS.NET. . 352340 IN NS D.ROOT-SERVERS.NET. . 352340 IN NS E.ROOT-SERVERS.NET. . 352340 IN NS F.ROOT-SERVERS.NET. . 352340 IN NS G.ROOT-SERVERS.NET. ;; Received 643 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 81.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 81.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 81.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 81.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 81.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 81.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 235 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 178 ms ;; connection timed out; no servers could be reached ... what am I missing? (Set the PIX v7.2.1 to allow DNS upto 4096 bytes - results are the same before and after) Note: As far as I know lookups from this server worked until around Sept 09, the hosts changed from 203.15.51.32/27 to 111.125.160.129/26 at this time, they have been failing since. Thanks, Michelle
0n Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote: >Michelle Sullivan wrote: >michelle@enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 >michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR Curious, why did you modify 'bufsize' ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.
On Mon, Feb 15, 2010 at 08:30:43PM +0800, Wilkinson, Alex <alex.wilkinson@dsto.defence.gov.au> wrote a message of 14 lines which said:
Curious, why did you modify 'bufsize' ?
To test response size issues, probably. Broken middleboxes are the scourge of the Internet. http://labs.ripe.net/content/preparing-k-root-signed-root-zone
If you have received this email in error, you are requested to contact the sender and delete the email.
Done. I also erased the hard disk and reinstalled the OS.
On 2/15/2010 7:00 AM, Stephane Bortzmeyer wrote:
If you have received this email in error, you are requested to contact the sender and delete the email.
Done. I also erased the hard disk and reinstalled the OS.
Given that many Network Operator managers require that that crap be appended to out-bound messages, frequently beyond the control (or wishes) of the message-originator, why is it necessary to whine about every occurrence of it? Maybe the list manager here can include the whine in the monthly "address verification" message, which I filter off to the bit-bucket unseen. Alternately, maybe we can get an IETF wg tasked with a supply of new "funny" remarks to be included in the whines--since all of the funny stuff currently available has been used and abused so completely. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Larry Sheldon wrote:
On 2/15/2010 7:00 AM, Stephane Bortzmeyer wrote:
If you have received this email in error, you are requested to contact the sender and delete the email.
Done. I also erased the hard disk and reinstalled the OS.
Given that many Network Operator managers require that that crap be appended to out-bound messages, frequently beyond the control (or wishes) of the message-originator, why is it necessary to whine about every occurrence of it?
IMHO, if your organization appends crap to your outbound messages then you should maintain a separate crap-free email account for your personal email and use it when you post to discussion lists. (If you want to receive list email at your crap-infested account for your own convenience, have it forwarded so that your crap-infested reply email can't be posted back to the list. This isn't rocket science, right?) Posting with crap laden .sigs is just as bad as posting in HTML. This isn't some band fan discussion group, this is the North American Network Operators Group - it's reasonable to expect a certain amount of posting professionalism here. jc
On Mon, Feb 15, 2010 at 12:51 PM, JC Dill <jcdill.lists@gmail.com> wrote:
Larry Sheldon wrote:
IMHO, if your organization appends crap to your outbound messages then you should maintain a separate crap-free email account for your personal email
or... we could all be adults and just forget these things exist, since as the threads over the years seem to indicate they aren't enforcable anyway... that gets my vote, less noise and happier people. -chris
On 2/15/2010 11:51 AM, JC Dill wrote:
Larry Sheldon wrote:
On 2/15/2010 7:00 AM, Stephane Bortzmeyer wrote:
If you have received this email in error, you are requested to contact the sender and delete the email.
Done. I also erased the hard disk and reinstalled the OS.
Given that many Network Operator managers require that that crap be appended to out-bound messages, frequently beyond the control (or wishes) of the message-originator, why is it necessary to whine about every occurrence of it?
IMHO, if your organization appends crap to your outbound messages then you should maintain a separate crap-free email account for your personal email and use it when you post to discussion lists. (If you want to [snip]
OK. So he should use his hotmail account for stuff that is authoritative for his employer. Oh, wait. hotmail appends an advertisement to everything. Yahoo maybe--no their appendages go on for a page or more....I guess I'll have to listen to the whiners (or filter them off--they probably don't have any thing useful to say anyway). -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Wilkinson, Alex wrote:
0n Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote:
>Michelle Sullivan wrote:
>michelle@enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 >michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR
Curious, why did you modify 'bufsize' ?
Well I started here: http://sel.icann.org/node/715#fn1 and figured that it was a way to force the packet size and protocol so that I could fit it to known constraints in the PIX eg: Fix to 512 bytes and if the PIX is rejecting anything over 512 bytes there is a simple answer. Fix to 4096 bytes and it forces to EDNS (v0) - as can be seen in the output, to see if the PIX is just dropping all EDNS.. obviously the resulting size sent back I cannot control (except by limiting the maximum size), so the next step was to query all (or a selection) of the servers being traced through. What I can't figure out is why I can query the servers directly and get a response but the trace fails. Any insight will be greatly appreciated. Michelle
On Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan <matthew@sorbs.net> wrote a message of 298 lines which said:
michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR
Bad test: the response is too small to exercice real size problems. Try adding "+dnssec" to the dig command-line (that's what BIND does by default).
Stephane Bortzmeyer wrote:
On Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan <matthew@sorbs.net> wrote a message of 298 lines which said:
michelle@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR
Bad test: the response is too small to exercice real size problems. Try adding "+dnssec" to the dig command-line (that's what BIND does by default).
Thanks.... the query still works though.... michelle@enigma:~$ dig +bufsize=4096 +dnssec -x 81.255.164.225 @NS3.NIC.FR ; <<>> DiG 9.3.3 <<>> +bufsize=4096 +dnssec -x 81.255.164.225 @NS3.NIC.FR ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33097 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa. 172800 IN NS bow.rain.fr. 255.81.in-addr.arpa. 172800 IN NS proof.rain.fr. 255.81.in-addr.arpa. 172800 IN NS ns.ripe.net. 255.81.in-addr.arpa. 7200 IN NSEC 0.26.81.in-addr.arpa. NS RRSIG NSEC 255.81.in-addr.arpa. 7200 IN RRSIG NSEC 5 4 7200 20100317114227 20100215114227 19380 81.in-addr.arpa. dpdCyKkLsN4ts8DbSSBzsOPvr/65Z40Y3IbWFFuIBUf6/dhRFKbrpcgW HB6aPdFgpEyJ70uJgRY54d3eAS8S2U9oeAWlzj75n1wnrC8KAdLbCIS+ nbl1occ0PmIn0uuv0y/3oBvxLb2qVTB6KoBH2vxjSUIVsyLwthiUg34G Wyrn/yHT+gRfAbNdfmYRm8fa0/TGvNUN ;; ADDITIONAL SECTION: ns.ripe.net. 172800 IN A 193.0.0.193 ns.ripe.net. 172800 IN AAAA 2001:610:240:0:53::193 ns.ripe.net. 172800 IN RRSIG A 5 3 172800 20100317112654 20100215112654 51207 ripe.net. NWJBUydKjOtdlzqSAUkdOD3gMPLsKEQqE2z5LLvOmsdjltrJuQmkk2it bS+iyh4lzffi2Zc39D6rscy+MuNAnHNplnwUpIu2zOVAJwKs8NuChbon MfCS5K9Q0uEbYaiH1q+AIzekkPjhKfA/8uFFKTyw3fyQyoA6PXp+tbin GvwUdsrKzvpFrA7yiK4mlExfNnmcN7Qm ns.ripe.net. 172800 IN RRSIG AAAA 5 3 172800 20100317112654 20100215112654 51207 ripe.net. Gz53F5uTq1nmr/t8x8hltVNZ/Rw3G/tRTJX6hz1CQWmU6YPK2xaRro47 Yk7St3z0I+H2plwhhRoF/3o5c4wI6h5jgMUQdf0YUQ0Uw9F3XUHqsGN/ zffk5mGBvK9bx8zxK3OBMd6cQ4O6uKgIGI7BwCacwhYU9lz+OZTxBRNB Es24jQ+h5HkV8gL++dG8m6InoFAn7cca ;; Query time: 322 msec ;; SERVER: 192.134.0.49#53(192.134.0.49) ;; WHEN: Tue Feb 16 00:09:36 2010 ;; MSG SIZE rcvd: 789
-----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Monday, February 15, 2010 12:58 PM To: Michelle Sullivan Cc: NANOG list Subject: Re: in-addr.arpa server problems for europe?
On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan <matthew@sorbs.net> wrote a message of 185 lines which said:
213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms
;; connection timed out; no servers could be reached
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers?
(I tried from an US/Datotel/Level3 machine and everything works.)
Solution: stop using DNSSEC or checking for DNSSEC. If you think it is usefull: look for everything that could have an impact on it.
-----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Monday, February 15, 2010 2:01 PM To: Mark Scholten Cc: nanog@nanog.org Subject: Re: in-addr.arpa server problems for europe?
On Mon, Feb 15, 2010 at 01:12:55PM +0100, Mark Scholten <mark@streamservice.nl> wrote a message of 36 lines which said:
Solution: stop using DNSSEC or checking for DNSSEC.
In 2010, it is a bit backward...
I've seen problems that are only there because of DNSSEC, so if there is a problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
On Mon, 15 Feb 2010, Mark Scholten wrote:
I've seen problems that are only there because of DNSSEC, so if there is a problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
You realise that two of them are signed now and the rest will be signed by 1st July? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
On 2/15/10 9:21 AM, Tony Finch wrote:
On Mon, 15 Feb 2010, Mark Scholten wrote:
I've seen problems that are only there because of DNSSEC, so if there is a problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
You realise that two of them are signed now and the rest will be signed by 1st July?
Which means now is a good time to find and fix brokenness, not hope that DNSSEC will go away. ~Seth
On Feb 15, 2010, at 1:01 PM, Seth Mattinen wrote:
On 2/15/10 9:21 AM, Tony Finch wrote:
On Mon, 15 Feb 2010, Mark Scholten wrote:
I've seen problems that are only there because of DNSSEC, so if there is a problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
You realise that two of them are signed now and the rest will be signed by 1st July?
Which means now is a good time to find and fix brokenness, not hope that DNSSEC will go away.
Right. Apart from implementations that just can't handle funky RR types in the response -- firewalls, perhaps? see RFC 2979, especially the transparency rule -- a lot of the trouble is caused by the reply size. The code should either use EDNS0 or fall back to TCP -- and lots of folks have broken firewall configs that don't allow TCP 53, even though it's been in the spec since 1984 or thereabouts. --Steve Bellovin, http://www.cs.columbia.edu/~smb
-----Original Message----- From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk] On Behalf Of Tony Finch Sent: Monday, February 15, 2010 6:21 PM To: Mark Scholten Cc: nanog@nanog.org Subject: RE: in-addr.arpa server problems for europe?
On Mon, 15 Feb 2010, Mark Scholten wrote:
I've seen problems that are only there because of DNSSEC, so if there
is a
problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
You realise that two of them are signed now and the rest will be signed by 1st July?
Tony.
Yes, I realise that. I also realise that not all nameserver software can work as it work with DNSSEC. That is also a problem that has to be solved and for as far as I know all nameserver software we use support it or will support it in the future. As long as it is not supported by all nameserver software you can keep problems.
In message <017901caae69$5d9e8770$18db9650$@nl>, "Mark Scholten" writes:
-----Original Message----- From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk] On Behalf Of Tony Finch Sent: Monday, February 15, 2010 6:21 PM To: Mark Scholten Cc: nanog@nanog.org Subject: RE: in-addr.arpa server problems for europe?
On Mon, 15 Feb 2010, Mark Scholten wrote:
I've seen problems that are only there because of DNSSEC, so if there
is a
problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
You realise that two of them are signed now and the rest will be signed by 1st July?
Tony.
Yes, I realise that. I also realise that not all nameserver software can work as it work with DNSSEC. That is also a problem that has to be solved and for as far as I know all nameserver software we use support it or will support it in the future. As long as it is not supported by all nameserver software you can keep problems.
Nameservers that are not DNSSEC aware will not get responses that contain DNSSEC records unless a client explicitly requests a DNSSEC record type or make a * (ANY) request. There is no problem to solve. Just a lot of misunderstanding. That said the majority of nameservers on the planet are DNSSEC aware and will request the DNSSEC record to be returned. They will also fall back to plain DNS if middleware blocks the response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-----Original Message----- From: marka@isc.org [mailto:marka@isc.org] Sent: Tuesday, February 16, 2010 12:37 AM To: Mark Scholten Cc: 'Tony Finch'; nanog@nanog.org Subject: Re: in-addr.arpa server problems for europe?
In message <017901caae69$5d9e8770$18db9650$@nl>, "Mark Scholten" writes:
-----Original Message----- From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk] On Behalf Of Tony Finch Sent: Monday, February 15, 2010 6:21 PM To: Mark Scholten Cc: nanog@nanog.org Subject: RE: in-addr.arpa server problems for europe?
On Mon, 15 Feb 2010, Mark Scholten wrote:
I've seen problems that are only there because of DNSSEC, so if
there
is a
problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
You realise that two of them are signed now and the rest will be signed by 1st July?
Tony.
Yes, I realise that. I also realise that not all nameserver software can work as it work with DNSSEC. That is also a problem that has to be solved and for as far as I know all nameserver software we use support it or will support it in the future. As long as it is not supported by all nameserver software you can keep problems.
Nameservers that are not DNSSEC aware will not get responses that contain DNSSEC records unless a client explicitly requests a DNSSEC record type or make a * (ANY) request.
There is no problem to solve. Just a lot of misunderstanding.
That said the majority of nameservers on the planet are DNSSEC aware and will request the DNSSEC record to be returned. They will also fall back to plain DNS if middleware blocks the response.
As you've understood I need to read something extra about DNSSEC support. The most things I know about DNSSEC are based on my contacts with software writers that create nameservers and system administrators maintaining multiple nameservers. So if I understand it correctly; if a resolver requests DNSSEC information (together with for example www.domain.tld) and 1 resolver before the AUTH nameserver doesn't have DNSSEC it won't ask/require DNSSEC? In that case men in the middle attacks are still possible. Also note that a provider might have multiple resolvers with some using/able to provide DNSSEC and others without DNSSEC support. Mark
In message <01c201caaead$b115eda0$1341c8e0$@nl>, "Mark Scholten" writes:
-----Original Message----- From: marka@isc.org [mailto:marka@isc.org] Sent: Tuesday, February 16, 2010 12:37 AM To: Mark Scholten Cc: 'Tony Finch'; nanog@nanog.org Subject: Re: in-addr.arpa server problems for europe?
In message <017901caae69$5d9e8770$18db9650$@nl>, "Mark Scholten" writes:
-----Original Message----- From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk] On Behalf Of Tony Finch Sent: Monday, February 15, 2010 6:21 PM To: Mark Scholten Cc: nanog@nanog.org Subject: RE: in-addr.arpa server problems for europe?
On Mon, 15 Feb 2010, Mark Scholten wrote:
I've seen problems that are only there because of DNSSEC, so if
there
is a
problem starting with trying to disable DNSSEC could be a good idea. As long as not all rootzones are signed I don't see a good reason to use DNSSEC at the moment.
You realise that two of them are signed now and the rest will be signed by 1st July?
Tony.
Yes, I realise that. I also realise that not all nameserver software can work as it work with DNSSEC. That is also a problem that has to be solved and for as far as I know all nameserver software we use support it or will support it in the future. As long as it is not supported by all nameserver software you can keep problems.
Nameservers that are not DNSSEC aware will not get responses that contain DNSSEC records unless a client explicitly requests a DNSSEC record type or make a * (ANY) request.
There is no problem to solve. Just a lot of misunderstanding.
That said the majority of nameservers on the planet are DNSSEC aware and will request the DNSSEC record to be returned. They will also fall back to plain DNS if middleware blocks the response.
As you've understood I need to read something extra about DNSSEC support. The most things I know about DNSSEC are based on my contacts with software writers that create nameservers and system administrators maintaining multiple nameservers. So if I understand it correctly; if a resolver requests DNSSEC information (together with for example www.domain.tld) and 1 resolver before the AUTH nameserver doesn't have DNSSEC it won't ask/require DNSSEC? In that case men in the middle attacks are still possible. Also note that a provider might have multiple resolvers with some using/able to provide DNSSEC and others without DNSSEC support.
Mark
DNSSEC requires a DNSSEC clear path between the validator and the authoritative servers. If there is not a DNSSEC clear path the answers will be rejected as they cannot be validated. A man in the middle can launch a denial of service attack but cannot launch a spoofing attack. Most validators, at the moment, are co-located with iterative resolvers which provide the DNSSEC clear path. Some applications are fully DNSSEC aware and do their own validation in which case there needs to be a DNSSEC clear path to the recursive resolver and onwards to the authoritative servers. Other applications are only AD aware, in which case they trust the recursive resolver and need channel security between the application and the recursive resolver. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
I don't know if it's material as most DNS stuff is over my head, but Geoff Houston has written about the in-addr.arpa situation in the most recent edition of his Internet Society ISP Column http://isoc.org/wp/ispcolumn/?p=246 -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com ---------------------------------------------------------------
* Stephane Bortzmeyer:
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers?
Ahem. dig's +trace doesn't use EDNS by default, so no signatures and (usually) no large responses. For extra realism, you need to add +dnssec +norecurse, and +all for usefulness.
In message <87iq9ys512.fsf@mid.deneb.enyo.de>, Florian Weimer writes:
* Stephane Bortzmeyer:
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers?
Ahem. dig's +trace doesn't use EDNS by default, so no signatures and (usually) no large responses.
I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4. drugs# foreach h ( SUNIC.SUNET.SE TINNIE.ARIN.NET NS-PRI.RIPE.NET NS3.NIC.FR SEC3.APNIC.NET SEC1.APNIC.NET SNS-PB.ISC.ORG ) foreach? echo $h `dig +short $h aaaa` foreach? end SUNIC.SUNET.SE 2001:6b0:7::2 TINNIE.ARIN.NET 2001:500:13::c7d4:35 NS-PRI.RIPE.NET 2001:610:240:0:53::3 NS3.NIC.FR 2001:660:3006:1::1:1 SEC3.APNIC.NET 2001:dc0:1:0:4777::140 SEC1.APNIC.NET 2001:dc0:2001:a:4608::59 SNS-PB.ISC.ORG 2001:500:2e::1 drugs# Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <201002152312.o1FNCFq8098232@drugs.dv.isc.org>, Mark Andrews writes:
In message <87iq9ys512.fsf@mid.deneb.enyo.de>, Florian Weimer writes:
* Stephane Bortzmeyer:
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers?
Ahem. dig's +trace doesn't use EDNS by default, so no signatures and (usually) no large responses.
I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4.
drugs# foreach h ( SUNIC.SUNET.SE TINNIE.ARIN.NET NS-PRI.RIPE.NET NS3.NIC.FR SEC3.APNIC.NET SEC1.APNIC.NET SNS-PB.ISC.ORG ) foreach? echo $h `dig +short $h aaaa` foreach? end SUNIC.SUNET.SE 2001:6b0:7::2 TINNIE.ARIN.NET 2001:500:13::c7d4:35 NS-PRI.RIPE.NET 2001:610:240:0:53::3 NS3.NIC.FR 2001:660:3006:1::1:1 SEC3.APNIC.NET 2001:dc0:1:0:4777::140 SEC1.APNIC.NET 2001:dc0:2001:a:4608::59 SNS-PB.ISC.ORG 2001:500:2e::1 drugs#
Also a more recent DiG than from BIND 9.3.3 would have helped. :-)
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
In message <87iq9ys512.fsf@mid.deneb.enyo.de>, Florian Weimer writes:
* Stephane Bortzmeyer:
It is highly improbable that all these name servers are unreachable from you. Therefore, I suspect that *content* is the issue. RIPE-NCC zones are signed with DNSSEC. Are you sure you do not have a broken middlebox which deletes DNSSEC-signed answers?
Ahem. dig's +trace doesn't use EDNS by default, so no signatures and (usually) no large responses.
I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4.
And that is the solution! (and I upgraded the resolver on all the machines to 9.6.1-P1 before getting that far.) Thanks, Michelle
participants (13)
-
Christopher Morrow -
Florian Weimer -
JC Dill -
Joly MacFie -
Larry Sheldon -
Mark Andrews -
Mark Scholten -
Michelle Sullivan -
Seth Mattinen -
Stephane Bortzmeyer -
Steven Bellovin -
Tony Finch -
Wilkinson, Alex