March 2005 - Test - lists.nanog.org

Re: Traceroute with ASN
by Joe Shen 16 Mar '05

16 Mar '05

Yes. Can I do this on a Linux box without having to install Zebra BGP on it? Joe > > Something like this? > > [root@m4ilb0x root]# lft www.level3.net -A > > Tracing ________________________. > > TTL LFT trace to Level3.com (209.245.19.41):80/tcp > 1 [AS24730] amsterdam-c1-f1.prolocation.net > (81.23.230.1) 0.5ms > 2 [AS9057] > ge-2-0-185.ipcolo1.Amsterdam1.Level3.net > (213.244.164.197) 0.8ms > 3 [AS9057] ae-0-53.mp1.Amsterdam1.Level3.net > (213.244.165.65) 1.4ms > 4 [AS9057] ae-1-0.bbr1.London2.Level3.net > (212.187.128.46) 8.6ms > 5 [AS3356] as-0-0.bbr2.Washington1.Level3.net > (4.68.128.102) 81.3ms > 6 [AS3356] as-0-0.bbr1.Denver1.Level3.net > (209.247.11.21) 127.3ms > 7 [AS3356] so-6-0.hsa1.Denver1.Level3.net > (4.68.112.154) 127.9ms > 8 [AS3356] se3-0.public1.Broomfield1.Level3.net > (209.245.16.18) 128.7ms > ** [neglected] no reply packets received from TTL > 9 > 10 [AS3356] [target] Level3.com (209.245.19.41):80 > 129.0ms > > bye, > Raymond. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

9 9

RE: sorbs.net
by Hannigan, Martin 15 Mar '05

15 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Edward B. Dreger > Sent: Tuesday, March 15, 2005 9:04 PM > To: Niels Bakker > Cc: nanog(a)merit.edu > Subject: Re: sorbs.net > > > [ SNIP ] > > I don't follow too closely these days, but thought NANOG was moderated > now and that totally out-of-line threads would have been nipped in the > bud. Must... grep... mailboxes... The opposite. This thread is a reasonable example. People are showing displeasure at the thread and it's winding down. It's more efficient for the readers to determine what's on and off topic than the list administrators. We'll inevitably have a false positive. Using tools and visual cues is reasonable insurance against that and fosters greater communucations and hopefully cooperation amongst the readers and posters, namely us. We're still discussing the future of the mailing list on the nanog-futures(a)nanog.org list and anyone can join. If you have an opinion on how the list should operate, subscribe up and post. It's been productive for the most part. -M<

1 0

Re: Delegating /24's from a /19
by Robert Bonomi 15 Mar '05

15 Mar '05

> From owner-nanog(a)merit.edu Tue Mar 15 18:51:46 2005 > Date: Wed, 16 Mar 2005 11:51:33 +1100 (EST) > From: Mark Andrews <Mark_Andrews(a)isc.org> > To: nanog(a)merit.edu > Subject: Re: Delegating /24's from a /19 > Cc: > > > In article <2147483647.1110902129(a)imac-en0.delong.sj.ca.us> you write: > > > >--==========D714B409A8D84E671065========== > >Content-Type: text/plain; charset=us-ascii; format=flowed > >Content-Transfer-Encoding: quoted-printable > >Content-Disposition: inline > > > >>>> alex(a)pilosoft.com wrote: > >>>> > Either by doing DNS delegation on the zone boundary or by SWIP'ing > >>>> > the space to the other company. > >>>> > >>>> You can SWIP it yes, but that won't help DNS on small blocks like = > >/24's. > >>>> > >SWIPping the large block won't help. SWIPping the /24s will. > > > >>> OK, what am I missing? > >>> > >>> *ASSUMPTION*: > >>> The holder of the /16 _has_ delegated rDNS for the 32 /24s to the /19 > >>> owner. > >>> > >>> The /19 owner can, on it's nameserver, run an "authoritative" zone for > >>> the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing > >>> back to the rDNS nameserver of the /16 owner. > >>> > >Absolutely. > > > >[SNIP DNS Resolution 101 tutorial] > > > >>> > >>> _AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it > >>> pointing back to the 'parent' nameserver, this seems to work just fine. > >>> Admittedly, if the upstream block owner changes the _name_ of it's > >>> nameserver(s), the 'delegated to' nameserver requires manual tweaking, > >>> but, realistically, "how often" does _that_ happen? > >> > > > >Seems perfectly reasonable to me. > > > >> This is the worst piece of "advice" I have ever seen. Did you note that it was _not_ 'advice', that I was *ASKING* "what am I missing?" > >> > >Um, why? > > Firstly he does NOT have authority for the /16 reverse. Lots > of latent problems there. Can you elucidate on these "latent problems"? > Secondly sideways delegations don't work. Education request: _when_ and/or _how_ do they "not work"? If machine A answers only for what it knows about, and refers everything else to machine B, and machine B answers for everything except what it knows that machine A knows aboud, and refers *only* those requests to machine A it appears to me that it doesn't really matter _which_ machine you send the query to -- the "right" machine will provide the _correct_ answer. > Thirdly I'm sick and tired of having to debug stupid > schemes ISP's come up with to try to avoid SWIPing the > nameservers in situations like this. They don't work > or they don't meet the customers expectations (i.e. > they have a /24 and should just be able to use x.y.z.in-addr.arpa > and have it work reliably). I see a lot of hand-waving, and a paucity of facts there -- commonly referred to as "spreading FUD". Could you describe the failure modes of the specific scheme presented -- on the assumption that it *is* implemented as described -- and explain how/why the customer's expectations are not being met; given that the customer with the /24 customer *is* using the "x.y.z.in-addr.arpa" zone on their server. > Delegation is the DNS is strictly hierachical. I take it that this means that it is "forbidden" to make "authoritative" 'blackhole' zones for _named_ domains that you don't want any contact with, too. e.g. a corporate resolver redirecting all fetches from "*.doubleclick.com" to a bitbucket server -- one that responds with an "empty" page to any http request. And that running authoritative local rDNS zones for 10/8, 172.16/12, and 192.168/16 is also not allowed. Note: this speeds up traceroute (and similar toys) considerably, when the path goes through devices numbered in RFC1918 space. One wild-card for the entire zone, unless I happen to be using some of that space internally on _my_ network. At the 'corporate' -- not ISP -- level, I have found numerous reasons to run 'authoritative' zones for name-space that was *not* hierarchically delegated to me. e.g. when management is exchanging e-mail with people in Central America, where the name server for the recipient's domain is routinely "not available" fore extended periods, yet the MX for that mail (in a different domain) is resolvable and reachable. Running a 'bogon' authoritative name-server for that domain lets management "get _their_ job done", without the failures attributable to the problem remote name-server. It works. Yes, it requires maintainence. But it _works_. unlike the alternative. > > You either SWIP the new servers or you slave the zones > from the customer. In both cases you are following the > delegation heirarchy. Note even if you slave the zones > you still have to ensure the delegation is correct. > > Mark >

