March 2010 - Test - lists.nanog.org

RE: NANOG Digest, Vol 26, Issue 142
by Stephen Tandy 30 Mar '10

30 Mar '10

Sent from my Windows® phone. -----Original Message----- From: nanog-request(a)nanog.org <nanog-request(a)nanog.org> Sent: 30 March 2010 13:00 To: nanog(a)nanog.org <nanog(a)nanog.org> Subject: NANOG Digest, Vol 26, Issue 142 Send NANOG mailing list submissions to nanog(a)nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request(a)nanog.org You can reach the person managing the list at nanog-owner(a)nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Robert Kisteleki) 2. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Phil Regnauld) 3. Re: IPv4 ANYCAST setup (Jens Link) 4. Re: IPv4 ANYCAST setup (bmanning(a)vacation.karoshi.com) 5. Re: IPv4 ANYCAST setup (Tony Finch) 6. Re: Useful URL for network operators (Valdis.Kletnieks(a)vt.edu) 7. RE: Auto MDI/MDI-X + conference rooms + bored == loop (William Mullaney) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Mar 2010 11:37:49 +0200 From: Robert Kisteleki <robert(a)ripe.net> Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: nanog(a)nanog.org Message-ID: <4BB1C66D.7000808(a)ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I must observe that these are not really the links you'd want to give your end users to check out. Their audience is very different. While the article on RIPE Labs comes close, they don't really answer the "does it work or does it not?" question with a green/red light, and they don't provide a good explanation to the audience Randy is referring to. Robert On 2010.03.30. 11:29, Phil Regnauld wrote: > Randy Bush (randy) writes: >> >> i.e. what can we do to maximize the odds that the victim will quickly >> find the perp, as opposed to calling our our tech support lines? > > Ah yes, there was the second good reason for actually helping netops > and security officers :) > > Tools: > > https://www.dns-oarc.net/oarc/services/replysizetest > > https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources, > under troubleshooting: > http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues > http://secspider.cs.ucla.edu/ > > Info sheets: > > http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-tech… > (click English, top right) > > ... plenty of links there too. > > Cheers, > Phil > ------------------------------ Message: 2 Date: Tue, 30 Mar 2010 11:52:27 +0200 From: Phil Regnauld <regnauld(a)nsrc.org> Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: Robert Kisteleki <robert(a)ripe.net> Cc: nanog(a)nanog.org Message-ID: <20100330095226.GE24147(a)macbook.catpipe.net> Content-Type: text/plain; charset=us-ascii Robert Kisteleki (robert) writes: > I must observe that these are not really the links you'd want to > give your end users to check out. Their audience is very different. > While the article on RIPE Labs comes close, they don't really answer > the "does it work or does it not?" question with a green/red light, > and they don't provide a good explanation to the audience Randy is > referring to. Fair enough. Some simple "check your DNS reply size test [what is this ?]" page ought to be set up, with a simple explanagtion. "checkmydns.org" is available. If I get 5 minutes... :) ------------------------------ Message: 3 Date: Tue, 30 Mar 2010 11:58:16 +0200 From: Jens Link <lists(a)quux.de> Subject: Re: IPv4 ANYCAST setup To: nanog(a)nanog.org Message-ID: <87mxxqb07b.fsf(a)bowmore.quux.de> Content-Type: text/plain; charset=us-ascii "Kevin Oberman" <oberman(a)es.net> writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Let me guess: They also completely blocked ICMP. I always tell these customers to switch to IPv6 real fast and to turn of ICMPv6 to make their networks really secure. ;-) > I will say that these were at federal government facilities. I hope the > commercial world is a bit more in touch with reality. You can find clueless people everywhere. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink(a)guug.de | ------------------------------------------------------------------------- ------------------------------ Message: 4 Date: Tue, 30 Mar 2010 10:05:27 +0000 From: bmanning(a)vacation.karoshi.com Subject: Re: IPv4 ANYCAST setup To: Randy Bush <randy(a)psg.com> Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> Message-ID: <20100330100527.GC30288(a)vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii On Tue, Mar 30, 2010 at 05:43:25PM +0900, Randy Bush wrote: > >>> I have talked to multiple security officers (who are generally not > >>> really knowledgeable on networks) who had 53/tcp blocked and none > >>> have yet agreed to change it. > >> patience. when things really start to break, and the finger of fate > >> points at them, clue may arise. > > 36 days until all root servers have DNSSEC data, at which point large > > replies become normal. > > are end user tools, i.e. a web click a button, available so they can > test if they are behind a clueless security id10t? no - in part because using a browser to debug DNS involves a third app (and likly a third/forth) platform. the nifty OARC testpoint is nearly worthless for real operations, since its not located at/near a DNS authoritative source. the K testpoint is good, I should prolly put back the one off B. > is there good simple end user docco they are somewhat likely to find > when things break for them? not yet. in part because out of the few simple parts, many, many combinations of failure can occur. ) MTU strictures: v6/v4 tunneling v6/v4 MTU clamping ) Fragmenation UDP ) Port blocking ) Resolver Behaviour EDNS awareness > i.e. what can we do to maximize the odds that the victim will quickly > find the perp, as opposed to calling our our tech support lines? thats a tough call. as tech support staff, we are almost always an outside observer on the path btwn the victim and the perp. troubleshooting is going to be problematic. > > randy ------------------------------ Message: 5 Date: Tue, 30 Mar 2010 11:53:12 +0100 From: Tony Finch <dot(a)dotat.at> Subject: Re: IPv4 ANYCAST setup To: nanog(a)nanog.org Message-ID: <alpine.LSU.2.00.1003301152280.1923(a)hermes-2.csi.cam.ac.uk> Content-Type: TEXT/PLAIN; charset=US-ASCII "Kevin Oberman" <oberman(a)es.net> writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Do they also believe that all DNS replies are less than 512 bytes? :-) Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ------------------------------ Message: 6 Date: Tue, 30 Mar 2010 07:33:39 -0400 From: Valdis.Kletnieks(a)vt.edu Subject: Re: Useful URL for network operators To: Jim Mercer <jim(a)reptiles.org> Cc: nanog(a)nanog.org Message-ID: <1191.1269948819@localhost> Content-Type: text/plain; charset="us-ascii" On Tue, 30 Mar 2010 05:34:06 EDT, Jim Mercer said: > Once again, please ignore Jim Mercer. > He should do more homeworks too. He's said similar about a number of people who have more operations clue than he does. I'd comment, except Woody Allen already did it better: http://www.youtube.com/watch?v=9wWUc8BZgWE > a) I have never heard of Randy Bush That's OK, I encoura.. oh nevermind, it's shooting fish in a barrel. ;)

