May 2005 - Test - lists.nanog.org

Re: Malicious DNS request?
by Joe Shen 17 May '05

17 May '05

Paul, I'm sorry if this is JUST to BIND or some other specific software. But, IMHO this is just a sample that requests which only generate NXDOMAIN responds. According to someone's presentation on NANOG ("DNS anomailies and their impact on DNS Cache Server" ), such record may be type of attack. If we only rely on cacheing to remove paient of CPU time, cache server load will be increased. So, what I'm tryting to ask is , is there some mechanism proposed to deal with such problem? BIND is just a sample. joe --- Paul Vixie <vixie(a)vix.com> wrote: > > joe_hznm(a)yahoo.com.sg (Joe Shen) writes: > > > I'm using BIND9.2.5 & BIND9.3.1 on two Solaris > box, > > each box has two CPUs installed. it's found > BIND8.4.6 > > running on one CPU could reach the throughput of > > BIND9.*.* running on two CPUs. > > > > Could we improve server throughput or lower lower > the > > effect of those requests on NXDOMAIN? > > yes. but "we" isn't nanog. can you take your > bind-specific questions > to a bind-related mailing list or newsgroup? > www.isc.org has pointers. > -- > Paul Vixie > __________________________________________________ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com

2 1

FCC set to require 911 for VoIP as early as Thursday...
by Fergie (Paul Ferguson) 17 May '05

17 May '05

Things just seem to coalesce sometimes. http://www.reuters.com/newsArticle.jhtml?type=topNews&storyID=8521222 - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com

1 0

Re: Malicious DNS request?
by Joe Shen 17 May '05

17 May '05

Hi, thanks for your help. I noticed that the requests of those non-exist domain name disappeared yesterday. But the NXDOMAIN record in named.stats keep increasing. ( see attachment) I'm using BIND9.2.5 & BIND9.3.1 on two Solaris box, each box has two CPUs installed. it's found BIND8.4.6 running on one CPU could reach the throughput of BIND9.*.* running on two CPUs. Could we improve server throughput or lower lower the effect of those requests on NXDOMAIN? Joe __________________________________________________ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com

5 4

Re: Malicious DNS request?
by Joe Shen 17 May '05

17 May '05

Sorry to attach the "rndc stats" result. I run "rndc stats" continuously( interval is less than 2 seconds), it's shown: ==================== success 17950622 referral 225680 nxrrset 1691861 nxdomain 11203490 recursion 3648017 failure 1363923 ... --- Statistics Dump --- (1116319437) +++ Statistics Dump +++ (1116322885) success 18889882 referral 229772 nxrrset 1809835 nxdomain 11474755 recursion 3825876 failure 1415044 .... --- Statistics Dump --- (1116322885) +++ Statistics Dump +++ (1116322886) success 18890342 referral 229772 nxrrset 1809868 nxdomain 11474873 recursion 3825976 failure 1415052 .... --- Statistics Dump --- (1116322886) Joe __________________________________________________ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com

1 0

Re: Malicious DNS request?
by Joe Shen 17 May '05

17 May '05

Sorry to attach the "rndc stats" result. I run "rndc stats" continuously( interval is less than 2 seconds), it's shown: ==================== success 17950622 referral 225680 nxrrset 1691861 nxdomain 11203490 recursion 3648017 failure 1363923 ... --- Statistics Dump --- (1116319437) +++ Statistics Dump +++ (1116322885) success 18889882 referral 229772 nxrrset 1809835 nxdomain 11474755 recursion 3825876 failure 1415044 .... --- Statistics Dump --- (1116322885) +++ Statistics Dump +++ (1116322886) success 18890342 referral 229772 nxrrset 1809868 nxdomain 11474873 recursion 3825976 failure 1415052 .... --- Statistics Dump --- (1116322886) Joe __________________________________________________ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com

1 0

Fwd: BCP 104,
by Fergie (Paul Ferguson) 16 May '05

16 May '05

Forgive the forwarding, but I thought this BCP might be of interest to the list. - ferg [snip] A new Request for Comments is now available in online RFC libraries. BCP 104 RFC 4084 Title: Terminology for Describing Internet Connectivity Author(s): J. Klensin Status: Best Current Practice Date: May 2005 Mailbox: john-ietf(a)jck.com Pages: 11 Characters: 24522 SeeAlso: BCP 104 I-D Tag: draft-klensin-ip-service-terms-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4084.txt As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Verisign broke GTLDs again?
by Michael Tokarev 16 May '05

16 May '05

Noticied today. All Verisign's GTLD servers broke EDNS0 (RFC2671). Here's how it looks like: query: $ dnsget -t mx -vv microsoft.net. -n 192.5.6.30 ;; trying microsoft.net. ;; sending 42 bytes query to 192.5.6.30 port 53 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64471, size: 42 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUERY SECTION (1): ;microsoft.net. IN MX ;; ADDITIONAL section (1): ;EDNS0 OPT record (UDPsize: 4096): 0 bytes Note the EDNS0 stuff (numar=1). And here's the reply to this query: ;; received 12 bytes response from 192.5.6.30 port 53 ;; unexpected number of entries in QUERY section: 0 ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64471, size: 12 ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION (0): ; invalid query section They're returning FORMERR (which is wrong), *and* don't return the original query (numqd=0). Without EDNS0 extensions, it works like expected. /mjt

