November 1998 - Test - lists.nanog.org

RE: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection fai lures with some InterNIC.net hosts
by Chris Mauritz 24 Nov '98

24 Nov '98

Actually, this isn't a BigIP problem. It's a BSDI problem (the underlying OS for the BigIP box). I believe BSDI has a patch available for BSD/OS 4.0 (mayabe even 3.1). While you can't benefit from this patch directly, you can perhaps nudge your F5 rep about expediting a patch for your boxen. Chris Chris Mauritz Director, Systems Administration Rare Medium, Inc. chrism(a)raremedium.com -----Original Message----- From: Mark Kosters [mailto:markk@internic.net] Sent: Tuesday, November 24, 1998 11:08 AM To: Greg A. Woods; North America Network Operators Group; NetBSD Networking Technical Discussion List Cc: Mark Kosters Subject: Re: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts On Fri, Nov 20, 1998 at 04:25:11PM -0500, Greg A. Woods wrote: > The problem has to do with the failure of a host to fragment larger > packets on demand (i.e. when the other host sends an ICMP "needs frag" > notification). This may be because the ICMP packet never gets through > (perhaps someone who didn't understand TCP/IP and ICMP and everything > else related implemented a filter on all "abnormal" ICMP packets); or it > may be because the receiving host doesn't understand the ICMP "needs > frag" request (and also doesn't implement path MTU discovery, or have I > got that backwards?). > > No matter what the problem really is, I'm sure a *lot* of people would > be much happier if this problem were fixed, specifically for the WHOIS > service (though I've also had troubles receiving HTTP too). I got quite > a few replies about similar experiences when I first posted about this > on NANOG recently. Thanks Greg for the good information. The InterNIC load balancers (BigIP made by F5 Labs) do have a problem with path MTU discovery. We have taken a short term fix of turning off path MTU discovery on the hosts behind BigIP until F5 issues a fix. Regards, Mark -- Mark Kosters markk(a)internic.net InterNIC Registration Services PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 I am not a spokesperson for NSI. Anything I write or say is my personal opinion and in no way should be interpreted as NSI's official position.

1 0

SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts
by woods＠most.weird.com 24 Nov '98

24 Nov '98