1 0

RE: sorbs.net
by Hannigan, Martin 15 Mar '05

15 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Robert Bonomi > Sent: Tuesday, March 15, 2005 2:11 PM > To: nanog(a)merit.edu > Subject: Re: sorbs.net > > > > > From owner-nanog(a)merit.edu Tue Mar 15 12:53:30 2005 > > Date: Tue, 15 Mar 2005 10:53:22 -0800 > > From: Micah McNelly <micah(a)style.net> > > Subject: Re: sorbs.net > > > > > > Actually I got a response quickly from a list member who > represent sorbs > > at some level. Do you really think opinion has a place in mail > > delivery? > > *MY* opinion on that matter doesn't count for sh*t. > > Neither does yours. > > The _only_ opinion that matters is that of the *owner* of the > destination > mail-server. As in "My server, *my* rules." ObOps: Blocking by SP ip addr + asking for user cash = operational problem for SP -M<

3 3

Re: sorbs.net
by Robert Bonomi 15 Mar '05

15 Mar '05

> From owner-nanog(a)merit.edu Tue Mar 15 14:28:29 2005 > To: Robert Bonomi <bonomi(a)mail.r-bonomi.com> > Cc: nanog(a)merit.edu > Subject: Re: sorbs.net > From: Valdis.Kletnieks(a)vt.edu > Date: Tue, 15 Mar 2005 15:28:17 -0500 > > > On Tue, 15 Mar 2005 13:42:24 CST, Robert Bonomi said: > > > As with any other 'voluntary use' blocklist, it's "clout" is only as good > > as the number of people using it. If serious questions arose as to the > > 'integrity' of the list, or the list operator, the vast majority of the > > mail-server operators using it would *stop* doing so. And any lack of > > integrity would be a moot issue, since 'practically nobody' would still > > be using it. It is _textbook_perfect_ "self regulation" at work. > > This is, of course, making the rather big assumption that the person who > decided to use said blocklist: > > a) was fully cognizant of the list's goals and policies when they chose to use it. nope. > *and* > b) is willing and able to track deviations on an ongoing basis. Yup. That _is_ an implicit part of *any* filtering/blocking job -- and many other tasks as well. That you _check_ on an ongoing basis, to make sure that the automation *is* doing what you "think" it is doing. > *and* > c) whoever replaces them is also able to do so. If they aren't competent to do the job, they shouldn't *have* the job. If management doesn't know what all the job requirements are, that is managements failing, and they _deserve_ the consequences thereof. <wry grin> > If it was in fact "textbook perfect", we'd never hear about stuff breaking > when a block list goes belly up with six month's warning, and people *still* > being surprised when suddenly everything returns 127.0.0.2 and a lot of mail > goes kaboing. Beg to differ. "textbook perfect" self-regulation means that when the list starts returning excessive numbers of false positives, that 'practically everybody' _stops_using_it_. And in fairly short order. Which is, in fact, precisely what DID happen. The list operator was relying on the effectiveness of said "self regulation" mechanism to "get the word out" to those who had _not_ heard about the shutdown from other sources.

5 4

"Bernie Ebbers Guilty"
by Paul Vixie 15 Mar '05

15 Mar '05

