Ooops... My apologies (before I get slammed). I forgot the query type of NS in my dig. ; <<>> DiG 9.2.1 <<>> @a.root-servers.net ns mil. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 11 ;; QUESTION SECTION: ;mil. IN NS ;; ANSWER SECTION: mil. 86400 IN NS E.ROOT-SERVERS.NET. mil. 86400 IN NS PAC2.NIPR.mil. mil. 86400 IN NS CON1.NIPR.mil. mil. 86400 IN NS B.ROOT-SERVERS.NET. mil. 86400 IN NS A.ROOT-SERVERS.NET. mil. 86400 IN NS EUR1.NIPR.mil. mil. 86400 IN NS PAC1.NIPR.mil. mil. 86400 IN NS H.ROOT-SERVERS.NET. mil. 86400 IN NS G.ROOT-SERVERS.NET. mil. 86400 IN NS CON2.NIPR.mil. mil. 86400 IN NS EUR2.NIPR.mil. ;; ADDITIONAL SECTION: E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 PAC2.NIPR.mil. 86400 IN A 199.252.155.234 CON1.NIPR.mil. 86400 IN A 199.252.175.234 B.ROOT-SERVERS.NET. 3600000 IN A 128.9.0.107 A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 EUR1.NIPR.mil. 86400 IN A 199.252.154.234 PAC1.NIPR.mil. 86400 IN A 199.252.180.234 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 CON2.NIPR.mil. 86400 IN A 199.252.173.234 EUR2.NIPR.mil. 86400 IN A 199.252.143.234 ;; Query time: 500 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Aug 21 16:07:56 2002 ;; MSG SIZE rcvd: 412 That's better. :) Go back to your regularly scheduled threads. At 03:04 PM 8/21/2002 -0500, you wrote:

On Wed, Aug 21, 2002 at 03:46:22PM -0400, Vinny Abello wrote:

...

I just stumbled across something I thought was interesting. All the .mil domain names used by the U.S. Military are served by one single root server. I thought that was a bit odd. I'm sure that one server is more

than

...

enough to handle the queries for all the .mil domains with no problem, but it doesn't seem very redundant or safe at all. Especially for something our military uses. There's something that could be beefed up a little bit. My other thought (which others may know) was that perhaps the military runs G.ROOT-SERVERS.NET and I'm just not aware of it. Maybe it's a policy to only run .mil on what they can control? Even still, I think it might be in their best interest to setup a few more.

These are the results I got when I queried A.ROOT-SERVERS.NET:

; <<>> DiG 9.2.1 <<>> @a.root-servers.net mil. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION: ;mil. IN A

;; AUTHORITY SECTION: mil. 86400 IN SOA G.ROOT-SERVERS.NET. HOSTMASTER.N IC.mil. 2002082000 3600 900 1209600 86400

Ummmm. The SOA MNAME field is always a single server.

bastet[~]$ dig +short mil ns @g.root-servers.net PAC1.NIPR.mil. H.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. CON2.NIPR.mil. EUR2.NIPR.mil. E.ROOT-SERVERS.NET. PAC2.NIPR.mil. CON1.NIPR.mil. B.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. EUR1.NIPR.mil. bastet[~]$

-Pete

Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN

OK. People can stop correcting me now. :) I did catch the mistake immediately after I sent the email. Now something REALLY useful in an email client would be an unsend feature... I'm joking of course. I have to say that before I get slammed with the technical reasons why that wouldn't work for mail on the Internet which I'm already well aware. ;) At 01:24 PM 8/21/2002 -0700, you wrote:

% dig +norec @a.root-servers.net. mil. ns

; <<>> DiG 9.3.0s20020722 <<>> +norec @a.root-servers.net. mil. ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17626 ;; flags: qr aa; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 11

;; QUESTION SECTION: ;mil. IN NS

;; ANSWER SECTION: mil. 86400 IN NS PAC1.NIPR.mil. mil. 86400 IN NS H.ROOT-SERVERS.NET. mil. 86400 IN NS G.ROOT-SERVERS.NET. mil. 86400 IN NS CON2.NIPR.mil. mil. 86400 IN NS EUR2.NIPR.mil. mil. 86400 IN NS E.ROOT-SERVERS.NET. mil. 86400 IN NS PAC2.NIPR.mil. mil. 86400 IN NS CON1.NIPR.mil. mil. 86400 IN NS B.ROOT-SERVERS.NET. mil. 86400 IN NS A.ROOT-SERVERS.NET. mil. 86400 IN NS EUR1.NIPR.mil.