[[ NOTE: this message is cross-posted to NANOG and tech-net, as well as Cc'ed to Mark Kosters (because I don't know if Mark reads either list). Please reply either directly to me, or to *one* of those lists as appropriate (it's probably not relevant to discuss on NANOG now that the problem has been identified unless it's a problem with some particular piece of equipment, in which case it would be good to identify it so others can fix similar problems. ]] I've discovered the cause of those problems with TCP connections to/from some InterNIC.net hosts (and some other hosts, one of which was trying to send me e-mail and thus necessitated that I debug it in more detail). Now that I know the cause I can say that this problem is usually indicative of a firewall with a non-compliant TCP/IP implementation, though it may also indicate an unwise firewall filtering policy too. The problem has to do with the failure of a host to fragment larger packets on demand (i.e. when the other host sends an ICMP "needs frag" notification). This may be because the ICMP packet never gets through (perhaps someone who didn't understand TCP/IP and ICMP and everything else related implemented a filter on all "abnormal" ICMP packets); or it may be because the receiving host doesn't understand the ICMP "needs frag" request (and also doesn't implement path MTU discovery, or have I got that backwards?). No matter what the problem really is, I'm sure a *lot* of people would be much happier if this problem were fixed, specifically for the WHOIS service (though I've also had troubles receiving HTTP too). I got quite a few replies about similar experiences when I first posted about this on NANOG recently. Here's a sample trace collected from the PPP router upstream which shows the outgoing ICMP packets and the incoming TCP retransmissions, un-fragmented, even after the first request to fragment: 15:02:56.097980 204.92.254.2.4721 > 198.41.0.6.43: S 1660910424:1660910424(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 5148233 0> (ttl 62, id 25948) 15:02:56.420273 198.41.0.6.43 > 204.92.254.2.4721: S 1062510833:1062510833(0) ack 1660910425 win 8760 <mss 1460> (DF) (ttl 245, id 4189) 15:02:56.674783 204.92.254.2.4721 > 198.41.0.6.43: . ack 1 win 17520 (ttl 62, id 25951) 15:02:56.677143 204.92.254.2.4721 > 198.41.0.6.43: P 1:6(5) ack 1 win 17520 (ttl 62, id 25952) 15:02:57.175854 198.41.0.6.43 > 204.92.254.2.4721: . ack 6 win 8760 (DF) (ttl 245, id 4190) 15:02:59.393169 198.41.0.6.43 > 204.92.254.2.4721: P 1:4(3) ack 6 win 8760 (DF) (ttl 245, id 4191) 15:02:59.532326 204.92.254.2.4721 > 198.41.0.6.43: . ack 4 win 17517 (ttl 62, id 25994) 15:03:00.326761 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4192) 15:03:00.327688 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19390) 15:03:00.420416 198.41.0.6.43 > 204.92.254.2.4721: . 1464:2914(1450) ack 6 win 8760 (DF) (ttl 245, id 4193) 15:03:00.421157 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19391) 15:03:03.381245 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4194) 15:03:03.382120 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19392) 15:03:10.619116 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4195) 15:03:10.620110 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19411) 15:03:24.974732 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4196) 15:03:24.975626 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19413) 15:03:53.941690 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 4197) 15:03:53.942656 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19418) 15:04:50.256764 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 52333) 15:04:50.257959 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19425) 15:05:46.509834 198.41.0.6.43 > 204.92.254.2.4721: . 4:1464(1460) ack 6 win 8760 (DF) (ttl 245, id 43047) 15:05:46.510716 204.29.161.41 > 198.41.0.6: icmp: 204.92.254.2 unreachable - need to frag (mtu 1006) (DF) (ttl 255, id 19433) 15:06:29.615496 198.41.0.6.43 > 204.92.254.2.4721: R 4:4(0) ack 6 win 0 (ttl 55, id 23874) Note that ICMP packets get through correctly, seemingly because NetBSD fragments them on the way through (I suppose a "needs frag" packet could be sent in this case too, but that does seem a little too intertwined to be reliable). Here's the trace of two big (-s 1400) packet pings from the router's POV: 15:17:21.092624 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 253, id 41845) 15:17:21.366494 198.41.0.6 > 204.92.254.2: icmp: echo reply (ttl 246, id 25176) 15:17:21.978679 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 253, id 41855) 15:17:22.227824 198.41.0.6 > 204.92.254.2: icmp: echo reply (ttl 246, id 25351) And here's what I see on my end of the link corresponding to the above: 15:17:17.466591 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 255, id 41845) 15:17:18.467986 204.92.254.2 > 198.41.0.6: icmp: echo request (ttl 255, id 41855) 15:17:18.487006 198.41.0.6 > 204.92.254.2: icmp: echo reply (frag 25176:984@0+) (ttl 244) 15:17:18.489940 198.41.0.6 > 204.92.254.2: (frag 25176:24@984) (ttl 244) 15:17:19.251136 198.41.0.6 > 204.92.254.2: icmp: echo reply (frag 25351:984@0+) (ttl 244) 15:17:19.263880 198.41.0.6 > 204.92.254.2: (frag 25351:24@984) (ttl 244) Perhaps routers (i.e. NetBSD when it's routing, in this case) should also fragment TCP packets on the way through if there are "too many" retransmissions of over-sized packets (one's too many for me, but I guess on high-latency links there might be two or three in the pipe -- perhaps a timer would help adjust when to do local fragmenting). -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

5 5

NSI policy on lame delagations
by Patrick Greenwell 24 Nov '98

24 Nov '98