NEW YORK - Bernard Ebbers, the former chief executive of WorldCom and perhaps the most powerful American businessman ever to face a criminal trial, was found guilty today of securities fraud, conspiracy and filing false documents with regulators. ... http://www.forbes.com/home/management/2005/03/15/cx_da_0315ebbersguilty.html

2 1

Would You Trust "Secure Enterprise Instant Messaging" From a Spam Source?
by Jon R. Kibler 15 Mar '05

15 Mar '05

Greetings all, Would you trust a "Secure Enterprise Instant Messaging" product that advertises via spam? We just received the following email advertising "safe" IM software. It was sent to a spambait email address that was clearly harvested from a newsgroup or other Internet posting. > From: "Omnipod" <reply-1472(a)elabs3.com> > Subject: Secure Enterprise Instant Messaging > To: (spambait email address deleted) > > Consumer Instant Messaging (IM) is not safe for business users: > > March 2005: The MSN Kelvir worm and its Trojan horse counterpart are just the latest viruses aimed at exploiting the vulnerabilities of consumer IM systems. > > February 2005: The Bropia worm was discovered propagating across users of the MSN Messenger network and acting as a carrier for an additional, more dangerous > worm called Agabot. > > February 2005: The Agabot worm performed a distributed denial-of service attack, similar to the notoriously destructive Slammer, Blaster and Sasser worms. > > New prevention solutions are needed as virus writers become more creative in their goal of wreaking havoc through soft spots in Microsoft software. Omnipod's private IM > network prevents these security problems by prohibiting the transfer of executable text (and denying file transfers with consumer IM) while combining strict administrative > controls with 168-bit encryption and 3DES SSL. Simply put, Omnipod protects users from hackers as well as from the common viruses and worms that routinely infect > consumer IM networks. > > Try Omnipod risk free at http://www.omnipod.com <SNIP!> Anyone ever heard of this outfit? Is this a legitimate product, or is it some kind of Trojan? The company that owns the domain elabs3.com (uptilt.com) claims to be a CRM organization, yet they advertise an email marketing capability. Anyone know anything about this organization? If this is a legit product, you REALLY have to wonder why in the world they would advertise via SPAM! Jon Kibler -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

1 0

Delegating /24's from a /19
by Mike Sawicki 15 Mar '05

15 Mar '05

Our organization has a /19 assignment from ARIN. We have given portions of this space to several other companies within our corporate umbrella. Several of these other companies have their own nameservers, and would like to be able to manage DNS on their own for their in-addr.arpa. blocks. What would be the best way to delegate authoritiy for them? ARIN is pointing to our 2 nameservers for the entire /19. Do I need to use some sort of RFC2317 method here, or would I be able to just install zones for each /24 with NS records pointing to the other companies' servers? Also, what are some good ways to test and verify that this is all working? Any pointers would be appreciated. Thanks. -- -- Mike Sawicki (fifi(a)HAX.ORG)

5 4

Re: sorbs.net
by Robert Bonomi 15 Mar '05

15 Mar '05

> From owner-nanog(a)merit.edu Tue Mar 15 13:21:45 2005 > From: Randy Bush <randy(a)psg.com> > Date: Tue, 15 Mar 2005 11:21:35 -0800 > To: nanog(a)merit.edu > Subject: Re: sorbs.net > > > a few questions > > o could this be used as a dos and then become extortion? > has this actually happened, or is it just black heli? _Legally_, it is *not* extortion, unless the thing that is 'taken' (*with* the 'under duress' consent of the victim) goes, directly or indirectly, to the party making the 'threat'. Noting also, that the legal definition of extortion requires a the property, goods or services be given up in response to a "threat" to do something if that property, goods or services are *not* turned over to the threatener; Thus, a situation where somebody does *not* act unless something is recieved, cannot be, legally, extortion. SORBS has been running for "much longer" than a year. To the best of my knowledge, strictly within their published guidlines. As with any other 'voluntary use' blocklist, it's "clout" is only as good as the number of people using it. If serious questions arose as to the 'integrity' of the list, or the list operator, the vast majority of the mail-server operators using it would *stop* doing so. And any lack of integrity would be a moot issue, since 'practically nobody' would still be using it. It is _textbook_perfect_ "self regulation" at work. > o the ts&cs would seem to indicate that the donation is > voluntary, and proportional to the spam generated. e.g., > if you generated no spam, no donation. do i understand > this correctly? As I understand it -- and I'm -not- an expert on SORBS -- they list individual IP addresses on various lists, for various different kinds of problems. Far and away,the biggest being originating spam. Listings _do_ "age off", taking an unknown period of time after 'someone' makes a request for removal. The donation is purely voluntary, and when provided, the SORBS operator does 'expidate' handling of the removal request. For some strange reason he believe that those people are 'more serious' about ensuring that problems don't occur from their machines again. I have no opinion as to the validity of that reasoning.

2 1

Traceroute to 207.65.163.1
by Ejay Hire 15 Mar '05

15 Mar '05

Hi all. I have an outside-in reachability problem I can't nail down. If you have a second, can you email me a traceroute to 207.65.163.1? Especially if you transit AS1239. Thanks to all, Ejay Hire Ejay.hire(a)isdn.net

2 2