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

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:

Solution: stop using DNSSEC or checking for DNSSEC. If you think it is
usefull: look for everything that could have an impact on it.

Michelle Sullivan wrote:

Stephane Bortzmeyer 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.

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).

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.

a message of 36 lines which said:

Solution: stop using DNSSEC or checking for DNSSEC.

In 2010, it is a bit backward...

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

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.

Stephane Bortzmeyer 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

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.

You realise that two of them are signed now and the rest will be signed by
1st July?

Tony.

Larry Sheldon 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

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

Which means now is a good time to find and fix brokenness, not hope that
DNSSEC will go away.

~Seth

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.

[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).

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