Seems that NSI has a new policy on lame delagations. I never heard anything about this. Anyone else? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v CTO (925) 377-1212 v NameSecure (925) 377-1414 f Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ---------- Forwarded message ---------- Date: Fri, 20 Nov 1998 12:17:26 -0500 From: Chuck Gomes <cgomes(a)internic.net> Reply-To: cgomes(a)NETSOL.COM To: DOMAIN-POLICY(a)LISTS.INTERNIC.NET Subject: Re: Missing DNS servers When we become aware of a lame delegation, we remove the name servers and notify the registrant that they have a limited time to provide name servers. If name service is not provided, we delete the name. In the interim the record would show as you see below. Chuck Gomes -----Original Message----- From: Tony Cognata [mailto:yett@BRIO.YIKES.COM] Sent: Friday, November 20, 1998 11:57 AM To: DOMAIN-POLICY(a)LISTS.INTERNIC.NET Subject: Missing DNS servers I would hope that someone working at Network Solutions would know the answer to this question. Why would the "whois" record for a domain called ANSHAN.COM not show a primary and secondary DNS server? Here is the record for the domain: Spearmind Communications MK (ANSHAN7-DOM) Effnerstr. 1e Ingolstadt, Bayern 85049 DE Domain Name: ANSHAN.COM Administrative Contact: Koch, Mario (MK5132) mario.koch(a)USA.NET +49-841-483843 (FAX) +49-201-247180-10447 Technical Contact, Zone Contact: Hostmaster, TABNet (TH941) TABNETHOSTMASTER(a)TABNET.NET 707 256-1999 (FAX) 707 256-1997 Billing Contact: Koch, Mario (MK5132) mario.koch(a)USA.NET +49-841-483843 (FAX) +49-201-247180-10447 Record last updated on 25-Mar-98. Record created on 26-Jan-98. Database last updated on 13-Oct-98 06:21:01 EDT. No known domain servers. --- You'll note that the very last line of the record shows that no DNS servers exist for the domain. The sentence "No known domain servers" appears. Also, on rare occasions I have come across "whois" records for domains that show only one DNS server appearing, not the customary (and required) two. Just curious to know what might be happening in these cases? Thank you. -- DOMAIN-POLICY administrivia should be sent to <listserv(a)lists.internic.net> To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP" -- DOMAIN-POLICY administrivia should be sent to <listserv(a)lists.internic.net> To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP"

14 32

Re: RBL quandry - opinions hereby solicited
by Dean Anderson 24 Nov '98

24 Nov '98

