- NANOG - lists.nanog.org

More MSFT woes.
by Jeff Mcadams 02 Feb '01

02 Feb '01

http://dailynews.yahoo.com/h/ap/20010202/tc/email_microsoft_1.html Seems like an email test got out of hand. Saying it doesn't reflect any problem with Exchange. I would tend to question that...a backlog of mail should be able to be processed more quickly than that I would think...though I don't really know the severity of the situation, so I'll give them the benefit of the doubt for now. FWIW, to the best of my knowledge, there is no relation between myself and the Scott McAdams quoted. (McAdams really isn't all that common of a name though, so I guess its possible) -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

2 1

XO Routing Issues in Maryland
by Omachonu Ogali 02 Feb '01

02 Feb '01

Does anyone know if XO reported an outage or any sort of issue affecting their Maryland POP? traceroute to ns.nova.org (209.31.144.41), 30 hops max, 40 byte packets 1 nac-gw.colo1.psn1.informationwave.net (207.99.106.1) 4.761 ms 1.728 ms 1.084 ms 2 s4-1.core1.whi.nac.net (209.123.11.153) 2.337 ms 1.758 ms 1.971 ms 3 global-crossing.transit.nac.net (207.99.10.2) 3.311 ms 2.919 ms 4.027 ms 4 s3-0-1-45M.br1.NYC2.gblx.net (206.132.29.161) 5.706 ms 4.632 ms 5.805 ms 5 pos2-2-155M.cr1.NYC2.gblx.net (208.51.66.17) 3.996 ms 3.228 ms 3.327 ms 6 pos10-3-622M.cr1.IAD3.gblx.net (208.48.234.221) 11.108 ms 12.834 ms 13.095 ms 7 208.49.231.10 (208.49.231.10) 10.930 ms 10.802 ms 11.984 ms 8 a2-0d821.core2.was-dc.us.xo.com (208.36.132.33) 11.646 ms 11.641 ms 12.177 ms 9 p1-0.tran1.nyc-ny.us.xo.com (64.0.0.42) 14.262 ms 15.195 ms 17.064 ms 10 p0-0.tran1.nwk-nj.us.xo.com (64.0.0.50) 16.675 ms 15.872 ms 16.306 ms 11 ge10-0.tran2.nwk-nj.us.xo.com (64.220.1.34) 17.255 ms 17.606 ms 16.016 ms 12 p0-0.tran2.chi-il.us.xo.com (64.0.0.45) 81.048 ms 83.928 ms 80.970 ms 13 ge4-0-0.core2.chi-il.us.xo.com (64.220.0.199) 81.309 ms 83.400 ms 80.947 ms 14 e31-1.bcr01.chi-il.us.cnc.net (207.88.48.68) 87.273 ms 82.624 ms 82.016 ms 15 206.83.91.154 (206.83.91.154) 112.163 ms 112.481 ms 118.052 ms 16 e31-23.bcr01.per-md.us.xo.com (209.220.97.102) 115.039 ms 118.966 ms 116.221 ms 17 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 114.528 ms 115.861 ms 115.369 ms 18 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 113.670 ms 113.359 ms 116.677 ms 19 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 113.869 ms 111.134 ms 114.139 ms 20 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 116.745 ms 116.585 ms 114.489 ms 21 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 113.891 ms 115.539 ms 113.167 ms 22 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 116.336 ms 115.490 ms 115.565 ms 23 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 117.069 ms 115.492 ms 116.245 ms 24 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 114.055 ms 116.477 ms 118.461 ms 25 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 116.595 ms 117.359 ms 116.917 ms 26 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 118.080 ms 115.674 ms 118.444 ms 27 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 116.193 ms 140.078 ms 120.025 ms 28 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 118.713 ms 117.849 ms 116.288 ms 29 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 118.428 ms 119.300 ms 122.720 ms 30 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 119.031 ms 117.408 ms 118.763 ms -- Omachonu Ogali missnglnk(a)informationwave.net http://www.informationwave.net

1 0

Not a good day now stuff from here is on BBC
by Henry R. Linneweh 02 Feb '01

02 Feb '01

