- Test - lists.nanog.org

SBC Contact
by Mike Rae 17 Mar '05

17 Mar '05

Can someone from SBC please contact me off-list ? Thanks in advance Mike Mike Rae Sprint Canada mike.rae(a)sprint-canada.com

1 0

Failures and hot-potato routing
by András Császár (IJ/ETH) 17 Mar '05

17 Mar '05

Hi! Does anyone have any statistical data how often intra-domain link failures cause that a new edge router is used? E.g., if the path between the original ingress-egress routers has a higher IGP cost after an IGP SPF calculation due to a link failure. Cheers, András http://www.tmit.bme.hu/~csaszar

1 0

Contacts for AS 577
by chip 17 Mar '05

17 Mar '05

Hello, Could someone with BGP clue from AS 577 please contact me off list regarding sourcing space that doesn't belong to you. Thanks, Chip Gwyn (chip.gwyn(a)gmail.com) -- Just my $.02, your mileage may vary, batteries not included, etc....

1 0

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

17 Mar '05

> From owner-nanog(a)merit.edu Tue Mar 15 14:12:12 2005 > Date: Tue, 15 Mar 2005 15:12:10 -0500 > From: Robert Blayzor <rblayzor(a)inoc.net> > To: alex(a)pilosoft.com > Cc: Mike Sawicki <fifi(a)HAX.ORG>, nanog(a)merit.edu > Subject: Re: Delegating /24's from a /19 > > > 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. > > > It is very easy to do DNS delegation, say if you have 128.0.0.0/19, and > > you want to delegate 128.0.1.0/24, in your zone file for > > 0.128.in-addr.arpa zone put > > > > 1 IN NS ns1.othercompany.com > > 1 IN NS ns2.othercompany.com > > The only way it will work is to use RFC2317 or slave the zones from the > other name server. Because he does not have the entire /16 you can't > just delegate like that. 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. "He who" queries from the outside world will work their way down from the .arpa zone, to the X.W.in-addr.arpa zone, get referred to the nameserver at "thiscompany", and get referred to the NS listed for Y.X.W.in-addr.arpa. which will resolve Z.Y.X.W.in-addr.arpa. "He who" queries the /19 owner nameserver directly for a Y.X.W.in-addr.arpa address that lies within the /19 owner's addresses will get answered by that nameserver, *or* be referred to the client's server. If they ask for something *outside* the /19 owner's space, the wildcard -- referring to the 'upstream' (the /16 owner) nameserver kicks in. _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?

5 10

Re: Delegating /24's from a /19
by Edward Lewis 16 Mar '05

16 Mar '05

At 13:48 -0800 3/16/05, David Raistrick wrote: >On Wed, 16 Mar 2005, Edward Lewis wrote: > > >> aside) to uphold. In the global DNS, no matter where you ask >> question, you should get the same answer. > >Really? Yes. > >> dig @ns1.arin.net 124.16.172.in-addr.arpa. IN NS >> >> and >> >> dig @ns1.foobar.com 124.16.172.in-addr.apra. IN NS >> >> had better return the same NS RRSet. > >An example modeled after the above using real servers: > >dig 48.173.209.in-addr.arpa ns @a.root-servers.net > >;; AUTHORITY SECTION: >209.in-addr.arpa. 1D IN NS chia.ARIN.NET. >209.in-addr.arpa. 1D IN NS dill.ARIN.NET. >209.in-addr.arpa. 1D IN NS BASIL.ARIN.NET. >209.in-addr.arpa. 1D IN NS henna.ARIN.NET. >209.in-addr.arpa. 1D IN NS indigo.ARIN.NET. >209.in-addr.arpa. 1D IN NS epazote.ARIN.NET. >209.in-addr.arpa. 1D IN NS figwort.ARIN.NET. > > >dig 48.173.209.in-addr.arpa ns @chia.ARIN.NET > >;; AUTHORITY SECTION: >48.173.209.in-addr.arpa. 1D IN NS oak.neustar.com. >48.173.209.in-addr.arpa. 1D IN NS pine.neustar.com. >48.173.209.in-addr.arpa. 1D IN NS willow.neustar.com. >48.173.209.in-addr.arpa. 1D IN NS cypress.neustar.com. And that is correct. Both are referring you to another zone. The set of servers in the first belong to 209/8, the latter to 209.173.48/8. What is not apparent is that neither query is resulting in an answer. Instead, the reply is a "go ask someone else" referral. It's like Joe says "ask Bob" and Bob says "ask Charlie." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.

1 1

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

16 Mar '05

> From owner-nanog(a)merit.edu Tue Mar 15 11:59:40 2005 > Date: Tue, 15 Mar 2005 09:59:21 -0800 > From: Micah McNelly <micah(a)style.net> > To: nanog(a)merit.edu > Subject: sorbs.net > > > Nanog, > > Anyone on the list involved with this project? I need to speak to > someone ASAP. No, I am not going to pay your ridiculous fine. > SORBS is a one-man operation out of Australia. I really doubt that he participates in the NORTH AMERICAN network operators group. SORBS -- like _any_ other blocklist -- is simply an expression of opinion. if you feel that "somebody" is 'wrongly' blocking mail because of a SORBS listing, your _first_ step should be to contact *that* party, and request that either (a) they stop using SORBS, or (b) that they 'whitelist' you. *THEY* are the ones that made the decision to block your mail to their system. Contact means for SORBS *is* provided on the web-site. it works reliably. Be advised, however, that a 'need' on your part does not translate to urgency on the part of anyone else. Note: *Nobody*, not even SORBS, says you 'have to' make that charitable contribution. All the 'spam' listings _do_ "age off" the SORBS system, eventually. Caveat: I have nothing to do with SORBS. I don't use it -- or *any* blocklist, for that matter -- myself (I use other means that are better suited for _my_ requirements). I don't even know the operator thereof. Everything I've said is based on published and publicly available information.

11 10

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

16 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Micah McNelly > Sent: Tuesday, March 15, 2005 12:59 PM > To: nanog(a)merit.edu > Subject: sorbs.net > > > > Nanog, > > Anyone on the list involved with this project? I need to speak to > someone ASAP. No, I am not going to pay your ridiculous fine. >From http://www.us.sorbs.net/faq/spamdb.shtml "Third and finally, if you are really not a spammer, or you are truly reformed, de-listing is relatively easy. You donate US$50 to a charity or trust approved by, and not connected with, SORBS for each spam received relating to the listing (This is known and refered to as the SORBS 'fine'). " That doesn't make a lot of sense. It's an interesting answer to the BotNet spamming problem, but not really a solution, IMHO. -M<

5 4

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 16 Mar '05

16 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 16 Mar '05

16 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