Paul says his only requirement is that they stop when asked. Well, I haven't seen any evidence that they won't or don't. All I have heard is that they make you choose between their email and their service, or no email and no service. That they don't change their business when someone demands and still do business with that person is another matter. It might be arguable about whether they can or should give their list to someone else or who owns the list. But it not even questionable that they can use it themselves to promote their own services. Perhaps you are getting something from NSI that I'm not getting. I've gotten advertisements on topics like how to do DNS, etc. Things that NSI might be able to train people on. Things that registrants of domains might need training on. I haven't gotten anything from NSI that isn't part of NSI's own business, unless you count verisign stuff, which could possibly be outside, but it is still certainly related to their business, and the business of those who have domains registered with them. I actually haven't gotten any email from NSI about verisign--Its all on their we page, I think. I haven't gotten any spam from NSI about, oh, say, the latest porn site, or how to get rich quick using chain letters. I haven't heard that people who aren't customers of NSI are getting unsolicited email from NSI. But you are still missing the definition of spam: what is unsolicited email. It is not "unsolicited" when you have a previously existing relationship, especially a relationship that specifies that you agree to give NSI your email address, and you agree with NSI that they can send you email. Furthermore, you can make NSI stop sending you email simply by not doing business with them. You can register domains in other registries. NSI isn't going out and buying email lists, and spraying email. They are sending to their own customer list. This is using the RBL to bully NSI. Its not about spam. --Dean At 05:07 PM 11/21/1998 -0500, Rich Sena wrote: >Dean stop beeing a boob - it's spam - it's not hey glad your a customer >hope all is well it's hey use us to register new domains - it's being >generated to compete against other avenues of registration - lets call it >what it is - if you like it great - give it a hug and kiss and give it a >rest - the majority I would assume aren't real thrilled about it - and the >whole speil about fake email addresses cuz folk don't want to give out >theirs - is bullshit - the correct answer is "then you don't get a domain" >drive through please. > >On Mon, 16 Nov 1998, Dean Anderson wrote: > >> Not so. You can use another registry. .COM, .NET, and .ORG may be the most >> popular, but they are not the only ones. When you refuse to do business >> with NSI, they don't send you email. They don't get lists and send email >> to random people. If you don't agree to let NSI send you email, they won't >> do business with you. Everyone agreed to those terms. Can't come back and >> change them later, because you don't like it. >> >> Personally, I don't see anything wrong with most of the mail I've gotten >> from them. Some of it a bit technically insulting, but that doesn't make >> it totally unreasonable from an email ethics point of view. It certainly >> doesn't qualify as spam, since it is in fact solicited. You paid $100+ for >> the privilege. >> >> Technically, they aren't broadcasting either. They are sending email to >> their customers. Not potential future customers. Existing customers. They >> didn't buy this list from somewhere. They asked for, and required customers >> to give this information, and to give them permission to send email. >> >> You seem to be in a conflict with your own rules, since you have said that >> you don't RBL companies that are using their own internal lists. As I >> thought, you aren't operating from some kind of moral or ethical principal, >> you are just bullying others. I just don't like that, whether you happen >> to be right or not. >> >> >> 2] They are sending to folks that use the service. >> > >> >yes. which is: everybody who has a domain in COM, NET, or ORG. >> >> Ahh, it has finally come to a confrontation with someone who quite possibly >> speaks more authoritatively for everyone in those domains than you do. >> This will be interesting, to say the least. >> >> I wonder if RBLing NetSol is cause for them to put vix.com on hold. That >> would be a hoot. I suppose they actually could call you in breach of >> contract for refusing to receive email, refund your money, and cancel your >> domains. >> >> --Dean >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Plain Aviation, Inc dean(a)av8.com >> LAN/WAN/UNIX/NT/TCPIP http://www.av8.com >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> > >-- >I am nothing if not net-Q! - ras(a)poppa.clubrich.tiac.net > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

6 5

IMAP attacks continue
by Daniel Senie 24 Nov '98

24 Nov '98

The frequency of IMAP attacks is increasing, and the number of IP addresses scanned per attack seems to be increasing as well. In the last 24 hours, I've been scanned by: fermi.math.csi.cuny.edu c149.lib.uci.edu sockeye.cob.calpoly.edu quebec.upa.qc.ca Anyone upstream of any of these able to add a Sniffer? It'd be interesting to see if someone is connected in via telnet or ssh and launching the attacks remotely. With all of these types of attack in the last several days, the systems doing the attacking have all been ones that were compromised. -- ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com

5 6

Re: Router gets hurt!
by John Fraizer 24 Nov '98

24 Nov '98

Thats Bills way of saying, "You all think you're hot snot with this IP stuff, don't you? Well, check this out!" It is a good idea to start with but, I don't think that microsoft ever thought about what would happen in the event that there were tons of boxes on the network where the "election" was held. You can do the same thing with a couple of *nix boxes running samba if you really want to do so. At 10:01 PM 11/23/98 -0800, Jason Weisberger wrote: > >Discovered today that NT has the built in ability to drown your network >and stomp on the routers cpu. Seems if someone sets up 2 NT domain masters >or whatever that Netbios garbage is called, they attempt to "hold an >election." The election is comprised of slamming every machine it can find >and then every broadcast address it can think of with udp on port 137. > >After a few minutes of it an RSP4 gets real tired and you start losing >packets as well as the switches all falling apart after trying to forward >the zillion mbits/sec of useless data. > >Anyone else seen anything like this? > >-- >Jason Weisberger >Chief Technology Officer >SoftAware, Inc. 310/305-0275 > ------------------------------------------------------------------ Get your *FREE* Parked Domain account at http://www.EZ-Hosting.Com ------------------------------------------------------------------ John Fraizer | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation PGP Key fingerprint = 7DB6 1CA2 DAA6 43DA 3AAF 44CD 258C 3D7E B425 81A8

1 0