Major net security holes identified http://news.bbc.co.uk/hi/english/sci/tech/newsid_1142000/1142572.stm -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | |--------------------------------| Henry R. Linneweh

8 8

Re: [NANOG] Re: Reasons why BIND isn't being upgraded
by Sean Donelan 02 Feb '01

02 Feb '01

On Thu, 01 February 2001, Paul Vixie wrote: > pi(a)vuurwerk.nl (Pim van Riezen) writes: > > bogosity while updating 8.2.2-P7 to 8.2.3: > > > > (1) 8.2.3 Doesn't accept the "(" in the SOA string to be on the next line > > after the IN SOA. Our script-generated zonefiles, about 45000 of them, > > all had this. > > Neither do the relevant RFC's, or any other DNS implementation. Pre-8.2.3 > was simply _wrong_ to accept that syntax. Is there any particular harm from accepting this syntax. It wouldn't be the first time a RFC has been updated to match working code.

4 3

RE: [NANOG] Re: Reasons why BIND isn't being upgraded
by Roeland Meyer 02 Feb '01

02 Feb '01

> From: Joshua Goodall [mailto:joshua@roughtrade.net] > Sent: Friday, February 02, 2001 12:52 AM > I can understand the annoyance felt by a large hosting > provider updating > BIND in an emergency and finding more than just a security > fix. Pim is, I > guess, concerned that similar updates in future may have longer MTTR > impact. Pete Elke's point about preproduction testing could > perhaps be > turned from a combative tone to the constructive without loss of > information. Isn't that why NSI is running a stealth master root server ... so they _are able_ to do pre-production testing of zone files? In the past few years, there were a lot of root server outages that would have been prevented by that practice.

2 1

RE: Reasons why BIND isn't being upgraded
by Carter, Gregory 02 Feb '01

02 Feb '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think if anything is to be stressed here is that it should be left up to the administrator of the network to choose whether they wish the version records to be available or not. Theory can be argued for it to either be enabled or disabled but honestly I wouldn't care either way if the choice was left to me and by default it was not enabled until I specified otherwise. I had no idea that named had ever responded this way until it was posted to this list to my surprise. I am not an advocate of security through obscurity however I don't feel that administrators should be removing all doubt to script kiddies of what versions of software they are running so easily. Make them work for it. 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: Adam McKenna [mailto:adam@flounder.net] Sent: Thursday, February 01, 2001 6:13 PM To: nanog(a)merit.edu Subject: Re: Reasons why BIND isn't being upgraded On Thu, Feb 01, 2001 at 06:07:44PM -0800, Paul Vixie wrote: > Simon(a)wretched.demon.co.uk (Simon Waters) writes: > > I remain unconvinced that showing the version string helps much. > > it helped you with your survey, didn't it? > > hiding it doesn't help at all. people who want to know if you're vulnerable > and to what have tools to find out. > > hiding it DOES however make it harder for people (including network owners) > to do surveys. I always thought that it was regarded as generally good security practice to give out as little information about your systems as possible, and none at all if you can help it. The BIND version should at least only be accessible from a set of defined IP addresses, defaulting to 127/8. - --Adam - -- Adam McKenna <adam-sig(a)flounder.net> | "No matter how much it changes, http://flounder.net/publickey.html | technology's just a bunch of wires GPG: 17A4 11F7 5E7E C2E7 08AA | connected to a bunch of other wires." 38B0 05D0 8BF7 2C6D 110A | Joe Rogan, _NewsRadio_ 9:10pm up 236 days, 19:28, 8 users, load average: 0.00, 0.00, 0.00 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBOnoajygrak0xvB4zEQI8PACg6QEbINrVYiEtOO/XzPs+AIwVt8IAoMsq 8x9K6g6r4P+hHrJNhnijJQux =IGS6 -----END PGP SIGNATURE-----

2 1

Re: [NANOG] Re: Reasons why BIND isn't being upgraded
by Paul Vixie 02 Feb '01

02 Feb '01

