Re: sorbs.net
What if the USPS decided any magazine you subscribed to was suddenly unfit for delivery and decided it should blocked (thrown away)? They don't decide. I do. This is not factually true. The USPS has a Postal Inspection Service that can intercept your mail for various reasons. Details are in 39 USC 3013. The quote below comes from a report on their activities for the year ended March 31 2004. During that period there were 21 withholding mail orders issued. -quote begins--- POSTAL INSPECTION SERVICE The Postal Service reports to the Office of Inspector General information related to investigative activities designed to protect the public against unscrupulous mailers perpetrating fraudulent schemes. The following information summarizes the administrative and judicial actions initiated and resolved during the reporting period. These actions include the issuance of cease and desist orders directed to mailers, actions to intercept payments fraudulently induced, and orders seeking to intercept fraudulent mailings. --quote ends-- In operations of any sort, network or otherwise, it is important to get the facts straight to ensure that you are not acting on the basis of bogus information. --Michael Dillon
Re: Traceroute with ASN
Is there any new development happening with the NANOG traceroute project? ftp://ftp.login.com/pub/software/traceroute/ On 2005.03.15 15:03:12 %z, Bruce Pinsky wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Watson wrote: | On 3/15/05 3:11 AM, Ziggy David Lubowa [EMAIL PROTECTED] wrote: | | | |On Tue, 15 Mar 2005 17:51:32 +0800 (CST), Joe Shen wrote | |Yes. Can I do this on a Linux box without having to |install Zebra BGP on it? | |Doesnt look like you have to, below is the link to the tarball | |http://oppleman.com/dl/?file=lft-2.3.tar.gz | | | I believe the author of LFT is working on a new release that does *not* use | the oft-times incorrect radb data, but instead pulls from a router (not sure | of the source) somewhere. | Would probably be nice to have a command-line option to specify the source from either: - - an RADB formatted source - - a Zebra or Quaaga BGP daemon - - via SNMP from a BGP capable device - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCN2mvE1XcgMgrtyYRArtOAKCTq6pq6VNIHH60q+VAJCaM6d00kgCePns8 5pgjTfF1TW5ISm5OdzQM4TA= =i6cq -END PGP SIGNATURE- -- Charles Arsenault [EMAIL PROTECTED] PGP: 3649 E54D AF11 88D9 A774 9537 ED1C 5574 235E 3942 Tel: +1-514-868-7823 Unix/BSD, Security, IP Network Engineering
Re: Delegating /24's from a /19
Robert Bonomi wrote: 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. I'm not as versed in DNS protocols as I was in the past (which then didn't compare to some on this list), but won't this cause tons of lame server messages that could be eliminated by proper SWIPping? pt
Re: Traceroute with ASN
On Tue, 2005-03-15 at 15:03 -0800, Bruce Pinsky wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Watson wrote: | On 3/15/05 3:11 AM, Ziggy David Lubowa [EMAIL PROTECTED] wrote: | | | |On Tue, 15 Mar 2005 17:51:32 +0800 (CST), Joe Shen wrote | |Yes. Can I do this on a Linux box without having to |install Zebra BGP on it? | |Doesnt look like you have to, below is the link to the tarball | |http://oppleman.com/dl/?file=lft-2.3.tar.gz | | | I believe the author of LFT is working on a new release that does *not* use | the oft-times incorrect radb data, but instead pulls from a router (not sure | of the source) somewhere. | Would probably be nice to have a command-line option to specify the source from either: - - an RADB formatted source - - a Zebra or Quaaga BGP daemon - - via SNMP from a BGP capable device A 4th option would be the Routeviews DNS based mapping service at asn.routeviews.org. See -- http://www.merit.edu/mail.archives/nanog/2003-09/msg00832.html An advantage here is that you get caching for free.
Re: sorbs.net
Hannigan, Martin [EMAIL PROTECTED] wrote: 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. [EMAIL PROTECTED] is who you want to talk to, IIRC. -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / [EMAIL PROTECTED] / PGP: 0xE3AE35ED The wisdom of a fool won't set you free --New Order, Bizarre Love Triangle
Re: sorbs.net
On Wed, 16 Mar 2005 [EMAIL PROTECTED] wrote: What if the USPS decided any magazine you subscribed to was suddenly unfit for delivery and decided it should blocked (thrown away)? They don't decide. I do. This is not factually true. The USPS has a Postal Inspection Service that can intercept your mail for various reasons. Details are in 39 USC 3013. The quote below comes from a report on their activities for the year ended March 31 2004. During that period there were 21 withholding mail orders issued. OK, they decide, for extremely small values of decide. 21 withholding mail orders vs. how many trillions of items handled? -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] WestNet: Connecting you to the planet. 805 884-6323 WB6RDV NetLojix Communications, Inc. - http://www.netlojix.com/
Re: Delegating /24's from a /19
At 20:22 -0800 3/15/05, Owen DeLong wrote: I'm not sure what you mean by sideways delegations. It is perfectly acceptable, for example, for: a.root-servers.net returns 16.172.in-addr.arpa. IN NS ns1.arin.net. ns1.arin.net returns 124.16.172.in-addr.apra. IN NS ns1.foobar.com. ns1.foobar.com. returns 124.16.172.in-addr.arpa. IN NS ns1.subsidiary.com. ns1.subsidiary.com. returns 5.124.16.172.in-addr.arpa. IN PTR foo.subsidiary.com. This does work. This is what is being proposed. I'm afraid that above is not an accurate or workable sequence of events. Here is what happens *today* when a fresh copy of named seeks a reverse map. First the disclaimer - I'm using named 9.3.1, not all iterating resolvers have the same strategy. I'm omitting repeated queries, as well as queries for records and retranmissions because of FORMERR. Also, if you start the server, run the query, stop the server and repeat (with an empty cache), the next result may vary as zones held vary be server. Note too that this is from a fresh (empty) cache. Some queries are not needed when the cache is populated. It is not always as bad as I am illustrating - but it's easiest to visualize from the 0 state. 1. I ask a root-server for 162.57.173.209.in-addr.arpa./PTR. The response is a referral to the servers for 209.in-addr.arpa and I am told there are 7 of them. 2. I ask another root-server for the address of each of the 7 name servers. This means 7 new queries (14 w/'s) directed to this second root server. Note that in this example, all 7 name servers are in the .net domain. 3. I ask the .net name servers the same questions as in #2. From this I get some hybrid answers - referrals enriched with answers - for most of the 7 name servers. I call these hybrids because, if you adhere strictly to the DNS protocol specifications, referrals are what you should get. The addition of the answer records to the referrals is a crutch to help the Internet run more smoothly. (For this we should thank Verisign engineers.) 4. The query in step 1 is issued to one of the name servers with a hybrid answer at this point. The reply received in this step is a referral to the servers for 57.173.209.in-addr.arpa, served up by four machines in neustar.com. 5. BIND continues seeking the glue for the name servers w/o hybrid answers in step 3. BIND does this to have these name servers available for further querying, but is not necessary for the immediate question. (This is done in parallel too - to avoid unnecessary latency.) 6. Armed with new name servers in step 4, a query for each's address is sent to another root server, which results in referrals to the servers for .com. 7. The .com servers also give the same hybrid answers (.com and .net are on the same machines) for the 4 name servers. 8. The original query is then issued to one of the servers whose address was obtained in step 7. The result of this is what we wanted all along. 9. BIND may continue seeking addresses for other servers after returning the answer, filling out its cache. Why bother to detail all this? It's important to realize that the real iteration is done only in steps 1, 4, and 8. In step 1 I am being told who to ask. In step 4 I am also being told who to ask. The rest of the time I am trying to find out where to ask. Steps 2,3,5 get me the addresses for the question in step 4. Steps 6,7,9 get the addresses for the question in step 8. So - going back to the comment above: a.root-servers.net returns 16.172.in-addr.arpa. IN NS ns1.arin.net. The root-servers do not return NS records, the refer the querier to one of the /8 zones. (Note that not all root servers have the same zones, some might refer the querier to the in-addr.arpa. zone.) ns1.arin.net returns 124.16.172.in-addr.apra. IN NS ns1.foobar.com. ns1.foobar.com. returns 124.16.172.in-addr.arpa. IN NS ns1.subsidiary.com. If the above two situations happened, then there's a violation of the database coherency principle that DNS tries hard (split-brain aside) to uphold. In the global DNS, no matter where you ask question, you should get the same answer. I.e., 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. So, I don't think the above is workable or even realistic. 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). So don't debug them. As long as ARIN has all of the /24s within the /19 pointing as NS records to the nameserver which contains the partially populated /16 zone file (or which secondaries each of the relevant /24 zones from their true owners), things
Re: Delegating /24's from a /19
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 NSchia.ARIN.NET. 209.in-addr.arpa. 1D IN NSdill.ARIN.NET. 209.in-addr.arpa. 1D IN NSBASIL.ARIN.NET. 209.in-addr.arpa. 1D IN NShenna.ARIN.NET. 209.in-addr.arpa. 1D IN NSindigo.ARIN.NET. 209.in-addr.arpa. 1D IN NSepazote.ARIN.NET. 209.in-addr.arpa. 1D IN NSfigwort.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.
Re: Delegating /24's from a /19
2) Use DNAME, RFC 2672. Good luck. (http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.html) 3) Use RFC 2317. I encourage my competitors to operate this way. Note: DNAME is equivalent to RFC 2317. In both cases this will break the customers expectation that they can just use x.y.z.in-addr.arpa for the PTR records. Note for reliable local reverse lookups when the external link is down they will need to slave the ISP's x.y.z.in-addr.arpa zone and well as manage the zone the CNAME / DNAME maps to. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: Delegating /24's from a /19
At 16:56 -0500 3/16/05, Edward Lewis wrote: servers in the first belong to 209/8, the latter to 209.173.48/8. Whoops - the last is /24. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: Delegating /24's from a /19
I'm afraid that above is not an accurate or workable sequence of events. Not accurate in the sense that I left out some of the queries and left it as a summary of the relevant ones, however... [...bind 9.3.1...] snip Note too that this is from a fresh (empty) cache. Some queries are not needed when the cache is populated. It is not always as bad as I am illustrating - but it's easiest to visualize from the 0 state. 1. I ask a root-server for 162.57.173.209.in-addr.arpa./PTR. The response is a referral to the servers for 209.in-addr.arpa and I am told there are 7 of them. And their host names. 2. I ask another root-server for the address of each of the 7 name servers. This means 7 new queries (14 w/'s) directed to this second root server. Note that in this example, all 7 name servers are in the .net domain. Right... However, pretty quickly, your cache gets these and, unless you are patholigically stupid about restarting your nameservers often, this is almost never necessary. 3. I ask the .net name servers the same questions as in #2. From this I get some hybrid answers - referrals enriched with answers - for most of the 7 name servers. I call these hybrids because, if you adhere strictly to the DNS protocol specifications, referrals are what you should get. The addition of the answer records to the referrals is a crutch to help the Internet run more smoothly. (For this we should thank Verisign engineers.) Except that the additional info was done long before Verisign was in the picture. Not sure why you think Verisign should get credit. Anyway, again, this query is almost never necessary. 4. The query in step 1 is issued to one of the name servers with a hybrid answer at this point. The reply received in this step is a referral to the servers for 57.173.209.in-addr.arpa, served up by four machines in neustar.com. OK. 5. BIND continues seeking the glue for the name servers w/o hybrid answers in step 3. BIND does this to have these name servers available for further querying, but is not necessary for the immediate question. (This is done in parallel too - to avoid unnecessary latency.) Right, but, again, this happens once in a blue moon. 6. Armed with new name servers in step 4, a query for each's address is sent to another root server, which results in referrals to the servers for .com. Again, if you actually have to do this. 99+% of the time, you will not. 7. The .com servers also give the same hybrid answers (.com and .net are on the same machines) for the 4 name servers. And, as such, you probably already have these answers. 8. The original query is then issued to one of the servers whose address was obtained in step 7. The result of this is what we wanted all along. 9. BIND may continue seeking addresses for other servers after returning the answer, filling out its cache. Why bother to detail all this? It's important to realize that the real iteration is done only in steps 1, 4, and 8. In step 1 I am being told who to ask. In step 4 I am also being told who to ask. The rest of the time I am trying to find out where to ask. Steps 2,3,5 get me the addresses for the question in step 4. Steps 6,7,9 get the addresses for the question in step 8. Uh, right, but, steps 2,3,5 and 6,7,9 are almost always unnecessary as they get put in the cache and pretty much left there for anything at all active pretty quickly. So - going back to the comment above: a.root-servers.net returns 16.172.in-addr.arpa. IN NS ns1.arin.net. The root-servers do not return NS records, the refer the querier to one of the /8 zones. (Note that not all root servers have the same zones, some might refer the querier to the in-addr.arpa. zone.) OK... Fine... You're right, it returns more like 172.in-addr.arpa. IN NS ns1.arin.net. But I don't see this as a significant distinction, since, ARIN will still return the next line the same. They are, btw, NS records... dig @a.root-servers.net 162.57.173.209.in-addr.arpa. PTR ; DiG 9.2.3 @a.root-servers.net 162.57.173.209.in-addr.arpa. PTR ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 24751 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;162.57.173.209.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 209.in-addr.arpa. 86400 IN NS chia.ARIN.NET. 209.in-addr.arpa. 86400 IN NS dill.ARIN.NET. 209.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET. 209.in-addr.arpa. 86400 IN NS henna.ARIN.NET. 209.in-addr.arpa. 86400 IN NS indigo.ARIN.NET. 209.in-addr.arpa. 86400 IN NS epazote.ARIN.NET. 209.in-addr.arpa. 86400 IN NS figwort.ARIN.NET. ;; Query time: 102 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Mar 16 23:37:33 2005 ;; MSG SIZE rcvd: 196 ns1.arin.net returns 124.16.172.in-addr.apra. IN NS ns1.foobar.com. ns1.foobar.com. returns 124.16.172.in-addr.arpa. IN NS