Router gets hurt!
by Jason Weisberger 24 Nov '98

24 Nov '98

Discovered today that NT has the built in ability to drown your network and stomp on the routers cpu. Seems if someone sets up 2 NT domain masters or whatever that Netbios garbage is called, they attempt to "hold an election." The election is comprised of slamming every machine it can find and then every broadcast address it can think of with udp on port 137. After a few minutes of it an RSP4 gets real tired and you start losing packets as well as the switches all falling apart after trying to forward the zillion mbits/sec of useless data. Anyone else seen anything like this? -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275

2 1

Re: NSI policy on lame delagations
by Paul Vixie 24 Nov '98

24 Nov '98

> Yet having the advantage that when your SQL- or other-based database > fails, your nameservers don't. I don't disagree with this. There's certainly a mode where BIND should be able to create its own b-tree by loading all of a zone and then managing it through a memory window. But there's also a more sparse mode where you just don't want to have another copy of your zone data, nor the resource consumption of having to make that copy, nor the delay between the times you pick to make that copy. Right now there's no choice since there's no zone API. One is coming, but not in 8.1.2++. -- Paul Vixie <paul(a)vix.com>

1 0

Re: WebTV.Net: Censorship Central?
by Eric Germann 23 Nov '98

23 Nov '98

If Paul will add 208.222.122.40 to the RBL and Merit will use the RBL I'll bet many NANOG readers would buy a WebTV unit just to get rid of Bob... Bob, many pray that you would be added to the RBL, nightly as a matter of fact, before supplications for ones own health. Drop it. ---Bob Allisat wrote: > > > <http://fcn.net/no> > > Microsoft's Web TV Network, with hundreds of thousands of subscribers, > uses the real-time black hole list censorship software. Very disturbing > since it niether tells it's clients their mail and WWW is being censored > nor offers them the choice as to whether or not to allow this censorship. > Outside their lame anti-spam statement there is no indication of any > censorship anywhere else <http://www.webtv.net/antispam/>. > > Perhaps the people using WebTV would appreciate knowing the fact that > Web TV censors their access. Or, even better, maybe Web TV could offer > them the choice as to whether their black list is off or on (default > to off). I'd be royally pissed off if I used WebTV and found out every- > thing I did was behind some one fellow's idea of right and wrong. Shame > on Web TV Networks! More info at: > > <http://fcn.net/no> > > Paul Vixie writes: > <http://maps.vix.com/rbl/webtv.html> > > If you received an error while trying to send mail to WebTV, > > please click here. > * (next page) > > Having problems sending to WebTV? > > > > Although WebTV�(webtv.net) uses the RBL, they also have their own > > list of IP addresses they reject mail from. Just because they > > reject mail from a site does not mean that site is on the > > MAPS�RBL. > > > > You can check to see whether your IP�address is on the RBL by > > checking <URL:http://maps.vix.com/cgi-bin/lookup> ; enter your > > IP�address in the form. > > > > If you do not know what your IP�address is, please contact your > > system administrator or ISP. Complaining to us about WebTV's > > actions is, unfortunately, largely useless, as we have no control > > over how they (or anyone else) runs their systems. > > > > Please contact WebTV�for information on why your address block is > > on their list, and how to get it removed. > > Bob Allisat > > Free Community Network _ bob(a)fcn.net . http://fcn.net > http://fcn.net/allisat _ http://fcn.net/draft > > > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Anyone know...
by Dean Anderson 23 Nov '98

23 Nov '98

If you got mail on saturday, then I think the next reload is monday night. --Dean At 12:41 PM 11/23/1998 -0500, Steven J. Sobol wrote: >why the InterNIC notified me that changes to a domain had been >completed on Saturday, and Whois is updated, but the root servers >still point to DNS on the old site even though there have been two >root server updates since then? Is this related to the problem we were >all discussing last week? > >-- >Steve Sobol [sjsobol(a)nacs.net] >Part-time Support Droid [support(a)nacs.net] >NACS Spaminator [abuse(a)nacs.net] > >Spotted on a bumper sticker: "Possum. The other white meat." > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1