5 7

NANOG34/Seattle: Found
by Carol Wadsworth 16 May '05

16 May '05

Found: one jump drive in Terminal Room

1 0

Re: what will all you who work for private isp's be doing in a few years?
by Frank Coluccio 16 May '05

16 May '05

Alexei Roudnev wrote: >> What I can't understand is why multicast hasn't just gone gangbusters into >> use yet. I see it as a really pent-up capability that, in light of >Because multicast standards was written by academic idiots. -:) Very >difficult to use and full of unused features. > >(Do not believe? Read RSVP protocol - not exactly multicast but not far away >from it). > >And because multicast protocols (unfortunately) are not easy to implement. >It excuse this standards and their authors. > >I can predict one more 'skype' like company, with really robust protocol, >catching multicast market. Something like 'peer to peer multicast' -:). Don't be too quick to assess the usage and value of multicast in last mile access networks, where it has found far greater success than over the Internet proper across the WAN. IP- and ATM- based multicast has worked very well for the past five years in telco VDSL (check out Next Level's implementations during the late nineties), and now in all manner of xDSL implementations, as well as a number of cable operator service applications in the digital region of their spectrum, for program video delivery to homes. Check it out. http://www.cisco.com/warp/public/cc/so/neso/dsso/global/madsl_wp.htm Frank A. Coluccio DTI Consulting Inc. On Fri May 13 2:29 , "Alexei Roudnev" sent: > >> >> >> So imagine a residential area all pulling digital video over wireless. >> Sound familiar? Ironically close to TV! (yet so different) >> >> What I can't understand is why multicast hasn't just gone gangbusters into >> use yet. I see it as a really pent-up capability that, in light of >Because multicast standards was written by academic idiots. -:) Very >difficult to use and full of unused features. > >(Do not believe? Read RSVP protocol - not exactly multicast but not far away >from it). > >And because multicast protocols (unfortunately) are not easy to implement. >It excuse this standards and their authors. > >I can predict one more 'skype' like company, with really robust protocol, >catching multicast market. Something like 'peer to peer multicast' -:). > > > > >> broadband video, etc., is just going to have to break wide open soon. >> >> Joe >> >> >> >> >> Ross Hosman >> >sjsobol(a)JustThe.net>, Fred Heutte aoxomoxoa(a)sunlightdata.com> >> @yahoo.com> cc: nanog(a)nanog.org >> Sent by: Subject: Re: what will all >you who work for private isp's be doing in a few years? >> owner-nanog >> >> >> 05/12/2005 02:16 >> PM >> >> >> >> >> >> >> >> Not pointing any fingers but many of you think these >> small ISP's are just going to die off instead of >> adapt. Wireless is becoming a better and more reliable >> technology that in the future will be able to provide >> faster service then FTTH. I know of atleast one small >> ISP in Michigan that went from dial-up to deploying >> wireless. With WiMAX coming out I think you will see a >> number of smaller ISPs switching to it as a service. >> It is also much cheaper to deploy a wireless network. >> >> Me personally, I think wireless is the future for >> residential internet/tv/phone. >> >> Ross Hosman >> Charter Communcations >> >> --- Steve Sobol sjsobol(a)JustThe.net> wrote: >> > >> > Fred Heutte wrote: >> > > (1) There will be a market for independent ISPs as >> > long CLECs >> > >> > I think a more appropriate term would be ALEC >> > >> > (anti-competitive local exchange carrier) >> > >> > ...That having been said, the problem with the small >> > guys providing access is >> > they can't generally achieve the economies of scale >> > that allow them to compete >> > with the big guys. >> > >> > I'm on a Charter cablemodem, 3mbps down x 256kbps >> > up, $39.95/month. Verizon is >> > building out FTTH in this area and they're going to >> > be offering 5x2 for $39.95 >> > or 10x5 for $49.95, IIRC. Those are all residential >> > prices, but Charter's >> > actually pretty competitive on business rates too. >> > >> > And yes, there are people who value service over >> > price, but the price >> > differential is only going to get worse. >> > >> > >> > -- >> > JustThe.net - Apple Valley, CA - http://JustThe.net/ >> > - 888.480.4NET (4638) >> > Steven J. Sobol, Geek In Charge / >> > sjsobol(a)JustThe.net / PGP: 0xE3AE35ED >> > >> > "The wisdom of a fool won't set you free" >> > --New Order, "Bizarre Love Triangle" >> > >> >> >> >

2 1

Re: Malicious DNS request?
by Bill Stewart 16 May '05

16 May '05

Tunneling IP over DNS - Dan Kaminsky's ozymandns project. One source of really strange DNS packets I've seen is Dan Kaminsky's experiments with tunneling IP over DNS , which he presented at Codecon, Defcon, and other places. Dan has often done Really Twisted Things With Packets, and once you've already tunneled IP though HTTP, it's time to do something a bit more aggressive. His first implementations were relatively straightforward, good enough for using SSH and email from the DNS servers on random wireless access points without needing to log in, but they weren't really high performance. The work he demonstrated at Codecon 2005 was able to do high-performance streaming video over DNS, which required spreading the data stream over tens of thousands of DNS servers. It was quite impressive, in a this-is-seriously-wrong kind of way. Perhaps somebody's running something like that somewhere near you.

1 0