Re: .ORG DNS Problem?
Seems to be working fine now: % dig nanog.org ns +trace ; DiG 9.2.2-P3 nanog.org ns +trace ;; global options: printcmd . 298767 IN NS C.ROOT-SERVERS.NET. . 298767 IN NS D.ROOT-SERVERS.NET. . 298767 IN NS E.ROOT-SERVERS.NET. . 298767 IN NS F.ROOT-SERVERS.NET. . 298767 IN NS G.ROOT-SERVERS.NET. . 298767 IN NS H.ROOT-SERVERS.NET. . 298767 IN NS I.ROOT-SERVERS.NET. . 298767 IN NS J.ROOT-SERVERS.NET. . 298767 IN NS K.ROOT-SERVERS.NET. . 298767 IN NS L.ROOT-SERVERS.NET. . 298767 IN NS M.ROOT-SERVERS.NET. . 298767 IN NS A.ROOT-SERVERS.NET. . 298767 IN NS B.ROOT-SERVERS.NET. ;; Received 404 bytes from 64.246.100.1#53(64.246.100.1) in 4 ms org.172800 IN NS TLD1.ULTRADNS.NET. org.172800 IN NS TLD2.ULTRADNS.NET. ;; Received 109 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 9 ms NANOG.ORG. 172800 IN NS DNS2.MERIT.NET. NANOG.ORG. 172800 IN NS DNS.MERIT.NET. NANOG.ORG. 172800 IN NS DNS3.MERIT.NET. ORG.86400 IN NS TLD2.ULTRADNS.NET. ORG.86400 IN NS TLD1.ULTRADNS.NET. ;; Received 180 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 10 ms -Adam Quoting Adam Kujawski [EMAIL PROTECTED]: Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow respones, or no responses. Traceroutes look fine: % tcptraceroute 204.74.112.1 53 Selected device fxp0, address 64.246.100.1, port 55786 for outgoing packets Tracing the path to 204.74.112.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 9.403 ms 7.361 ms 9.148 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.801 ms 8.061 ms 9.917 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.748 ms 8.341 ms 9.612 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 10.001 ms 9.172 ms 8.762 ms 5 ge-4-3-0.r00.chcgil06.us.bb.verio.net (206.223.119.12) 9.646 ms 8.960 ms 9.502 ms 6 ge-0-3-0.r02.chcgil06.us.bb.verio.net (129.250.2.121) 9.323 ms 9.071 ms 9.039 ms 7 ge-1-1.a00.chcgil07.us.ra.verio.net (129.250.25.136) 9.848 ms 9.306 ms 9.003 ms 8 fa-2-1.a00.chcgil07.us.ce.verio.net (128.242.186.134) 9.679 ms 9.697 ms 9.684 ms 9 tld1.ultradns.net (204.74.112.1) [open] 10.296 ms 10.625 ms 9.537 ms -AND - % tcptraceroute 204.74.113.1 53 Selected device fxp0, address 64.246.100.1, port 55792 for outgoing packets Tracing the path to 204.74.113.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 5.402 ms 7.282 ms 9.738 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.973 ms 7.958 ms 9.909 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.800 ms 10.295 ms 8.835 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 8.878 ms 8.786 ms 9.187 ms 5 fe9-2.IR1.Chicago2-IL.us.xo.net (206.111.2.149) 9.512 ms 8.964 ms 8.869 ms 6 p5-0-0.RAR2.Chicago-IL.us.xo.net (65.106.6.137) 9.580 ms 9.214 ms 9.120 ms 7 p4-1-0.MAR2.Chicago-IL.us.xo.net (65.106.6.154) 9.512 ms 10.285 ms 9.594 ms 8 p15-0.CHR1.Chicago-IL.us.xo.net (207.88.84.14) 10.126 ms 9.517 ms 9.472 ms 9 10.11.102.1 (10.11.102.1) 10.990 ms 9.808 ms 10.182 ms 10 tld2.ultradns.net (204.74.113.1) [open] 9.933 ms 10.124 ms 9.778 ms Source IP for the traceroutes is 64.246.100.1. Dig's don't get very far: % dig nanog.org +trace ; DiG 9.2.2-P3 nanog.org +trace ;; global options: printcmd . 300086 IN NS C.ROOT-SERVERS.NET. . 300086 IN NS D.ROOT-SERVERS.NET. . 300086 IN NS E.ROOT-SERVERS.NET. . 300086 IN NS F.ROOT-SERVERS.NET. . 300086 IN NS G.ROOT-SERVERS.NET. . 300086 IN NS H.ROOT-SERVERS.NET. . 300086 IN NS I.ROOT-SERVERS.NET. . 300086 IN NS J.ROOT-SERVERS.NET. . 300086 IN NS K.ROOT-SERVERS.NET. . 300086 IN NS L.ROOT-SERVERS.NET. . 300086 IN NS M.ROOT-SERVERS.NET. . 300086 IN NS A.ROOT-SERVERS.NET. . 300086 IN NS B.ROOT-SERVERS.NET. ;; Received 388 bytes from 64.246.100.1#53
Re: dealing with w32/bagle
Quoting Dan Hollis [EMAIL PROTECTED]: I am curious how network operators are dealing with the latest w32/bagle variants which seem particularly evil. We are currenly blocking *all* .zip attachments as a short-term work around, until we can modify our virus scanner to block only password-protected zip files. If anybody has already modified amavisd-new to act in this way, I would appreciate a hand. I'm *not* a perl person, and my first attempt at changing the source code has not had the desired effect. Also, does anyone have tools for regexp and purging these mails from unix mailbox (not maildir) mailspool files? Eg purging these mails after the fact if they were delivered to user's mailboxes before your virus scanner got a database update. It seems that this virus uses a limited number of subject lines: # E-mail account disabling warning. # E-mail account security warning. # Email account utilization warning. # Important notify about your e-mail account. # Notify about using the e-mail account. # Notify about your e-mail account utilization. # Warning about your e-mail account. There's a script, expire_mail.pl, that's userful for this. It's available at http://www.binarycode.org/cpan/scripts/mailstuff/expire_mail.pl. It can be used as such: /usr/local/bin/expire_mail.pl -verbose -noreset -subject [subject of message containing virus] /var/mail/* Of course, this won't work if/when the virus starts sending out emails with randomized subjects. Let's hope the that the author isn't reading NANOG. :) -Adam
Re: AOL rejecting mail from IP's w/o reverse DNS ?
Quoting Adam McKenna [EMAIL PROTECTED]: On Thu, Dec 04, 2003 at 04:59:59PM -0800, Crist Clark wrote: $ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 $ NS a.ns.$ $GENERATE 0-15 a.ns.$ A 204.50.168.2 Is any harder than, $ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 CNAME $.0/28 0/28 NS ns.mydomain.org. That's the whole point. They are equivalent, but the former doesn't force you to invent your own naming scheme or use CNAMES (if using A records in in-addr.arpa domains is distasteful, then imho using CNAMES is even more distasteful, not to mention RR's containing the / character). --Adam Why bother with CNAMES or A records? Is there anything wrong with simply using NS records for each adress? i.e.: $ORIGIN 109.246.64.in-addr.arpa. 1NS ns1.customerA.com. 1NS ns2.customerA.com. 2NS ns1.customerA.com. 2NS ns2.customerA.com. ... 16 NS ns1.customerB.com. 16 NS ns2.customerB.com. 17 NS ns1.customerB.com. 17 NS ns2.customerB.com. If the customer has a dozen name servers they want you to allocate reverse DNS for, it could become unwieldy, but technically, is there anything wrong with this setup? -Adam
Re: Removal of wildcard A records from .com and .net zones
Quoting Matt Larson [EMAIL PROTECTED]: VeriSign was directed by ICANN to suspend the Site Finder service by 0100 UTC on Sunday, October 5. We requested an extension from ICANN to give more notice to the community but were denied. Since when does Verisign argue that the community should be given advanced notice of drastic changes to the .com/.net zones? Would anybody from Verisign like to explain how extended notice of the wildcard removal would benefit the Internet community? I'm all ears. -Adam
RE: Fun new policy at AOL
Quoting Vivien M. [EMAIL PROTECTED]: You seem to be misunderstanding the issue. Let's say you work at someplace.edu. You want to send mail from home. With the SPF-type schemes being discussed, your mail MUST come from someplace.edu's server. If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your dialup account will let you use the dialup ISP's mail server... But your mail will get bounced because it's not something from someplace.edu. Hence, if no SMTP AUTH relay, you're screwed. If someplace.edu understands the the basic idea being discussed, one might assume that they wouldn't implement Jim Miller's idea until they've implemented SMTP AUTH (or POP before SMTP) as well. If they don't know about / know how to implement SMTP AUTH, they probably wouldn't bother to make the proper DNS changes to make this idea work. One might also assume that if the MTA used by someplace.edu implements Jim Miller's idea, said MTA is also is modern enough to have support for SMTP AUTH. You may find those to be doubious assumptions, but I don't think they're that unreasonable. The only weakness I see is that spammers could find a domain that doesn't implement Jim Miller's idea and forge mail in their name instead. So what if hotmail.com implements the system? There are 100 million other domain names the spammers could pick from. It's not a solution. It will slow the spammers down. It will inconvenience them. It won't stop them. That doesn't mean it shouldn't be done... just that it's not a panacea, and might not even be that effective. (I wonder if I would get less SPAM if every SMTP server were still an open relay.) By the way, a strengh of this idea that I haven't seen discussed here is that such a system would cut down on the spread (and worthless bounce reports) of current viruses that forge the From: header. -Adam
Backbone Infrastructure and Secrecy
NANOG's Sean Gorman is in the news: http://www.washingtonpost.com/wp-dyn/articles/A23689-2003Jul7.html I would find GIS like the one described *very* usefull in finding transport providers. If I could see who has what where, I would know who to go to for quotes. As it stands, most of this information is hard to get ahold of. Who, besides Sean, has maps like this? The state PUC? If so, is that information available to the public? Do you have to go thorugh a background check and/or sign an NDA? Or is it only the providers themselves that have the maps for this stuff? -Adam
Re: [Backbone Infrastructure and Secrecy]
Quoting Joel Jaeggli [EMAIL PROTECTED]: The part that's striking to me, is that as usual, the folks in the industry don't know when their facilities are co-mingled, in part becuase that information simply isn't readily and easily available unless someone's willing to go out collect the small little bits and connect the dots... If that compartimentalization continues, then continginency planning just remains that much harder when no-one is in a position to make informed decisions. Exactly. I think we all agree that this kind of information would be usefull for a variety of reasons (locating available resources, ensuring path redundancy, identifying critical points of failure, etc). I think we all agree that this information, in the wrong hands, can also be used for naughty purposes. How do we balance these opposing factors? I like the idea of a clearinghouse where one can access the data after a background check and a NDA. At the state level, the logical place would be the PUC. They have all the data, but do they have it all in a single GIS database? They should, but I doubt they do. At the national level, is there any department or agency to go to? It certainly doesn't sound like it. What would it take to get a project such as Mr. Gorman's done by the federal government so that there would be a single place to go? Does the government already have this information locked up behind closed doors? It seems like they would. Is there any reason not to make it available to interested parties that have a valid reason to access it? Would the infrastructure owners oppose such a system being publically available? After all, they don't want their competitors to copy their good design or take advantage of underserved markets revealed by the maps. But it seems they would have much to gain as well - potential customers will know who to go to for service. It sounds like the current trend is toward supressing this kind of information. But as an industry, it is in our best interest to compile this information and make it available to the proper parties. -Adam
Re: 923 Mbps across the Ocean ...
Quoting Eric Germann [EMAIL PROTECTED]: http://www.cnn.com/2003/TECH/internet/03/07/speed.record/index.html Comments folks? I'm going to launch a couple DAT tapes across the parking lot with a spud gun and see if I can achieve 923 Mb/s! It would have been nice if the reporter bothered to mention that Internet speed records are measured in terabit meters per second. An article about Internet speed records that doesn't include the actual record, or even a definition of the term Internet speed record, is hardly deserving of placement on the front of cnn.com. Slow news day? -Adam
FNSI (AS6259) - Cogent
Fiber Network Solutions and Cogent Communications are pleased to announce that Cogent Communications has agreed to acquire the major assets of FNSI, including all FNSI customers. After careful and thorough consideration, FNSI selected Cogent, a premier Tier One Internet Service Provider, as the successor to FNSIs operations. -Kuj