;; ADDITIONAL SECTION: PAC1.NIPR.mil. 86400 IN A 199.252.180.234 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 CON2.NIPR.mil. 86400 IN A 199.252.173.234 EUR2.NIPR.mil. 86400 IN A 199.252.143.234 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 PAC2.NIPR.mil. 86400 IN A 199.252.155.234 CON1.NIPR.mil. 86400 IN A 199.252.175.234 B.ROOT-SERVERS.NET. 3600000 IN A 128.9.0.107 A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 EUR1.NIPR.mil. 86400 IN A 199.252.154.234

;; Query time: 104 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net.) ;; WHEN: Wed Aug 21 13:15:28 2002 ;; MSG SIZE rcvd: 412

% doc -p -w mil Doc-2.2.3: doc -p -w mil Doc-2.2.3: Starting test of mil. parent is . Doc-2.2.3: Test date - Wed Aug 21 13:19:12 PDT 2002 Summary: No errors or warnings issued for mil. Done testing mil. Wed Aug 21 13:19:21 PDT 2002

Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN

At 12:09 AM +0200 2002/08/22, Mikael Abrahamsson wrote:

I guess that if mail sent to the nanog list wouldnt take 5-60 minutes to get delivered to all people on the list, people would sooner see that someone else has actually answered the email in question, and wont answer themselves.

Show me the headers that demonstrate these delays. On the message I am responding to, I see an end-to-end delay of just a few minutes, and that amount of time could easily be accounted for by your clock being slightly off from mine.

I remember this being discussed earlier, is there any perticular reason why this hasnt been fixed? If nanog-l is supposed to be a list for operational purposes, doesnt that require speedy delivery in a lot of cases?

For more details on the issues involved, read the following: Author: Rob Kolstad Title: Tuning Sendmail for Large Mailing Lists Pages: 195 Publisher: USENIX Proceedings: Eleventh Systems Administration Conference (LISA '97) Date: October 26-31, 1997 Location: San Diego, California Institution: Berkeley Software Design, Inc. Author: Strata Rose Chalup Author: Christine Hogan Author: Greg Kulosa Author: Bryan McDonald Author: Bryan Stansell Title: Drinking from the Fire(walls) Hose: Another Approach to Very Large Mailing Lists Pages: 317 Publisher: USENIX Proceedings: Twelfth Systems Administration Conference (LISA '98) Date: December 6-11, 1998 Location: Boston, Massachusetts Institution: Global Networking and Computing, Inc. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

At 12:09 AM 8/22/2002, Chris Adams wrote:

Once upon a time, Brad Knowles <brad.knowles@skynet.be> said:

...

Show me the headers that demonstrate these delays. On the message I am responding to, I see an end-to-end delay of just a few minutes, and that amount of time could easily be accounted for by your clock being slightly off from mine.

Well, on the thread in question, my response took 15 minutes to get back to me (well, 15:06 to be precise). That is by far the largest RTT for a list that I've posted to lately (not counting lists with servers down, etc.).

Headers show it took 50 seconds for my last post to make it here.

At 7:19 AM +0200 2002/08/22, Mikael Abrahamsson wrote:

Here are two examples. I have seen email with 20+ minutes delay even on the last hop to me, though in the first example it was only 4-5 minutes. In the first example most of the delay is within merit, on the last one the majority of the delay is from trapdoor to my box.

But we don't know what the *cause* is of the delay between Merit & your box. That might be caused by network problems between the two points, your box temporarily being unavailable, or whatever. We just don't have enough information to make a determination as to whose fault this problem is. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

On Fri, Aug 23, 2002 at 07:21:47AM +0200, Mikael Abrahamsson wrote:

Well, I am convinced that the problem lies in the way the list is set up or the software chosen. I checked approx 50 nanog-l email and almost no email is delivered to me within 5 minutes on this list, when there are 3-5 messages being posted in quick succession the delivery time quickly goes up to 10-15+ minutes.