1 0

RE: NANOG Digest, Vol 26, Issue 142
by Stephen Tandy 30 Mar '10

30 Mar '10

Sent from my Windows® phone. -----Original Message----- From: nanog-request(a)nanog.org <nanog-request(a)nanog.org> Sent: 30 March 2010 13:00 To: nanog(a)nanog.org <nanog(a)nanog.org> Subject: NANOG Digest, Vol 26, Issue 142 Send NANOG mailing list submissions to nanog(a)nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request(a)nanog.org You can reach the person managing the list at nanog-owner(a)nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Robert Kisteleki) 2. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Phil Regnauld) 3. Re: IPv4 ANYCAST setup (Jens Link) 4. Re: IPv4 ANYCAST setup (bmanning(a)vacation.karoshi.com) 5. Re: IPv4 ANYCAST setup (Tony Finch) 6. Re: Useful URL for network operators (Valdis.Kletnieks(a)vt.edu) 7. RE: Auto MDI/MDI-X + conference rooms + bored == loop (William Mullaney) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Mar 2010 11:37:49 +0200 From: Robert Kisteleki <robert(a)ripe.net> Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: nanog(a)nanog.org Message-ID: <4BB1C66D.7000808(a)ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I must observe that these are not really the links you'd want to give your end users to check out. Their audience is very different. While the article on RIPE Labs comes close, they don't really answer the "does it work or does it not?" question with a green/red light, and they don't provide a good explanation to the audience Randy is referring to. Robert On 2010.03.30. 11:29, Phil Regnauld wrote: > Randy Bush (randy) writes: >> >> i.e. what can we do to maximize the odds that the victim will quickly >> find the perp, as opposed to calling our our tech support lines? > > Ah yes, there was the second good reason for actually helping netops > and security officers :) > > Tools: > > https://www.dns-oarc.net/oarc/services/replysizetest > > https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources, > under troubleshooting: > http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues > http://secspider.cs.ucla.edu/ > > Info sheets: > > http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-tech… > (click English, top right) > > ... plenty of links there too. > > Cheers, > Phil > ------------------------------ Message: 2 Date: Tue, 30 Mar 2010 11:52:27 +0200 From: Phil Regnauld <regnauld(a)nsrc.org> Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: Robert Kisteleki <robert(a)ripe.net> Cc: nanog(a)nanog.org Message-ID: <20100330095226.GE24147(a)macbook.catpipe.net> Content-Type: text/plain; charset=us-ascii Robert Kisteleki (robert) writes: > I must observe that these are not really the links you'd want to > give your end users to check out. Their audience is very different. > While the article on RIPE Labs comes close, they don't really answer > the "does it work or does it not?" question with a green/red light, > and they don't provide a good explanation to the audience Randy is > referring to. Fair enough. Some simple "check your DNS reply size test [what is this ?]" page ought to be set up, with a simple explanagtion. "checkmydns.org" is available. If I get 5 minutes... :) ------------------------------ Message: 3 Date: Tue, 30 Mar 2010 11:58:16 +0200 From: Jens Link <lists(a)quux.de> Subject: Re: IPv4 ANYCAST setup To: nanog(a)nanog.org Message-ID: <87mxxqb07b.fsf(a)bowmore.quux.de> Content-Type: text/plain; charset=us-ascii "Kevin Oberman" <oberman(a)es.net> writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Let me guess: They also completely blocked ICMP. I always tell these customers to switch to IPv6 real fast and to turn of ICMPv6 to make their networks really secure. ;-) > I will say that these were at federal government facilities. I hope the > commercial world is a bit more in touch with reality. You can find clueless people everywhere. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink(a)guug.de | ------------------------------------------------------------------------- ------------------------------ Message: 4 Date: Tue, 30 Mar 2010 10:05:27 +0000 From: bmanning(a)vacation.karoshi.com Subject: Re: IPv4 ANYCAST setup To: Randy Bush <randy(a)psg.com> Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> Message-ID: <20100330100527.GC30288(a)vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii On Tue, Mar 30, 2010 at 05:43:25PM +0900, Randy Bush wrote: > >>> I have talked to multiple security officers (who are generally not > >>> really knowledgeable on networks) who had 53/tcp blocked and none > >>> have yet agreed to change it. > >> patience. when things really start to break, and the finger of fate > >> points at them, clue may arise. > > 36 days until all root servers have DNSSEC data, at which point large > > replies become normal. > > are end user tools, i.e. a web click a button, available so they can > test if they are behind a clueless security id10t? no - in part because using a browser to debug DNS involves a third app (and likly a third/forth) platform. the nifty OARC testpoint is nearly worthless for real operations, since its not located at/near a DNS authoritative source. the K testpoint is good, I should prolly put back the one off B. > is there good simple end user docco they are somewhat likely to find > when things break for them? not yet. in part because out of the few simple parts, many, many combinations of failure can occur. ) MTU strictures: v6/v4 tunneling v6/v4 MTU clamping ) Fragmenation UDP ) Port blocking ) Resolver Behaviour EDNS awareness > i.e. what can we do to maximize the odds that the victim will quickly > find the perp, as opposed to calling our our tech support lines? thats a tough call. as tech support staff, we are almost always an outside observer on the path btwn the victim and the perp. troubleshooting is going to be problematic. > > randy ------------------------------ Message: 5 Date: Tue, 30 Mar 2010 11:53:12 +0100 From: Tony Finch <dot(a)dotat.at> Subject: Re: IPv4 ANYCAST setup To: nanog(a)nanog.org Message-ID: <alpine.LSU.2.00.1003301152280.1923(a)hermes-2.csi.cam.ac.uk> Content-Type: TEXT/PLAIN; charset=US-ASCII "Kevin Oberman" <oberman(a)es.net> writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Do they also believe that all DNS replies are less than 512 bytes? :-) Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ------------------------------ Message: 6 Date: Tue, 30 Mar 2010 07:33:39 -0400 From: Valdis.Kletnieks(a)vt.edu Subject: Re: Useful URL for network operators To: Jim Mercer <jim(a)reptiles.org> Cc: nanog(a)nanog.org Message-ID: <1191.1269948819@localhost> Content-Type: text/plain; charset="us-ascii" On Tue, 30 Mar 2010 05:34:06 EDT, Jim Mercer said: > Once again, please ignore Jim Mercer. > He should do more homeworks too. He's said similar about a number of people who have more operations clue than he does. I'd comment, except Woody Allen already did it better: http://www.youtube.com/watch?v=9wWUc8BZgWE > a) I have never heard of Randy Bush That's OK, I encoura.. oh nevermind, it's shooting fish in a barrel. ;)

