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. miche...@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 miche...@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 miche...@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.
Re: in-addr.arpa server problems for europe?
On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan matt...@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.)
Re: in-addr.arpa server problems for europe?
Stephane Bortzmeyer wrote: On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan matt...@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
RE: in-addr.arpa server problems for europe?
-Original Message- From: Stephane Bortzmeyer [mailto:bortzme...@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 matt...@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.
Re: in-addr.arpa server problems for europe?
Michelle Sullivan wrote: Stephane Bortzmeyer wrote: On Mon, Feb 15, 2010 at 10:22:17AM +0100, Michelle Sullivan miche...@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 miche...@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 .352606INNSL.ROOT-SERVERS.NET. .352606INNSM.ROOT-SERVERS.NET. .352606INNSA.ROOT-SERVERS.NET. .352606INNSB.ROOT-SERVERS.NET. .352606INNSC.ROOT-SERVERS.NET. .352606INNSD.ROOT-SERVERS.NET. .352606INNSE.ROOT-SERVERS.NET. .352606INNSF.ROOT-SERVERS.NET. .352606INNSG.ROOT-SERVERS.NET. .352606INNSH.ROOT-SERVERS.NET. .352606INNSI.ROOT-SERVERS.NET. .352606INNSJ.ROOT-SERVERS.NET. .352606INNSK.ROOT-SERVERS.NET. ;; Received 511 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 81.in-addr.arpa.86400INNSSNS-PB.ISC.ORG. 81.in-addr.arpa.86400INNSTINNIE.ARIN.NET. 81.in-addr.arpa.86400INNSNS3.NIC.FR. 81.in-addr.arpa.86400INNSSEC1.APNIC.NET. 81.in-addr.arpa.86400INNSSEC3.APNIC.NET. 81.in-addr.arpa.86400INNSSUNIC.SUNET.SE. 81.in-addr.arpa.86400INNSNS-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 miche...@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.INPTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa.172800INNSproof.rain.fr. 255.81.in-addr.arpa.172800INNSns.ripe.net. 255.81.in-addr.arpa.172800INNSbow.rain.fr. ;; ADDITIONAL SECTION: ns.ripe.net.172800INA193.0.0.193 ns.ripe.net.172800IN2001: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 miche...@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.INPTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa.172800INNSns.ripe.net. 255.81.in-addr.arpa.172800INNSbow.rain.fr. 255.81.in-addr.arpa.172800INNSproof.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 miche...@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.INPTR ;; AUTHORITY SECTION: 164.255.81.in-addr.arpa. 3600INNSproof.rain.fr. 164.255.81.in-addr.arpa. 3600INNSbow.rain.fr. ;; Query time: 322 msec ;; SERVER: 193.0.0.193#53(193.0.0.193) ;; WHEN: Mon Feb 15 23:30:03 2010 ;;
Re: in-addr.arpa server problems for europe? [SEC=UNCLASSIFIED]
0n Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote: Michelle Sullivan wrote: miche...@enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 miche...@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.
Re: in-addr.arpa server problems for europe?
On Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan matt...@sorbs.net wrote a message of 298 lines which said: miche...@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).
Re: in-addr.arpa server problems for europe?
On Mon, Feb 15, 2010 at 08:30:43PM +0800, Wilkinson, Alex alex.wilkin...@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.
Re: in-addr.arpa server problems for europe?
On Mon, Feb 15, 2010 at 01:12:55PM +0100, Mark Scholten m...@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...
Re: in-addr.arpa server problems for europe? [SEC=UNCLASSIFIED]
Wilkinson, Alex wrote: 0n Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote: Michelle Sullivan wrote: miche...@enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 miche...@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
RE: in-addr.arpa server problems for europe?
-Original Message- From: Stephane Bortzmeyer [mailto:bortzme...@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 m...@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.
Re: in-addr.arpa server problems for europe?
Stephane Bortzmeyer wrote: On Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan matt...@sorbs.net wrote a message of 298 lines which said: miche...@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 miche...@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.INPTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa.172800INNSbow.rain.fr. 255.81.in-addr.arpa.172800INNSproof.rain.fr. 255.81.in-addr.arpa.172800INNSns.ripe.net. 255.81.in-addr.arpa.7200INNSEC0.26.81.in-addr.arpa. NS RRSIG NSEC 255.81.in-addr.arpa.7200INRRSIGNSEC 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.172800INA193.0.0.193 ns.ripe.net.172800IN2001:610:240:0:53::193 ns.ripe.net.172800INRRSIGA 5 3 172800 20100317112654 20100215112654 51207 ripe.net. NWJBUydKjOtdlzqSAUkdOD3gMPLsKEQqE2z5LLvOmsdjltrJuQmkk2it bS+iyh4lzffi2Zc39D6rscy+MuNAnHNplnwUpIu2zOVAJwKs8NuChbon MfCS5K9Q0uEbYaiH1q+AIzekkPjhKfA/8uFFKTyw3fyQyoA6PXp+tbin GvwUdsrKzvpFrA7yiK4mlExfNnmcN7Qm ns.ripe.net.172800INRRSIG 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
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On Fri, Feb 12, 2010 at 08:16:56AM +1100, Mark Andrews wrote: If you can't get native IPv6 then use a tunneled service like Hurricane Electric's (HE.NET). It is qualitatively better than 6to4 as it doesn't require random nodes on the net to be performing translation services for you which you can't track down the administrators of. You can get /48's from HE. Our external IPv6 web accesses are still very low, but have grown linearly over the last five years from 0.1% in 2005/06 to 0.5% of total web traffic now. Internally of course our figures are higher. Of that IPv6 traffic, 1% comes from 2002::/16 prefixes. Even less from Teredo prefixes. I guess we could run stats against known TB prefixes to determine who is using those. -- Tim
Noise (was Re: in-addr.arpa server problems for europe?)
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
Re: dns interceptors [SEC=UNCLASSIFIED]
I like Ben Goldacre's take on stupid email disclaimers: READ CAREFULLY. By reading this email, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. If you are anything other than a friend or an institutional professional colleague and you are writing to me about Bad Science stuff then it is reasonable to assume that I might quote our discussion in my writing, usually anonymously. http://bengoldacre.posterous.com/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
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. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: Noise (was Re: in-addr.arpa server problems for europe?)
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
Re: Noise (was Re: in-addr.arpa server problems for europe?)
On Mon, Feb 15, 2010 at 12:51 PM, JC Dill jcdill.li...@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
Re: in-addr.arpa server problems for europe?
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
RE: in-addr.arpa server problems for europe?
-Original Message- From: Tony Finch [mailto:fa...@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.
Re: in-addr.arpa server problems for europe?
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
DNSSEC Readiness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? It seems like this is something that will become a front and center issue for help desks everywhere pretty quick. :) Ideally the more we can stave off issues through proactive testing/fixing the better. - -- Charles N Wyble Linux Systems Engineer char...@knownelement.com (818)280-7059 http://www.knownelement.com Unless agreed upon, assume everything in this e-mail might be blogged. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5jxoACgkQJmrRtQ6zKE94eQCghyDn96HG2g7G1MDogj/yy1WB GFQAn22n3a48Mt9ssiwfyqN1Ne0N+X6L =Xt79 -END PGP SIGNATURE-
Re: dns interceptors
On Sun, 14 Feb 2010 18:59:56 EST, Steven Bellovin said: Yes -- and as a reward for your expertise, you get to explain the problem with a transparent DNS proxy to the judge. For bonus points, explain it to a jury The transparent DNS proxies aren't the problem. It's the translucent ones of undetermined opacity that just don't respond to cleaning with Windex that are the problem... pgpbqeBR0DEJG.pgp Description: PGP signature
Re: DNSSEC Readiness
On Mon, 15 Feb 2010, Charles N Wyble wrote: How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? Here's my summary of the situation (as of a couple of months ago) with links to a few key resources: http://fanf.livejournal.com/104774.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: in-addr.arpa server problems for europe?
* 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.
Re: DNSSEC Readiness
* Charles N. Wyble: How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? For now, running (with a real resolver address instead of 192.0.2.1) dig @192.0.2.1 $RANDOM. +dnssec and checking if a certain percentage of the responses include DNSSEC data. This means that your resolver can get data from DURZ-enabled servers, so you should be fine when the root is signed. If your resolvers are not security-aware, use dig @192.0.2.1 . NSEC dig @192.0.2.1 . RRSIG dig @192.0.2.1 . DNSKEY but you can run this variant of the test only once per day. If you never, ever get any DNSSEC data for these queries, you will very likely have a problem once all root servers have switched to serving DURZ (and later DNSSEC) data. It seems like this is something that will become a front and center issue for help desks everywhere pretty quick. :) Why do you think so? Would you even notice if your webmail provider switches to HTTPS by default (or back to HTTP)?
Re: DNSSEC Readiness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Finch wrote: On Mon, 15 Feb 2010, Charles N Wyble wrote: How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? Here's my summary of the situation (as of a couple of months ago) with links to a few key resources: http://fanf.livejournal.com/104774.html Tony. Most interesting. Thanks. - From https://www.dns-oarc.net/oarc/services/replysizetest char...@charles-laptop:~] dig +short rs.dns-oarc.net txt rst.x3827.rs.dns-oarc.net. rst.x3837.x3827.rs.dns-oarc.net. rst.x3843.x3837.x3827.rs.dns-oarc.net. 8.0.23.143 sent EDNS buffer size 4096 8.0.23.143 DNS reply size limit is at least 3843 Tested at 2010-02-15 19:03:47 UTC char...@charles-laptop:~] I have a local BIND server I use for DNS. It's whatever Ubuntu 9.10 installs with apt-get, and a cisco 1841 as my edge router. I imagine that is a pretty standard setup in a lot of user sites (linux with bind and a cisco router of some sort). Will do further investigation. - -- Charles N Wyble Linux Systems Engineer char...@knownelement.com (818)280-7059 http://www.knownelement.com Unless agreed upon, assume everything in this e-mail might be blogged. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5mxQACgkQJmrRtQ6zKE99PwCgh5ikE7LRywT610jG4QkkTE4n lyoAoMT67y/fGQHadGC6aHyRzRzQsxZi =K8sW -END PGP SIGNATURE-
Re: DNSSEC Readiness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Weimer wrote: * Charles N. Wyble: It seems like this is something that will become a front and center issue for help desks everywhere pretty quick. :) Why do you think so? Would you even notice if your webmail provider switches to HTTPS by default (or back to HTTP)? Well I would, but most users won't. :) However they will certainly start complaining when DNS stops working. Of course they won't know that's what the issue is, but they will call saying the internet is down. - -- Charles N Wyble Linux Systems Engineer char...@knownelement.com (818)280-7059 http://www.knownelement.com Unless agreed upon, assume everything in this e-mail might be blogged. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5m4cACgkQJmrRtQ6zKE9y7gCfVRwsS9nIMXP37581d0hsUkDD pHYAoM/3IrNmKbRKdwaEPEbxH1nCyntx =e45k -END PGP SIGNATURE-
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
* Igor Ybema: We know we should push our provider to support native IPv6, and we do. But this should not stop us using IPv6 6to4. You should complain to the DENIC member you use, or perhaps the DENIC ops team. Perhaps it's a simple mistake. NANOG isn't the right forum for this.
Re: Noise (was Re: in-addr.arpa server problems for europe?)
On 2/15/2010 1:19 PM, JC Dill wrote: I don't see the point you are trying to make in this discussion. I can see that. I don't have a clue bat big enough for the task. Are you saying Troll skat. I'm out. -- 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
Re: DNSSEC Readiness
* Charles N. Wyble: However they will certainly start complaining when DNS stops working. Of course they won't know that's what the issue is, but they will call saying the internet is down. Okay, then the first way I mentioned for checking should be sufficient. Well, perhaps make it dig $RANDOM.xxx.xxx.xxx.xx. +dnssec instead, so that you'll receive an even larger response. But actually, you already know that your DNS can cope with responses 512 bytes, if you look at this: dig @k.root-servers.net +trace +all +dnssec aol.com MX Certainly, your users would complain if they couldn't send mail to AOL. 8-)
Re: DNSSEC Readiness
Charles N Wyble wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? It seems like this is something that will become a front and center issue for help desks everywhere pretty quick. :) Ideally the more we can stave off issues through proactive testing/fixing the better. FWIW - .se did some consumer research during their DNSSec launch. I belive there will be a new study. Tests of Consumer Broadband Routers in Sweden (DNSSEC) in 2008: http://www.iis.se/docs/Routertester_en.pdf -- amar
Re: DNSSEC Readiness
FWIW - .se did some consumer research during their DNSSec launch. I belive there will be a new study. Tests of Consumer Broadband Routers in Sweden (DNSSEC) in 2008: http://www.iis.se/docs/Routertester_en.pdf Seriously, who puts recursive DNS resolvers behind consumer broadband routers? 8-) Seriously, these studies measure the wrong thing. I don't think any vendor has announced yet to switch on DNSSEC validation in stub resolvers by default.
AS16387 leaking routes
Has anyone seen the strange activity from AS16387? Did they leak their entire table? Our route collectors are showing AS16387 originating large numbers of prefixes. It looks like we caught the tail end of this activity as they are now announcing updates with massive amounts of prepending. Here's an example. We have several pages worth of this. 20100215|15:17:58|1266268678678|164.128.32.11|3303|ORIGIN_CHANGE|95.79.192/19|34533|16387 20100215|15:18:58|1266268738707|164.128.32.11|3303|BGPMON_PATH|3303,3303,3303,3303,3303,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6 453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453, 6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453 ,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,6453,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,8744,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,34533,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387,16387 Ernest McCracken Research Assistant
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On 16/02/2010, at 5:03 AM, Tim Chown wrote: On Fri, Feb 12, 2010 at 08:16:56AM +1100, Mark Andrews wrote: If you can't get native IPv6 then use a tunneled service like Hurricane Electric's (HE.NET). It is qualitatively better than 6to4 as it doesn't require random nodes on the net to be performing translation services for you which you can't track down the administrators of. You can get /48's from HE. Our external IPv6 web accesses are still very low, but have grown linearly over the last five years from 0.1% in 2005/06 to 0.5% of total web traffic now. Internally of course our figures are higher. Of that IPv6 traffic, 1% comes from 2002::/16 prefixes. Even less from Teredo prefixes. I guess we could run stats against known TB prefixes to determine who is using those. You are very unlikely to get traffic from Teredo, because: 1) Windows only asks for if it has non-Teredo IPv6 connectivity 2) When Windows has non-Teredo IPv6 connectivity and so can ask for , preference for reaching your web content is going to be non-Teredo IPv6 - IPv4 - Teredo, due to the prefix policy table, unless you have an in 2001::/32 (Teredo space), in which case it will prefer IPv4 - Teredo. With 6to4, Windows hosts will ask for , and will prefer non-6to4 IPv6 over 6to4 over IPv4. I'm a little surprised at how little 6to4 traffic you get. Teredo gets most use when an application asks for a connection to a certain IPv6 address, without DNS. This is most common in peer to peer - you're not going to levels of web traffic and P2P traffic using Teredo that are comparable ratios to IPv4. My expectation is that lines in your web logs in 2001::/32 have user agent strings indicating non-Windows hosts - or perhaps someone has miredo running on a proxy server, or perhaps the users' non-Teredo IPv6 AND IPv4 paths to you were broken when they tried to make a request. Stranger things have happened.. I wrote some code that will allow you to better understand the connectivity that end users of your web content have - when they visit your site it has them get 1x1 px transparent GIF images from various different hostnames with different characteristics in the DNS, and then reports back which loaded and how long. http://www.braintrust.co.nz/ipv6wwwtest/ Wikipedia were running this for a while, on every 100th hit. They did a modification to this where they also had a large image to test for pmtud errors. Google are using a similar technique to test IPv6 capabilities and networks. I'll add something with the pmtud stuff in the next week or so, and I'll also push the code to github. You'll probably want to make you own changes based on what you're interested in, also. -- Nathan Ward
Re: AS16387 leaking routes
On Mon, Feb 15, 2010 at 5:32 PM, Ernest Andrew McCracken (emccrckn) emccr...@memphis.edu wrote: Has anyone seen the strange activity from AS16387? Did they leak their entire table? Our route collectors are showing AS16387 originating large numbers of prefixes. It looks like we caught the tail end of this activity as they are now announcing updates with massive amounts of prepending. 16387 is a uunet customer, it seems, who's only annoucing (now) 2 prefixes... Robtex seems to support them only having a single upstream (701). I think 701 still prefix-lists all their customers. You saw this through 3303 without 701 (it seems?) in the path, The orignal prefix looks actually like 95.79.192.0/19 in the path: 34533 16387 that looks like ESamara trying to poison their paths toward 'healthy directions, LLC. maybe ESamara saw something they disliked from this part of the network? -Chris
Re: in-addr.arpa server problems for europe?
In message 87iq9ys512@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 ` 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: ma...@isc.org
RE: AS16387 leaking routes
There are other ASN changes as well as from other peers. Here are some just a few minutes old. Date|Time|timestamp|Peer IP|Peer ASN|Event Description|Prefix|old AS|new AS 20100215|17:11:13|1266275473183|164.128.32.11|3303|ORIGIN_CHANGE|192.156.97/24|5651|16387 20100215|17:11:13|1266275473309|164.128.32.11|3303|PING REQUEST|198.133.160.1 20100215|17:11:14|1266275474310|164.128.32.11|3303|PING RESPONSE|198.133.160.1|NO RESPONSE 20100215|17:11:14|1266275474310|164.128.32.11|3303|PING REQUEST|198.133.160.2 20100215|17:11:15|1266275475311|164.128.32.11|3303|PING RESPONSE|198.133.160.2|NO RESPONSE 20100215|17:10:05|1266275405989|164.128.32.11|3303|ORIGIN_CHANGE|91.200.172/22|43929|16387 20100215|17:05:13|1266275113867|164.128.32.11|3303|ORIGIN_CHANGE|193.169.44/23|49381|16387 20100215|16:59:02|1266274742071|154.11.11.113|852|ORIGIN_CHANGE|20.132.1/24|21877|16387 20100215|16:55:23|1266274523372|154.11.98.225|852|ORIGIN_CHANGE|91.210.10/24|47245|16387 20100215|16:50:47|1266274247250|154.11.11.113|852|ORIGIN_CHANGE|141.197.8/23|22764|16387 all with ridiculously long paths ofc. -Ernest McCracken From: christopher.mor...@gmail.com [christopher.mor...@gmail.com] On Behalf Of Christopher Morrow [morrowc.li...@gmail.com] Sent: Monday, February 15, 2010 4:46 PM To: Ernest Andrew McCracken (emccrckn) Cc: nanog@nanog.org Subject: Re: AS16387 leaking routes On Mon, Feb 15, 2010 at 5:32 PM, Ernest Andrew McCracken (emccrckn) emccr...@memphis.edu wrote: Has anyone seen the strange activity from AS16387? Did they leak their entire table? Our route collectors are showing AS16387 originating large numbers of prefixes. It looks like we caught the tail end of this activity as they are now announcing updates with massive amounts of prepending. 16387 is a uunet customer, it seems, who's only annoucing (now) 2 prefixes... Robtex seems to support them only having a single upstream (701). I think 701 still prefix-lists all their customers. You saw this through 3303 without 701 (it seems?) in the path, The orignal prefix looks actually like 95.79.192.0/19 in the path: 34533 16387 that looks like ESamara trying to poison their paths toward 'healthy directions, LLC. maybe ESamara saw something they disliked from this part of the network? -Chris
Re: in-addr.arpa server problems for europe?
In message 201002152312.o1fncfq8098...@drugs.dv.isc.org, Mark Andrews writes: In message 87iq9ys512@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 ` 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: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: in-addr.arpa server problems for europe?
In message 017901caae69$5d9e8770$18db96...@nl, Mark Scholten writes: -Original Message- From: Tony Finch [mailto:fa...@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: ma...@isc.org
Re: DNSSEC Readiness
In message 4b798f1e.6080...@knownelement.com, Charles N Wyble writes: All, How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? It seems like this is something that will become a front and center issue for help desks everywhere pretty quick. :) Ideally the more we can stave off issues through proactive testing/fixing the better. Make the following queries from your recursive servers. If you force the query source in the nameserver add a -b address to match. dig -4 ns . +norec @l.root-servers.net dig -4 ns . +dnssec +cd +norec @l.root-servers.net dig -4 any . +dnssec +cd +norec @l.root-servers.net dig -4 any . +dnssec +cd +norec @l.root-servers.net +vc If any of them fail you need to fix your middleware and / or firewall on the box. The first +dnssec query checks that unfragmented DNSSEC responses over 512 bytes are passed. I get 801 bytes today when I run this test. The second +dnssec query checks that fragmented DNSSEC responses are passed. I get 1906 bytes today when I run this test. The third +dnsec query checks that DNSSEC responses over TCP are passed. The non +dnssec query is a control query to check that you can reach l.root-servers.net. Repeat for IPv6. dig -6 ns . +norec @l.root-servers.net dig -6 ns . +dnssec +cd +norec @l.root-servers.net dig -6 any . +dnssec +cd +norec @l.root-servers.net dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc Mark - -- Charles N Wyble Linux Systems Engineer char...@knownelement.com (818)280-7059 http://www.knownelement.com Unless agreed upon, assume everything in this e-mail might be blogged. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt5jxoACgkQJmrRtQ6zKE94eQCghyDn96HG2g7G1MDogj/yy1WB GFQAn22n3a48Mt9ssiwfyqN1Ne0N+X6L =Xt79 -END PGP SIGNATURE- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: in-addr.arpa server problems for europe?
-Original Message- From: ma...@isc.org [mailto:ma...@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$18db96...@nl, Mark Scholten writes: -Original Message- From: Tony Finch [mailto:fa...@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
Re: AS16387 leaking routes
On Mon, Feb 15, 2010 at 6:13 PM, Ernest Andrew McCracken (emccrckn) emccr...@memphis.edu wrote: There are other ASN changes as well as from other peers. Here are some just a few minutes old. Date|Time|timestamp|Peer IP|Peer ASN|Event Description|Prefix|old AS|new AS 20100215|17:11:13|1266275473183|164.128.32.11|3303|ORIGIN_CHANGE|192.156.97/24|5651|16387 don't know what to tell ya... I only see 2 routes from 16387 in routeviews or other places I can view routing info :( This isn't some off-by-one error type thing in your collector code? -Chris
Re: AS16387 leaking routes
On Mon, Feb 15, 2010 at 9:19 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Feb 15, 2010 at 6:13 PM, Ernest Andrew McCracken (emccrckn) emccr...@memphis.edu wrote: There are other ASN changes as well as from other peers. Here are some just a few minutes old. Date|Time|timestamp|Peer IP|Peer ASN|Event Description|Prefix|old AS|new AS 20100215|17:11:13|1266275473183|164.128.32.11|3303|ORIGIN_CHANGE|192.156.97/24|5651|16387 don't know what to tell ya... I only see 2 routes from 16387 in routeviews or other places I can view routing info :( This isn't some off-by-one error type thing in your collector code? Oh, robtex seems uncomplete, or RIS thinks there are other Transits for 16387: http://www.ris.ripe.net/dashboard/16387 sprint + 701 transit...(both filter customers) -Chris
Re: in-addr.arpa server problems for europe?
In message 01c201caaead$b115eda0$1341c8...@nl, Mark Scholten writes: -Original Message- From: ma...@isc.org [mailto:ma...@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$18db96...@nl, Mark Scholten writes: -Original Message- From: Tony Finch [mailto:fa...@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: ma...@isc.org
Re: in-addr.arpa server problems for europe?
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 ---
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On 16/02/2010, at 7:34 PM, Mikael Abrahamsson wrote: On Tue, 16 Feb 2010, Nathan Ward wrote: You are very unlikely to get traffic from Teredo, because: 1) Windows only asks for if it has non-Teredo IPv6 connectivity Please don't just say windows as the different versions of windows behave differently, as we've already discussed in the thread here: http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01587.html Windows XP will happily use Teredo when faced with response only. What you're describing is Vista and Win7 I guess? Yep, sorry! XP won't ask for unless it has non-Teredo connectivity though I don't think. -- Nathan Ward
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On Tue, 16 Feb 2010, Nathan Ward wrote: XP won't ask for unless it has non-Teredo connectivity though I don't think. That doesn't compute considering all the XP machines with Teredo addresses that asked for my only content. http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01582.html Of the users getting v6 only gif from non-tunnel-space, 58% were from Proxad (free.fr I believe), and then on the list came UNINET, SUNET, FUNET (university networks in .no, .se and .fi) and Hurricane electric. 98% of Teredo users run Windows XP. 88% of 6to4 users run Windows Vista. So 98% of Teredo users getting the v6only content (using DNS) was using WinXP, so it does seem it does lookups. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On 16/02/2010, at 7:47 PM, Mikael Abrahamsson wrote: On Tue, 16 Feb 2010, Nathan Ward wrote: XP won't ask for unless it has non-Teredo connectivity though I don't think. That doesn't compute considering all the XP machines with Teredo addresses that asked for my only content. http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01582.html Of the users getting v6 only gif from non-tunnel-space, 58% were from Proxad (free.fr I believe), and then on the list came UNINET, SUNET, FUNET (university networks in .no, .se and .fi) and Hurricane electric. 98% of Teredo users run Windows XP. 88% of 6to4 users run Windows Vista. So 98% of Teredo users getting the v6only content (using DNS) was using WinXP, so it does seem it does lookups. I mean non-Teredo connectivity in addition to Teredo. Perhaps they have Teredo and 6to4, and could not reach you via 6to4 so instead used Teredo, or, any number of scenarios. -- Nathan Ward
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On Tue, 16 Feb 2010, Nathan Ward wrote: Perhaps they have Teredo and 6to4, and could not reach you via 6to4 so instead used Teredo, or, any number of scenarios. I think their only IPv6 connectivity was Teredo (for instance, they're behind NAT), and thus they used it to get the IPv6 only content. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: in-addr.arpa server problems for europe?
Mark Andrews wrote: In message 87iq9ys512@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
Re: DNSSEC Readiness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Andrews wrote: In message 4b798f1e.6080...@knownelement.com, Charles N Wyble writes: All, How are folks verifying DNSSEC readiness of their environments? Any existing testing methodologies / resources that folks are using? It seems like this is something that will become a front and center issue for help desks everywhere pretty quick. :) Ideally the more we can stave off issues through proactive testing/fixing the better. Make the following queries from your recursive servers. If you force the query source in the nameserver add a -b address to match. dig -4 ns . +norec @l.root-servers.net dig -4 ns . +dnssec +cd +norec @l.root-servers.net dig -4 any . +dnssec +cd +norec @l.root-servers.net dig -4 any . +dnssec +cd +norec @l.root-servers.net +vc If any of them fail you need to fix your middleware and / or firewall on the box. The first +dnssec query checks that unfragmented DNSSEC responses over 512 bytes are passed. I get 801 bytes today when I run this test. The second +dnssec query checks that fragmented DNSSEC responses are passed. I get 1906 bytes today when I run this test. The third +dnsec query checks that DNSSEC responses over TCP are passed. The non +dnssec query is a control query to check that you can reach l.root-servers.net. Repeat for IPv6. dig -6 ns . +norec @l.root-servers.net dig -6 ns . +dnssec +cd +norec @l.root-servers.net dig -6 any . +dnssec +cd +norec @l.root-servers.net dig -6 any . +dnssec +cd +norec @l.root-servers.net +vc Mark Thank you. That's a nice quick/dirty test. All 4 commands worked. If folks are curious, my setup is Ubuntu 9.10 client, Ubuntu 9.10 server running bind and a cisco 1841 running 12.4(18). I don't have a Windows box handy to test on. How would one test with nslookup anyway? Or does it only matter if the local DNS server can do the lookup and clients will just work? Though one would still need to test from Windows if you have AD for DNS I suppose. *shrugs* Ok that's the client side. How about the server side? I'm currently using my registrars DNS servers. I haven't seen anything in their control panel about DNSSEC. One item on my TODO list is to move DNS to my BIND servers. Quick search turns up http://www.howtoforge.com/debian_bind9_master_slave_system which mentions a few commands and couple stanzas. Is that all it takes? How do you verify that you are compliant? complete? I mean SSL based PKI is pretty straightforward and I understand it and can verify that I'm compliant/complete (run my own ca, issue certs, delegate trust etc). Guess I need to do more reading on DNSSEC and how to integrate into the global DNSSEC infrastructure (such as it is and will emerge to be). I have a test domain that I use for things like this. I would like to setup DNSSEC and then positively/negatively test it. Just not sure how. Presumably one should attempt to MITM the request and make sure the resolver complains yes? This is at my home network and as such I have a great degree of latitude. For folks who have managers to report to, what are the justifications for deploying DNSSEC? I think one would do it in stages 1)Make sure their infrastructure can at least handle the DNS protocol changes that DNSSEC brings about (ie the 4 test commands above pass) 2)Implement a parallel environment with and without DNSSEC (is this possible/desirable?) 3)Sign their records. Anyway just some thoughts. Thanks to folks who have responded so far. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt6UCoACgkQJmrRtQ6zKE/bAACgtNtqptEN0X1deA+gbr+HilOx OJ0AoKyLc6soMTi4aKQI4u6HUTWxr7tt =r7yW -END PGP SIGNATURE-