pi(a)vuurwerk.nl (Pim van Riezen) writes: > bogosity while updating 8.2.2-P7 to 8.2.3: > > (1) 8.2.3 Doesn't accept the "(" in the SOA string to be on the next line > after the IN SOA. Our script-generated zonefiles, about 45000 of them, > all had this. Neither do the relevant RFC's, or any other DNS implementation. Pre-8.2.3 was simply _wrong_ to accept that syntax. > (2) 8.2.3 Changed the meaning of the last field of the SOA record and > needs a $TTL directive to cover the default TTL. This also affected > all of our zones (86400 seconds timeout on negative caching is, you > must agree, way over the top so not a value you want to propagate). This also is per several (recent) RFC's, and again, pre-8.2.3 was simply _wrong_ in its use of the SOA.MINTTL as a default TTL for the whole zone. > (3) 8.2.3 Is unforgiving against errors in zonefiles. Where previously > individual records were rejected (or served as-is), bind now insists > on dropping the entire zone if something went wrong. Needless to say > in a reload of 45K domains it takes a bit of time to fish out the > bad ones. A zone either has an identity or it doesn't. There's no such thing as a best effort identity. If the file is not syntactically valid, it's not a zone and ought not be served, since it has no specific identity for the serial number to map to. > When downloading I expected a security upgrade, not a service pack. You and a lot of other people. 8.2.2-P8 will be along shortly.

2 1

Re: Scalable Mail solution with NAS
by Mike Johnson 01 Feb '01

01 Feb '01

Ron Snyder [snyder(a)roguewave.com] wrote: > On Thu, Feb 01, 2001 at 10:12:51AM -0500, Mike Johnson wrote: > > to deal with concurrent access. I've yet to find a version of > > this software that runs on Linux (or any other Open Sourceish OS), > > so it's not even a consideration for me. > > You mean something like > http://www.missioncriticallinux.com/technology/cluster/ ? Nope, I don't. See page 4 of their white paper: http://www.missioncriticallinux.com/technology/cluster/kimberlite.pdf Quote: Although both systems can access shared disk storage, to ensure data integrity, only one cluster system can run a service and access service data at one time. To prevent a service from running on multiple systems and corrupting data, each cluster system is remotely connected to the other cluster system's power switch through a serial line. This remote connection enables each cluster system to completely disable the other cluster system by cycling its power. Once a cluster system has been disabled, its services can be safely restarted on the other cluster system. They go to great lengths to ensure that no more than one system is accessing a single piece of data at the same time. Lots of companies do this (maybe not with this amount of paranoia, but it's still done). The hard part is to allow both systems to have access to the same data at the same time. Write operations on the same file are prevented by distributed lock managers. This is what Veritas Cluster and Sun Cluster do. It seems to be relatively difficult, otherwise I'm sure we'd already see plenty of options. I looked into the various options (about six months ago) and arrived at the conclusion that this was best done via NAS boxes. They handle locks pretty well, allowing concurrent access to the same file (best implemented with write locks, allowing read-only access). This allows the option of placing a bank of otherwise identical SMTP/IMAP servers behind a load-balancing switch attached to the NAS. The end users only ever see one hostname, but their request would be handled by the least loaded box. Need more capacity for more users? Add more servers. Need more storage space? Max out the capacity of the NAS, then add more NAS boxes. They're just mount points on the host. Mike -- Mike Johnson Network Engineer / iSun Networks, Inc. Morrisville, NC All opinions are mine, not those of my employer

1 0

Re: Wierd portscans
by Elric 01 Feb '01

01 Feb '01

On Wed, 31 Jan 2001, Justin Hinderliter wrote: > > One thought that comes to mind in regards to the high-numbered ports is > whether they might think that that's a firewall running PAT/NAT, in which > case, private IPs behind the firewall would end up showing up as > high-numbered ports on the firewall. Is this on a gateway/firewall, and if > so, are you running NAT/PAT? Nope, we aren't running NAT or PAT. - Elric -------------------------------------------------------------------------- Network Administrator Dierking Scott Enterprises --------------------------------------------------------------------------

1 0

Scalable Mail solution with NAS
by Patrick Hollowell 01 Feb '01

01 Feb '01

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? Patrick Hollowell Sr. Network Engineer CTC Internet Services phollowell(a)vnet.net 800-377-3282 x3527

14 15