1 0

Re: "Is TDM going the way of dial-up?"
by msokolov＠ivan.Harhan.ORG 30 Mar '10

30 Mar '10

Kevin Oberman <oberman(a)es.net> wrote: > And, if you are using a 1988 TCP stack on a 4.3 system, you are not > likely to ever efficiently utilize a higher speed link What higher speed link? I'm very happy with 384 kbps symmetric, using SDSL as ARPANET replacement. I have designed and built my own SDSL to EIA-530 CSU/DSU so I can use a Cisco 2500 router instead of that nasty new-fangled Netopia which has (oh horror!) RJ45 Ethernet instead of proper AUI. Oh, did I forget to mention that my Ethernet is coaxial? To me all that UTP stuff isn't true Ethernet. > and will not > behave well on any link. TCP has come a long way in the past 12 > years. (Of course, I can't guess what "mostly unchanged" means.) Backward compatibility rules! MS

2 1

"Is TDM going the way of dial-up?"
by Rick Ernst 30 Mar '10

30 Mar '10

I've noticed over the last 3 years or so that TDM, specifically T-1, access and transport has been in a steady decline. Customers are moving to FTTH and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A recent upgrade from OC-3 to GigE transport actually saved us a large chunk of money. I'm wondering if others are seeing the same behavior, if it's market-dependant, or if I'm just imagining things. I'm working on building new infrastructure and my current thoughts are to minimize my TDM footprint. It would be useful to get a better feel if this is an overall trend or something local. Thoughts? Thanks,

11 13

Re: "Is TDM going the way of dial-up?"
by msokolov＠ivan.Harhan.ORG 30 Mar '10

30 Mar '10

Rick Ernst <nanog(a)shreddedmail.com> wrote: > I've noticed over the last 3 years or so that TDM, specifically T-1, access > and transport has been in a steady decline. Customers are moving to FTTH > and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken > an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A > recent upgrade from OC-3 to GigE transport actually saved us a large chunk > of money. > > I'm wondering if others are seeing the same behavior, if it's > market-dependant, or if I'm just imagining things. Unfortunately what you are seeing is indeed where the world is going, and it is extremely painful to watch. My personal preference is the direct opposite of that: Ethernet for non-LAN use is my very antithesis, I hate it to the core of my being. V.35/HDLC forever for me! I will continue using HDLC over traditional synchronous serial WAN media for as long as I am alive. MS P.S. This message is being sent from a VAX running a variant of 4.3BSD (Quasijarus). Almost the entire ARPA Internet software stack that's running on my VAXen is mostly unchanged from how it was in 1988.

2 1

DNS TXT field usage ?
by jul 29 Mar '10

29 Mar '10

Hello, While watching some parked domains, I recently observed one which has a TXT field containing some crypto value, something like a ssh key/RSA 512 or 1024 output (only the crypto part 'cvxvcvcxvcxv=' ). For now, I have referenced the following usage of TXT - DNS Server information/version - SPF (format like "v=spf1 a mx -all") [1] - DKIM (format like "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3 [...] YA+OwSMWQIDAQAB", but always in _domainkey.<domain>) [2] - not DNSSec as I supposed first (only DNSKEY, RR, RSIG, NSEC, not TXT) Does someone know at what kind of usage this kind of value could correspond ? (even if, nearly everything is possible) Maybe somebody knows of a webpage referencing common usage of DNS fields ? I found http://www.iana.org/assignments/dns-parameters but it points only on RFC not practical usage. Thanks a lot. Best regards, Jul [1] http://en.wikipedia.org/wiki/Sender_Policy_Framework [2] http://www.ietf.org/rfc/rfc4871.txt (7.4) Note: current RFC referencing TXT field is http://www.ietf.org/rfc/rfc1035.txt "TXT RRs are used to hold descriptive text."

4 3

NTP clock source
by Kyle Bader 29 Mar '10

29 Mar '10

Can anyone recommend a solid clock souce (stratum 0) that's not overly expensive? The only stuff I've found so far is ESE, can anyone recommend them or conversely has anyone had any problems with their hardware? -- Kyle

15 15

things to test
by Mikael Abrahamsson 29 Mar '10

29 Mar '10

I've been pondering what aspects of a residential broadband connection that would be worthwhile in testing, which would also be some kind of incentive for ISPs to start doing "better". Some things that comes to mind: speed latency to some points geographically near the user MTU of the connection If PMTUD works or not queueing (FIFO or something "better") antispoofing (BCP38) compliance filtering (IPv6 transition protocols for instance, lots more possible) buffer depth ingress/egress ECN ISP provided DNS resolver properties (DNSSEC, EDNS etc) I'm sure there are lots more, and this could probably not be done using a web browser driven application, but instead would have to be an application, thus harder to get people to use generally. Any work being done in this area already that someone can point to? I'd also like to use some of this tech to do "web server tests", especially when it comes to PMTUD working, especially when for a IPv6 world it would be nice to have an easily available testing suite for these basic mechanisms. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

3 3

Using private APNIC range in US
by Jaren Angerbauer 28 Mar '10

28 Mar '10

Hi all, I have a client here in the US, that I just discovered is using a host of private IPs that (as I understand) belong to APNIC (i.e. 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming that the addresses probably nat to a [US] public IP. I'm not familiar enough with the use of private address space outside of ARIN (i.e. 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and accessible it must be working for them. I'm just wondering if there is any recommendation or practice around this -- using private IP ranges from another country. Thanks. --Jaren

21 25

Blacklist entry
by Larry Sheldon 28 Mar '10

28 Mar '10

For some reason I am getting a ton of "DNR" spam from blackberry.net with Subject: lines that imply that somebody here is the culprit. (Hence this message here.) I am blacklisting "blackberry.net" in an effort to reduce the spam load here. -- Democracy: Three wolves and a sheep voting on the dinner menu. 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

2 2