Re: Memory leak cause of Comcast DNS problems
Steve (and all),
>At least in my neighborhood, Comcast appears to be running BIND 9.2.4rc6
Ah... Then there are to possible paths...
1) There was a real memory-leak bug and this was an unfortunate operations
event. The CHANGES file for 9.3.1 and bind-9.2.5rc1 show various big fixes
related to memory leak issues. I leave it to someone else to comment on the
potential of being tickled within a Comcast environment.
-or- (And on a much more cynical note.)
2) Someone checked the latest CHANGES file for bind and realized that saying it
was a memory leak was a good cover (see quick pseudo-grep of file below. Note
that not all the bug's affect the running bind name server code).
Whichever it was, I wonder how it could affect so many name servers at only one
provider and all at the same time. This is just plain strange. I would have
thought that best practices for a DNS service would recommend staggered
upgrades, heck, even forced different s/w releases. etc. etc.
Martin
---
awk '
/^ --- 9\.2\.[0123][^ ]* released ---/ { print; exit; }
/^ --- [^ ]* released ---/ { print; next; }
/^[ ]*$/ { if (memory) { print all; } all = ""; memory = 0; next; }
/[mM]emory/ { memory = 1; }
{ all = all "\n" $0; next }
' < bind-9.3.1/CHANGES
---
--- 9.3.1 released ---
--- 9.3.1rc1 released ---
--- 9.3.1beta2 released ---
--- 9.3.1beta1 released ---
--- 9.3.0 released ---
--- 9.3.0rc4 released ---
--- 9.3.0rc3 released ---
--- 9.3.0rc2 released ---
1683. [bug] dig +sigchase could leak memory. [RT #11445]
--- 9.3.0rc1 released ---
1643. [bug] dns_db_closeversion() could leak memory / node
references. [RT #11163]
--- 9.3.0beta4 released ---
1635. [bug] Memory leak on error in query_addds().
--- 9.3.0beta3 released ---
1599. [bug] Fix memory leak on error path when checking named.conf.
--- 9.3.0beta2 released ---
--- 9.3.0beta1 released ---
1562. [bug] isc_socket_create() and isc_socket_accept() could
leak memory under error conditions. [RT #10230]
1561. [bug] It was possible to release the same name twice if
named ran out of memory. [RT #10197]
1547. [bug] Named wasted memory recording duplicate lame zone
entries. [RT #9341]
1545. [bug] It was possible to leak memory if named was unable to
bind to the specified transfer source and TSIG was
being used. [RT #10120]
1364. [func] Log file name when unable to open memory statistics
and dump database files. [RT# 3437]
1235. [func] Report 'out of memory' errors from openssl.
1143. [bug] When a trusted-keys statement was present and named
was built without crypto support, it would leak memory.
982. [func] If "memstatistics-file" is set in options the memory
statistics will be written to it.
--- 9.2.3rc1 released ---
RE: Okay, I'm just going to _assume_...
One word of advice... Don't skip the intro. "I'm a hacker and I steal data from the Internet". I love the parachutes (it somewhat reminds me of a Woody Allen movie, but that's another story). I want a QoS rocket Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Wallingford Sent: Thursday, October 21, 2004 9:53 PM To: Bill Woodcock Cc: [EMAIL PROTECTED] Subject: Re: Okay, I'm just going to _assume_... It's official - pigs are aloft, the forecast for Hell is freezing rain, the Sox have nearly broken the Curse (and will... :), and Cisco has taken over Looney Tunes. The end is near. No, no operational content... Did John Chambers have an aneurysm recently? On Thu, 21 Oct 2004, Bill Woodcock wrote: : :...that there's some operational content somewhere in here: : :http://www.cisco.com/edu/peterpacket/ : :...though I'm on kind of a slow link, so I'm still looking. My eternal :thanks to Suresh for finding this. My day is complete. : :-Bill
RE: Senator Diane Feinstein Wants to know about the Benefits of P2P
Sean, >There were lots of FTP mirrors around. >Every Sun workstation could have a Anonymous FTP. Of course, the problem >was every Sun workstation could be an Anonymous FTP :-) ... but you forgot to mention that filtering and firewalls and NAT were not in common use, hence everywhere was accessible from everywhere. P2P was all there was. Martin
Re: Spam handling
Joe, > Nice, why bother advertising such a removal via email? Because everyone is really meant to also own a Hotmail, AOL, Yahoo, gmail, or some such "reputable" email service that you use for instances like this. OR... set your outbound SMTP server to your upstream's so that at least this message goes out correctly. In your case (for 24.61.68.177) you would use Comcast's SMTP name, whatever that is. Martin --- At 08:31 PM 4/28/2004, joe wrote: >Ok so I send an email to a friend at SBC. Here's the result. > >The original message was received at Wed, 28 Apr 2004 23:23:51 -0400 >from pc2.rocknyou.com [192.168.1.28] > > - The following addresses had permanent fatal errors - ><[EMAIL PROTECTED]> >(reason: 553 5.3.0 DNSBL:To request removal of,[xx.xx.xxx.111],send an >E-mail to [EMAIL PROTECTED]) > > - Transcript of session follows - >... while talking to mx1-klmzmi.klmzmi.ameritech.net.: MAIL From:<[EMAIL PROTECTED]> ><<< 553 5.3.0 DNSBL:To request removal of,[xxx.xxx.xx.177],send an E-mail to >[EMAIL PROTECTED] >501 5.6.0 Data format error > >Ok, I send an email to to [EMAIL PROTECTED] >result: > >The original message was received at Wed, 28 Apr 2004 23:24:09 -0400 >from pc2.rocknyou.com [192.168.1.28] > > - The following addresses had permanent fatal errors - ><[EMAIL PROTECTED]> >(reason: 550 5.0.0 Access denied) > > - Transcript of session follows - >... while talking to mx.dia.sbcglobal.net.: MAIL From:<[EMAIL PROTECTED]> ><<< 550 5.0.0 Access denied >554 5.0.0 Service unavailable > >Nice, why bother advertising such a removal via email? > >Cheers >-Joe
Re: New cisco exploit published in the media today
> "Death of Internet Predicted. MPEGs at 11 (10:30 in Newfoundland)". I think it's 11:30 (Newfoundland does have DST). I'm not a Canadian (and I don't play one on the Internet), so don't quote me. Martin
Re: Upcoming change to SOA values in .com and .net zones
>There should be no end-user impact resulting from these changes ... I believe there have been 26 (opps, now 27) responses to this announcement in the last 2 hours 45 minutes, that's about one response every 6 minutes. Hence there seems to be at least some impact on the community and that's before these changes are even implemented. :-) Martin
Re: South America NOG ?
Bill, >> Is anyone aware of a South America NOG? or do they mainly use nanog? > >There was an operator's meeting in Argentina recently, unfortunately >scheduled at exactly the same time as the APNIC meeting. Primarily talk >about IXes, was my impression. I don't know how many attendees. Close to two hundred. You missed a good meeting! http://www.napla2003.com.ar/programa.html The presentations are all archived on that site. Martin
Re: Internet privacy
Owen, >I know it's short notice, but, can we try and get someone from >ICANN to explain at Chicago why they haven't pulled Verisign's contracts >for malfeasance? Further, can we get someone from Verisign to explain >how Verisign plans to correct these actions and stop taking unilateral >destructive actions with the public trust? > >This has real operational impact, and, it certainly needs more >coordination that Verisign has so far been willing to apply. I'm happy to see Verisign's actions on the Chicago NANOG agenda... http://www.nanog.org/mtg-0310/dns.html But (alas) I don't see any ICANN names on the list... http://www.nanog.org/mtg-0310/attendee.list.html Keep in mind that NANOG is a "North America..." entity and what your addressing here is a global issue. :-) Martin
RE: SNMP OID's for BGP monitoring
Jay, The basic BGP mibs are found in this file... ftp://ftpeng.cisco.com/pub/mibs/v2/BGP4-MIB.my From that you can deduce the OID's for polling the routers (even 12.3 train) and collect BGP info. Alas you can't find out the one value that Jared pointed out... the number of routes heard from a peer. :-( If you add the file above to your mib's directory then you can do a... snmpwalk -v 1 $ROUTER_IP $ROUTE_COMMUNITY bgp.bgpPeerTable.bgpPeerEntry ...but you will only get the following entries in your response... bgpPeerIdentifier.A.B.C.D bgpPeerState.A.B.C.D bgpPeerAdminStatus.A.B.C.D bgpPeerNegotiatedVersion.A.B.C.D bgpPeerLocalAddr.A.B.C.D bgpPeerLocalPort.A.B.C.D bgpPeerRemoteAddr.A.B.C.D bgpPeerRemotePort.A.B.C.D bgpPeerRemoteAs.A.B.C.D bgpPeerInUpdates.A.B.C.D bgpPeerOutUpdates.A.B.C.D bgpPeerInTotalMessages.A.B.C.D bgpPeerOutTotalMessages.A.B.C.D bgpPeerLastError.A.B.C.D bgpPeerFsmEstablishedTransitions.A.B.C.D bgpPeerFsmEstablishedTime.A.B.C.D bgpPeerConnectRetryInterval.A.B.C.D bgpPeerHoldTime.A.B.C.D bgpPeerKeepAlive.A.B.C.D bgpPeerHoldTimeConfigured.A.B.C.D bgpPeerKeepAliveConfigured.A.B.C.D bgpPeerMinASOriginationInterval.A.B.C.D bgpPeerMinRouteAdvertisementInterval.A.B.C.D bgpPeerInUpdateElapsedTime.A.B.C.D ...where A.B.C.D is the IP address of the peer. You maybe better off doing a poll of the router via a command line and plotting the values after scraping the text somewhat! Martin --- At 12:34 PM 9/5/2003 -0500, Austad, Jay wrote: >Doh, unfortunately, I'm on the 12.3 train, and that OID does not exist. I >could have sworn that I saw some MRTG graphs awhile back where people were >monitoring how many prefixes they had and other sorts of things. Were they >scripting this somehow or pulling via SNMP? > >> -Original Message- >> From: Jared Mauch [mailto:[EMAIL PROTECTED] >> Sent: Friday, September 05, 2003 10:27 AM >> To: Austad, Jay >> Cc: [EMAIL PROTECTED] >> Subject: Re: SNMP OID's for BGP monitoring >> >> >> If you are running 12.0(26)S you can now graph the number >> of routes you receive from a BGP peer. >> >> Here's the OID for those that have long-awaited such a >> feature. >> >> .1.3.6.1.4.1.9.9.187.1.2.4.1.1 >> >> Now why this is missing from their "newer" 12.2 and >> 12.3 software >> is something that you will need to ask your cisco rep. >> >> - Jared >> >> On Fri, Sep 05, 2003 at 10:23:29AM -0500, Austad, Jay wrote: >> > >> > What OID's are people using to monitor/graph BGP stats on >> Cisco routers? >> > >> > -jay >> >> -- >> Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] >> clue++; | http://puck.nether.net/~jared/ My statements >> are only mine. >>
Re: Sea sponge builds a better glass fiber
Stephen, >or the naturally occuring coral that can switch multiple oc-192 at line rate and >give you accurate counter results ? That would actually be STM-64's, as nearly all marine cables are SDH and not SONET. (I'm assuming you have to keep the coral or sponge wet). Martin
Re: Full Internet ASN <--> AS Name resolution
Mourad, Don't forget LACNIC... ftp://ftp.lacnic.net/pub/stats/lacnic/ ftp://ftp.lacnic.net/pub/stats/lacnic/lacnic.20030601 Martin --- At 04:00 PM 6/6/2003 +0200, Mourad BERKANE wrote: > >Hi NANOGers, > >Could someone forward me a .txt file including FULL INTERNET (ARIN + RIPE + APNIC) >ASN <--> AS Name resolution table? > >I don't want to compile following regional dbase :-) > >ftp://ftp.arin.net/netinfo/asn.txt >ftp://ftp.apnic.net/pub/apnic/dbase/data/rpsl >ftp://ftp.ripe.net/ripe/dbase/ > >Thanks in advance >Mourad >
Re: IANA reserved Address Space
Brennan, If you want your routes to be human parse'able, I recommend running your lab in full IPv6 mode. That way you take Valdis's recommendation to a whole new level (and base number system). Plus... Whats the point of having a lab that only uses 1982/1983 addressing techniques (1/8, 10/8, 100/8 are classfull addresses). Labs are meant to push the limits of todays technology and experiment with future concepts. IPv6 matches that criteria. Martin --- At 10:07 AM 5/30/2003 -0400, [EMAIL PROTECTED] wrote: >On Fri, 30 May 2003 05:49:28 PDT, [EMAIL PROTECTED] said: > >> one of the things I want to do is make it much >> easier to "parse visually" my route tables. > >Might want to use networks 4/8, 16/8, and 64/8 - they stand out >nicely when looking at net numbers in hex or binary. ;) >
Re: OT: need SBCIS (7132) contact with DNS clue
Eddy, If you have an xDSL line with static IP's on a /27, then PBI/SBC will setup the DNS as follows. In this example W is the base IP of the network (ie: 0,8,16,24,32,40,48, etc.) and (W+n) should just be a number and not have parentheses or a plus! PCI/SBC will add the following to their zone files... W.X.Y.Z.in-addr.arpa. IN NS W.X.Y.Z.in-addr.arpa. IN NS W.X.Y.Z.in-addr.arpa. IN NS In my case they did NOT list PBI/SBC as a "NS" for that specific zone, hence it always comes over to my boxes. Then PBI/SBC will add this in their zone files... (W+0).X.Y.Z.in-addr.arpa. IN CNAME (W+0).W.X.Y.Z.in-addr.arpa. (W+1).X.Y.Z.in-addr.arpa. IN CNAME (W+1).W.X.Y.Z.in-addr.arpa. (W+2).X.Y.Z.in-addr.arpa. IN CNAME (W+2).W.X.Y.Z.in-addr.arpa. (W+3).X.Y.Z.in-addr.arpa. IN CNAME (W+3).W.X.Y.Z.in-addr.arpa. (W+4).X.Y.Z.in-addr.arpa. IN CNAME (W+4).W.X.Y.Z.in-addr.arpa. (W+5).X.Y.Z.in-addr.arpa. IN CNAME (W+5).W.X.Y.Z.in-addr.arpa. (W+6).X.Y.Z.in-addr.arpa. IN CNAME (W+6).W.X.Y.Z.in-addr.arpa. PBI/SBC did not do the W+7 entry for me but they did do the W+0 entry. :-) That all said, you just need to add one zone "W.X.Y.Z.in-addr.arpa" on your side. Why is this confusing? Because if you got the same email as I did... they didn't even come close to explaining it this way and hence why your worried about the recurse on the NS's. Contact email address I have in my files for PBI/SBC DNS are... "HARPER, LACONTRIA (SBIS)" <[EMAIL PROTECTED]> DESC Central <[EMAIL PROTECTED]> Note that I don't work for SBC, I just use an xDSL line at home. Martin -- At 10:44 PM 3/21/2003 +, E.B. Dreger wrote: >Greetings all, > > >Anyone have an SBCIS (AS7132) contact with DNS clue? I'm being >told it's "company policy" that they list their nameservers as >authoritative for reverse DNS on space assigned from their >netblocks. IOW, they "delegate" by creating NS RRs that point to >the correct NSes _and_ NS RRs pointing to their own. > >It gets better. Like all good "authoritative" NSes, their NSes >disallow recursive processing. Is it truly company policy to >screw up reverse DNS for downstreams who run their own? > >Wanted: AS7132 contact who understands the concept of lame >servers, why they are bad, and is willing and able to help do >something about it. > > >Eddy >-- >Brotsman & Dreger, Inc. - EverQuick Internet Division >Bandwidth, consulting, e-commerce, hosting, and network building >Phone: +1 (785) 865-5885 Lawrence and [inter]national >Phone: +1 (316) 794-8922 Wichita > >~ >Date: Mon, 21 May 2001 11:23:58 + (GMT) >From: A Trap <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Please ignore this portion of my mail signature. > >These last few lines are a trap for address-harvesting spambots. >Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to >be blocked.
Re: scripts to map IP to AS?
Dave (and anyone that downloads lookup_as.c),
Grab a newer version of traceroute.c -- There is a CLASSFULL piece of code within the
2.9.3 code-base used in lookup_as.c. The newer traceroute.c code removes the 192/8 &
128/8 testing. This is a cut-n-paste from the newer
traceroute-nanog-6.3.0/traceroute.c. It can be cut-n-pasted into your code...
>/*
> * Lookup origin of the net in radb.
> */
>
>char *lookup_as(in)
>struct in_addr in;
>{
> static char query[100];
> static unsigned char *addr_ptr;
> static char *sp;
> char *get_origin();
>
> addr_ptr = (unsigned char *) (&in.s_addr);
>
>#ifdef FORCE_NATURAL_MASK
> if (addr_ptr[0] >= 192) {
>sprintf (query, "%d.%d.%d.0",addr_ptr[0],addr_ptr[1],addr_ptr[2]);
> } else if (addr_ptr[0] >= 128) {
>sprintf (query, "%d.%d.0.0",addr_ptr[0],addr_ptr[1]);
> } else {
>sprintf (query, "%d.0.0.0",addr_ptr[0]);
> }
>#else
> sprintf (query,"%d.%d.%d.%d",addr_ptr[0],addr_ptr[1],addr_ptr[2],addr_ptr[3]);
>#endif /* FORCE_NATURAL_MASK */
>
> sp = get_origin(query);
>/* printf("as_lookup: get_origin returned %d\n",sp); */
> if (0==sp) {
> return((char *)&nullstring);
> } else {
> return(sp);
> }
>
>}
Or you could use the following shell script...
#!/bin/sh
exec whois "$[EMAIL PROTECTED]"
...which is somewhat quicker and does what lookup_as.c does.
Martin
-
At 10:07 AM 2/20/2003 -0500, David G. Andersen wrote:
>On Thu, Feb 20, 2003 at 08:09:31AM -0500, William Allen Simpson quacked:
>>
>> Anybody have a pointer to scripts to map IP to AS?
>>
>> There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets,
>> and I'd like to start blocking routing to those irresponsible AS's
>> that haven't blocked their miscreant customers.
>>
>> http://isc.sans.org/port_details.html?port=1434
>
> You can use a quick perl wrapper around whois, or you
>could use this terribly ugly hacked up traceroute-ng that I
>wrote to do lookups:
>
> http://nms.lcs.mit.edu/software/ron/lookup_as.c
>
>Compile with
>
> gcc -DSTANDALONE=1 lookup_as.c -o lookup_as -lm
>
>And then run. It gets the job done, but it's ugly. :)
>
> -Dave
>
>--
>work: [EMAIL PROTECTED] me: [EMAIL PROTECTED]
> MIT Laboratory for Computer Science http://www.angio.net/
> I do not accept unsolicited commercial email. Do not spam me.
Earthquake Mag: 7.6 - 2003/01/21 20:07 - Epicenter: Costa Colima Mexico
Found at... http://www.ssn.unam.mx/ ...which is now somewhat overrun! Nothing yet at... http://neic.usgs.gov/neis/current/m_america.html Martin
Amid telecom ruins, a fortune is buried - The Oregonian - Portland, Oregon
Not operational, but relevant... This is from today's Oregonian (Portland, Oregon newspaper). The article had good graphs and maps, but they are not online. http://www.oregonlive.com/news/oregonian/index.ssf?/xml/story.ssf/html_standard.xsl?/base/business/1039179342248063.xml There are some interesting guesses on the amount of money spent on fiber and-the-like in Oregon and some quotes from the like of Reed Hundt and Jere Retzer, etc. Martin
Re: Operational Issues with 69.0.0.0/8...
Todd,
If this helps. Do something like the following...
telnet route-views.oregon-ix.net > /tmp/file
term len 0
sh ip bgp 69.0.0.0 255.0.0.0 l
quit
cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c | more
...your commands will vary.
You will see plenty of routes within 69/8.
A closer look with show that around 121 routes are seen in the 69/8 range via most of
the feeds into Oregon. There is one big exception...
69.4.64.0/20
... it shows up via AS-2548 (Digex) and the other feeds, but it's the only route
within 69/8 that shows up via AS-2548. This is valuable information.
It does not mean there is filtering within AS-2548, but I would recommend you contact
them to further this investigation.
BTW: This is exactly what Oregon is great for! It shows up issues like this with
ease. Thanks!
Martin
---
At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote:
>Thanks for the reply, James.
>
>I wish I could tell you the answer. We see traffic passing through some
>of the routers (transit), but on each network, or their downstreams
>there seem to be different devices filtering. Sometimes it is a border
>or peering router. In other cases, it has been access devices, such as
>firewalls.
>
>One we resolved this morning (with some help from the good folks at
>ARIN) was a downstream provider from one of these transit providers that
>was filtering in their devices as well.
>
>I am just trying to raise general awareness that the 69.0.0.0/8 block is
>assigned and out there in use, and to get people to re-examine their
>filters, access lists, etc.
>
>You help and response is appreciated.
>
>Sincerely,
>
>Todd A. Blank
>614.207.5853
>
>-Original Message-
>From: Feger, James [mailto:[EMAIL PROTECTED]]
>Sent: Monday, December 02, 2002 1:35 PM
>To: Todd A. Blank
>Subject: Re: Operational Issues with 69.0.0.0/8...
>
>When you say 'Networks involved' do you mean those providers are
>blocking
>the traffic, or you see these networks in the transit?
>
>Thanks,
>James
>
>
>On Mon, 2 Dec 2002, Todd A. Blank wrote:
>
>>
>> To all concerned:
>>
>> We have been assigned a CIDR of 69.1.192.0/19.
>>
>> We have had numerous problems getting traffic through to various
>destinations.
>>
>> We are finding that many routers are still filtering 69.0.0.0/8.
>>
>> This block used to be restricted, but was assigned by IANA to ARIN in
>August of 2002.
>>
>> If anyone is still filtering this block in their routers, please
>remove the filters!
>>
>> Here are some of the destinations that are not reachable if your
>source is anywhere in the 69.0.0.0/8 CIDR:
>>
>> www.cplink2.com
>> www.ocas.com
>> www.indofilms.com
>> www.lavalife.com
>>
>>
>> Some of the Networks involved are Cable and Wireless, Allegiance
>Internet and AT&T.
>>
>> Thank you,
>>
>> Todd A. Blank
>> IPOutlet LLC
>> 614.207.5853
>>
Re: Fwd: Next NANOG meeting/stats
While we are at it... Those that still believe in using Sneaker-Net will be attending the following convention... Western Shoe Association (WSA) Las Vegas 8-11 Feb 2003 ...I don't think we have people that are members of both WSA & NANOG. Also, I know that we have had NANOG's that overlap the World Series (Baseball) and the Superbowl (American Football), but for cricket lovers... Cricket World Cup 2003 begins on 9 Feb Johannesburg South Africa. ...so that excludes most of the network operators within the British Empire from attending. While talking about sports, if you leave NANOG on the Tuesday and fly that night to Auckland, NZ you will have just enough time to sleep off the jet-lag and witness... The America's Cup series begins in Auckland February 15, 2003 (Saturday). ... keep in mind you would loose a day flying over the International Date line. (you would loose Feb 12'th so you would still have Valentines day available). Finally... Forum of Incident Response and Security Teams (FIRST) 10 and 11-Feb-2003 FIRST Technical Colloquium Location: Europe, to be decided ...which means that there will be no-one available from the US Government to talk about "how to secure the Internet". That reason alone should warrant a change of date! :-) Martin --- At 05:32 PM 11/15/2002 -0500, Randy Bush wrote: >>> The next NANOG meeting will be held February 9-11, 2003, in >>> Arizona, where it will be warm and sunny. >> Is this date absolutely set in stone? First Halloween, now Valentine's >> Day. > >and it butts right against nordnog, essentially preventing attendance >at both. > >randy
Re: 601 West 26th Street
Hello Shane, Yes. There are many companies. Here is one that you may know... Martha Stewart Living Omnimedia LLC. 601 West, 26th Street, 9th Floor New York, NY 10001 US http://www.marthastewart.com/ ...I belive she posts her home decorating hints to that web site every day. I can not belive that there is a legitimate reason to talk about Martha Stewart on the NANOG mailing list. Martin -- At 03:23 PM 10/23/2002 -0400, Owens, Shane (EPIK.ORL) wrote: >Does anyone do any IP business out of this address?? > >Shane Owens >Sr. Manager IP Engineering and Operations >EPIK Communications >3501 Quadrangle Blvd Ste 225 >Orlando FL 32817 >Phone:(407)472-8291 >Cell:(321)436-3232 >fax:(407)472-8216 >[EMAIL PROTECTED]
Re: Testing root server down code
Steve, You said... >Microsoft DNS has a poor response and can spin out of control with all root >servers available.. how would you tell the difference ;) This just in... The RPSEC mailing list has the recommendation to the Government (US that is) on both BGP and DNS. >ISP BGP & DNS Working Group >Working Paper developed as part of the NSTAC Process - Not for Further Dissemination (If your not meant to disseminate it, then why did it end up on the RPSEC mailing list?) Here is what it says about DNS... >Recommendations for DNS > >1. Encourage physical diversity (both network and geographic) for top-level domain >servers. > >2. Encourage greater software diversity for DNS sever systems. Currently most DNS >servers are based on the BIND Berkeley Internet Name Domain code base. There is also >a Microsoft Windows version of DNS that very few groups currently run. >3. ... Hence... At least in the US (and I can't say for the rest of the world), the government have been recommended to consider Microsoft's version of DNS. Will the UK Government follow in the US's footsteps? Martin At 07:04 PM 10/23/2002 +0100, Stephen J. Wilcox wrote: >On Wed, 23 Oct 2002, Sean Donelan wrote: > >> >> The last time all the root servers were down was June 28 1985. On June 29 >> 1985 there was a flurry of messages about adding root server down code to >> the various DNS implementations of the day. Apparently, some of the >> software had a poor response to all root servers being unreachable, and >> spun out of control. >> >> Has anyone tested modern DNS code (Microsoft and BIND to name two) for >> this condition recently? I haven't, hence my question. > >Microsoft DNS has a poor response and can spin out of control with all root >servers available.. how would you tell the difference ;) > >Steve
Re: Wireless insecurity at NANOG meetings
>I agre security is sadly lacking, but it is probably impossible to >implement in a conference environment. Look this is a very simple issue. Sean's first post really pointed out that it's "bad form" for a set of operators to run an insecure network. I would believe that it's "good form" to at least try. It was stated that the network was not run by the "operators". OK, I accept that, but it's run by people with great (actually fantastic) connections to real operators (ie: us). WEP may not be a good protocol, but it's better than nothing. If people thing it's hard to configure, then run two networks.. one without WEP and one with WEP. Security is a relative thing... Normally security at the door to the nanog conference hall is "low", but that does not seem to bother many people. (Hence security at a "wired" locations within the conference is "low" making the WEP issue mute). I would be happy to run on a wireless network with a specific SSID and no SSID beacon with a static WEP key. (I don't have LEAP, or other protocols on my laptop). Does this make my communications more secure? I don't know... Everything from my nanog laptop is VPN'ed anyway... hence already end-to-end encrypted. I believe that Sean brought up a good point and something worth working on. Even an incremental improvement at this upcoming meeting followed by another incremental improvement at the next meeting, etc. etc. will be a good thing. BTW: WEP may not be a great protocol and people may believe there is a false sense of security. If this worries you, then I would recommend a note placed on the nanog web pages that states something like "all IP networking provided at the conference should be considered insecure, etc.". Martin PS: As for bandwidth "stealing". Heck... looking at the stats for previous nanog's, we are doing a poor job of using the provided bandwidth. I say... bring it on! (legal traffic only --- of-course!).
Re: Notes on the Internet for Bell Heads
Sean, My vote goes for... How to build an Internet Service Company From A to Z... All you need to know to plan, build and market an Internet service company. Tips and tricks from the inside. Charles H. Burke July '96 ISBN: 0-935563-02-4 And I quote... > Coffee Maker - Coffee is an necessary as HTML to the aspiring ISP. > ... > I highly recommend the Bunn-Omatic corporation for excellent high > performance coffee makers. > ... It's a classic! As for driving in the UK and US... I have explained the value of roundabouts to many, many Americans and they still don't get it. Being British, but living in the US... I just don't get why they are not used here. You will have to put up with the face that Bell-heads and Net-heads just doing things differently and not understanding why the other side prefers an opposite method! Martin At 03:09 PM 7/11/2002 -0400, Sean Donelan wrote: >Has anyone written the equivalent of the old Bell Systems Notes on the >Network for the Internet? A couple of books come close, Hueston's ISP >Survival Guide and Cisco's ISP Essentials. But there doesn't seem to >be anything that helps Bell heads understand what switching, routing >or signaling means on the Internet. There are a lot of words which are >spelled alike, but mean very different things in the Bell world and the >Internet world. > >I've been thinking of it like driving in England or the USA. We drive >on different sides of the road. Its safe until you get someone who >doesn't know the rules of the road driving on the other side of the >Atlantic. So how do you explain the rules of the Internet road to someone >used to driving on the telephone system?
Re: Hotel in Seattle area w- internet access ?
Joe, Well worth the read if you are going to Seattle... http://seattlewireless.net/ Martin At 11:16 AM 6/26/2002 -0700, joe mcguckin wrote: >I'm leaving for Seattle this evening. Can anyone recommend a hotel that has >internet access in the rooms? > >Thanks, > >joe
Who posts to the nanog list -- The top 59 players (Was not: Re: list problems?)
Hi all, Somewhat related to the previous subject, but bringing it much closer to the operational aspects of the nanog e-mail list, I present this data It only took a few commands to build a count of articles posted to the nanog list over the last 17 months (Jan 2001 to the present day). I sorted them based upon the total count of messages (highest first). I only included the first 59 names. If the e-mail shows up with wrapped lines, then you can find the same information at http://www.mahtin.com/nanog-count.txt which should be easy to read in an unwrapped manner. Note that as some people posting using different real-names in the SMTP headers, there are minor errors in this list. ( "bmanning" missed counting some of "Bill Manning" or "bill manning" posted messages and "Richard A. Steenbergen" and "Richard A Steenbergen" are really the same person). I can't help it if people change their e-mail setups. ;-) Enjoy the data. Martin - # E-MAIL NAME COUNT 2001-01 2001-02 2001-03 2001-04 2001-05 2001-06 2001-07 2001-08 2001-09 2001-10 2001-11 2001-12 2002-01 2002-02 2002-03 2002-04 2002-05 1 Sean Donelan534 68 34 17 44 16 51 24 20 91 36 38 27 6 13 24 17 8 2 Roeland Meyer 371 44 13 51 37 64 - 38 63 61 - - - - - - - - 3 Valdis.Kletnieks231 14 9 20 6 23 12 15 29 18 22 8 7 7 10 6 10 15 4 Randy Bush 214 18 14 10 6 10 21 6 28 33 13 14 11 9 6 4 5 6 5 John Fraizer205 18 32 19 31 26 8 10 24 37 - - - - - - - - 6 E.B. Dreger 147 - - - - 12 15 1 8 19 22 5 5 11 1 9 12 27 7 Paul Vixie 128 13 8 1 - 9 7 1 4 12 22 9 - 1 5 4 16 16 8 Shawn McMahon 127 15 16 34 14 48 - - - - - - - - - - - - 9 Richard A. Steenbergen 127 17 8 5 26 23 40 8 - - - - - - - - - - 10 Dan Hollis 127 6 2 4 14 29 4 8 6 10 5 3 1 8 4 1 1 21 11 David Schwartz 122 - 2 32 13 22 12 4 10 8 3 1 - 1 4 3 3 4 12 Greg A. Woods 115 20 14 16 21 8 18 2 5 1 3 - - - - - - 7 13 Scott Francis 113 - 1 25 4 16 2 8 3 4 3 2 6 2 4 1 3 29 14 bmanning108 15 5 3 9 14 2 4 6 14 4 7 - 6 3 4 8 4 15 Sean M. Doran 106 - - - 9 15 7 - 24 25 6 3 - 1 2 8 5 1 16 Stephen J. Wilcox 105 3 6 10 3 11 3 10 3 10 - - - 1 10 9 6 20 17 Daniel Golding 101 1 5 3 1 7 8 11 6 15 7 9 5 3 4 3 9 4 18 Leo Bicknell100 3 3 - 1 - 9 5 28 23 12 4 2 2 1 2 1 4 19 Hank Nussbacher 100 12 14 10 7 2 6 5 4 14 8 4 3 1 - 3 2 5 20 Patrick Greenwell98 7 7 30 2 2 1 1 17 10 4 8 7 2 - - - - 21 Alex Rubenstein 98 1 7 2 2 9 16 7 3 18 4 8 - 3 5 2 3 8 22 Vadim Antonov94 3 1 12 - 2 - - 25 22 6 3 1 - 13 3 1 2 23 Bill Woodcock93 9 8 3 5 11 5 10
Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
Paul, > now as to who's responsible, ... I hate to say it, but "Microsoft". This is the default for w2k and the like. The interesting thing is that it's got a very short timer for retries and hence why your logs are so big. I found this... http://www.isc.org/ml-archives/bind-users/2001/02/msg01806.html http://www.domainregistry.ie/tech/dynamic-dns.html >Windows 2000 >The option can be found from: >Click Start -> Settings -> Network and Dialup >View the Properties of Local Area >Select Adapter -> Protocols -> TCP/IP -> Advanced -> DNS >The "Register this name" option box should be clear. ...the later would have to be done on millions of boxes around the world. I wanted to add a flag to bind to "silently ignore" these requests, but alas this is not a good solution for reverse-dns private space. I also thought that w2k and the like should not do a dynamic dns update if it's on private IP space, but that's not a valid test either, as the "enterprise" may well only exist in private IP space. (Yes... they should run their own zone for the reverse dns). Martin --- At 04:57 PM 4/18/2002 -0700, you wrote: >according to http://root-servers.org/, dns transactions concerning rfc1918 >address space are now being served by an anycast device near you (no matter >who you might be, or where.) there will eventually be official statistics, >but i thought i'd give everybody a chance to clean up their houses first. > >on the instance ISC runs, i noticed that the log files were turning over >really fast. that is to say, really, really, really fast. see below. > >-rw-r--r-- 1 root sys10485795 Apr 18 12:11 update-1.log.33 >-rw-r--r-- 1 root sys10485850 Apr 18 12:19 update-1.log.32 >-rw-r--r-- 1 root sys10485794 Apr 18 12:26 update-1.log.31 >-rw-r--r-- 1 root sys10485846 Apr 18 12:33 update-1.log.30 >-rw-r--r-- 1 root sys10485787 Apr 18 12:41 update-1.log.29 >-rw-r--r-- 1 root sys10485830 Apr 18 12:48 update-1.log.28 >-rw-r--r-- 1 root sys10485776 Apr 18 12:55 update-1.log.27 >-rw-r--r-- 1 root sys10485873 Apr 18 13:02 update-1.log.26 >-rw-r--r-- 1 root sys10485847 Apr 18 13:09 update-1.log.25 >-rw-r--r-- 1 root sys10485830 Apr 18 13:17 update-1.log.24 >-rw-r--r-- 1 root sys10485783 Apr 18 13:24 update-1.log.23 >-rw-r--r-- 1 root sys10485871 Apr 18 13:31 update-1.log.22 >-rw-r--r-- 1 root sys10485794 Apr 18 13:39 update-1.log.21 >-rw-r--r-- 1 root sys10485866 Apr 18 13:46 update-1.log.20 >-rw-r--r-- 1 root sys10485821 Apr 18 13:54 update-1.log.19 >-rw-r--r-- 1 root sys10485843 Apr 18 14:01 update-1.log.18 >-rw-r--r-- 1 root sys10485831 Apr 18 14:08 update-1.log.17 >-rw-r--r-- 1 root sys10485809 Apr 18 14:16 update-1.log.16 >-rw-r--r-- 1 root sys10485765 Apr 18 14:23 update-1.log.15 >-rw-r--r-- 1 root sys10485802 Apr 18 14:31 update-1.log.14 >-rw-r--r-- 1 root sys10485853 Apr 18 14:39 update-1.log.13 >-rw-r--r-- 1 root sys10485779 Apr 18 14:46 update-1.log.12 >-rw-r--r-- 1 root sys10485822 Apr 18 14:54 update-1.log.11 >-rw-r--r-- 1 root sys10485864 Apr 18 14:59 update-1.log.10 >-rw-r--r-- 1 root sys10485770 Apr 18 15:03 update-1.log.9 >-rw-r--r-- 1 root sys10485801 Apr 18 15:07 update-1.log.8 >-rw-r--r-- 1 root sys10485795 Apr 18 15:14 update-1.log.7 >-rw-r--r-- 1 root sys10485810 Apr 18 15:22 update-1.log.6 >-rw-r--r-- 1 root sys10485762 Apr 18 15:29 update-1.log.5 >-rw-r--r-- 1 root sys10485844 Apr 18 15:37 update-1.log.4 >-rw-r--r-- 1 root sys10485813 Apr 18 15:45 update-1.log.3 >-rw-r--r-- 1 root sys10485806 Apr 18 15:53 update-1.log.2 >-rw-r--r-- 1 root sys10485769 Apr 18 16:00 update-1.log.1 >-rw-r--r-- 1 root sys10485853 Apr 18 16:07 update-1.log.0 >-rw-r--r-- 1 root sys8108342 Apr 18 16:13 update-1.log > >what these files are is a whole lot of lines that look like (broken by me): > >18-Apr-2002 16:16:05.491 security: notice: \ >denied update from [63.198.141.30].2323 for "168.192.in-addr.arpa" IN > >by "a whole lot" i mean we've logged 3.3M of these in the last four hours. > >so who are these people and why are they sending dynamic updates for rfc1918 >address space PTR's? second answer first: it's probably Windows' fault. >after a successful DHCP transaction, the corresponding A RR and PTR RR have >to be updated. if rfc1918 is in use, dns transactions about these PTR's >ought to be caught and directed toward some local server, who can do something >useful with them. this loca