Are the contents of the nanog list so incredibly important that we must get delivery within 5 minutes or less? If it takes longer than 5 minutes to propagate, do you get your post free? Oh wait, the list is already free...hmm. If you want near-instantaneous mail delivery, you can have it -- for a fee. As in all things, you get what you pay for. Personally, I am quite happy with the list as is -- the new list setup is a vast improvement over what things were just a few months ago. I'm not about to complain over a few minutes. How many of us check our email every few minutes anyway? Perhaps the delay will encourage people to wait, and consider their post before jumping on a thread -- that seems to be the real culprit. --msa

At 8:50 AM -0400 2002/08/23, Richard A Steenbergen wrote:

I've seen it be better, and I've also seen it be a lot worse. But if speeding up the mail delivery time can stop the endless supply of useless replies to things which have already been addressed, I'd suggest it's worth it.

See <http://www.usenix.org/publications/library/proceedings/lisa98/full_papers/chalup/chalup_html/chalup.html>. Not everyone agrees that instantaneous mail delivery will solve all problems. It might help choke off replies coming back from people who get slow mail delivery, but it's certainly not going to stop people who are slow to *check* their mail, and respond before reading all messages in the thread. Moreover, it would be likely to encourage chat-like flaming.

And that $300 minimum * 500 people = $150k * 3 = $750k/yr charged at meetings, that doesn't count?

How many of the people on this list actually go to the meetings? How many actually pay the fees? How many people who go to the meetings and pay the fees *don't* watch this list? Maybe we should have separate lists, with one just for the people who actually pay the fees? Then they can discuss things as much as they want amongst themselves, and not have to worry about all these freebie hangers-on? Seriously, there is no charge to join the list, and if you want to change that fact, I suspect you're going to drive away most of the people. Some of the people you drive away might not be of particular importance to you, but I can't imagine that you would want to drive away everybody who doesn't pay the $300 fee. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

At 2:01 AM -0400 2002/08/23, Jim Popovitch wrote:

IMHO, I know of no out-of-the-box MTA that defaults to handle mailinglist loads.

I've been specializing in e-mail system administration for about ten years, and doing large systems & performance tuning of e-mail systems for about six. I can tell you from personal experience that Postfix is better at handling them out-of-the-box than any other I know of.

The trick to speedy turnaround is in the MTA configuration.

Indeed. Hence my references to the two main papers published so far on this topic, one by Rob Kolstand and one by Strata Chalup.

This is chiefly achieved by using multiple queues, as well as severely reducing the timeouts such that email being sent to unreachable/overloaded mailhosts are quickly moved to the bottom of the delivery stack.

These are some of the standard techniques, yes. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

-----Original Message----- From: Brad Knowles

I've been specializing in e-mail system administration for about ten years, and doing large systems & performance tuning of e-mail systems for about six. I can tell you from personal experience that Postfix is better at handling them out-of-the-box than any other I know of.

Interesting... mail.merit.edu seems to be running Postfix. Did they dumb it down? :) -Jim P.

On Fri, Aug 23, 2002 at 06:11:44PM +0200, Brad Knowles wrote:

At 9:17 AM -0400 2002/08/23, Jim Popovitch wrote:

...

Interesting... mail.merit.edu seems to be running Postfix.

Indeed, that was part of my point. They've already made a pretty good choice for an MTA to handle mail for the list.

...

Did they dumb it down? :)

I doubt it. They've just got a big list, and they may not have tuned the installation quite as much as they could have.

As of about a year ago, the major problems were: The subscriber list is *HUGE*. It is relatively high volume. Even running postfix, they need more per-queue tuning than the mailing list administrator can do amongst her 100's of other jobs (Hi Sue!). For the most part, things work pretty well.

Brad Knowles, <brad.knowles@skynet.be>

-- Jeff Haas NextHop Technologies

At 11:09 PM -0500 2002/08/21, Chris Adams wrote:

Well, on the thread in question, my response took 15 minutes to get back to me (well, 15:06 to be precise). That is by far the largest RTT for a list that I've posted to lately (not counting lists with servers down, etc.).

See my previous message on this thread. Without knowing more about how their network is run and what their current message delivery statistics are, all I'm seeing are a few complaints from a few people that they're seeing deliveries sometimes take 15-20 minutes. This could very easily fit within an extremely reasonable delivery standard of 95% of all e-mail being delivered within five minutes, and 99% of all e-mail being delivered within one hour. I'm still not seeing a problem here. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)