.mil domain root only hosted by one server??

Vinny_Abello1 · August 21, 2002, 7:46pm

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

;; Query time: 390 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Wed Aug 21 15:38:58 2002
;; MSG SIZE rcvd: 90

I'd like comments from anyone with more information on this. I'm just curious as to why it is this way and what the reasoning behind it is. Maybe I'll email hostmaster.nic.mil and ask.

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

Joe_Abley · August 21, 2002, 7:59pm

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.

  [jabley@peppermill]% for n in a b c d e f g h i j k l m; do
  > dig @${n}.root-servers.net ns mil. | egrep -qi '^mil.*NS' && \
  for cmdand> echo "${n}.root-servers.net provides a delegation for MIL."
  > done
  a.root-servers.net provides a delegation for MIL.
  b.root-servers.net provides a delegation for MIL.
  c.root-servers.net provides a delegation for MIL.
  d.root-servers.net provides a delegation for MIL.
  e.root-servers.net provides a delegation for MIL.
  f.root-servers.net provides a delegation for MIL.
  g.root-servers.net provides a delegation for MIL.
  h.root-servers.net provides a delegation for MIL.
  i.root-servers.net provides a delegation for MIL.
  j.root-servers.net provides a delegation for MIL.
  k.root-servers.net provides a delegation for MIL.
  l.root-servers.net provides a delegation for MIL.
  m.root-servers.net provides a delegation for MIL.
  [jabley@peppermill]% dig ns mil.

  ; <<>> DiG 8.3 <<>> ns mil.
  ;; res options: init recurs defnam dnsrch
  ;; got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 5
  ;; QUERY SECTION:
  ;; mil, type = NS, class = IN

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

  ;; ADDITIONAL SECTION:
  A.ROOT-SERVERS.NET. 6d23h59m20s IN A 198.41.0.4
  B.ROOT-SERVERS.NET. 6d23h59m20s IN A 128.9.0.107
  E.ROOT-SERVERS.NET. 6d23h59m21s IN A 192.203.230.10
  G.ROOT-SERVERS.NET. 6d23h59m22s IN A 192.112.36.4
  H.ROOT-SERVERS.NET. 6d23h59m22s IN A 128.63.2.53

  ;; Total query time: 93 msec
  ;; FROM: peppermill.automagic.org to SERVER: default -- 204.152.184.68
  ;; WHEN: Wed Aug 21 12:56:09 2002
  ;; MSG SIZE sent: 21 rcvd: 316

[jabley@peppermill]%

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.

All thirteen root servers contain delegations for MIL, and there
are eleven servers which will provide an authoritative response to
a query for SOA (of which five are also root servers).

Joe

Valdis_Kletnieks · August 21, 2002, 8:01pm

The fact that you only see one doesn't mean there's only one. And note
that the .MIL domain perhaps has a vested interest in *NOT* having a fully
redundant view of the world accessible from outside. Sure, it's one point
of failure - but if you're battening down the hatches because of an attack,
it's also a one-stop place to cut yourself off....

Pete_Ehlke · August 21, 2002, 8:04pm

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_Abello1 · August 21, 2002, 8:09pm

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.

>
> 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

Chris_Adams3 · August 21, 2002, 8:12pm

In short: you asked the wrong question.

Once upon a time, Vinny Abello <vinny@tellurian.com> said:

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

You asked for A records. Since a.root-servers.net does not have any A
records, and since it isn't a recursive server, it just gave you the SOA
for mil.

If you ask for NS records (like "dig @a.root-servers.net mil. ns"),
you'll see a different picture.

Bandy_Rush1 · August 21, 2002, 8:19pm

  [jabley@peppermill]% for n in a b c d e f g h i j k l m; do
  > dig @${n}.root-servers.net ns mil. | egrep -qi '^mil.*NS' && \
  for cmdand> echo "${n}.root-servers.net provides a delegation for MIL."
  > done

man doc

randy

Bandy_Rush1 · August 21, 2002, 8:24pm

% 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

Al_Rowland · August 21, 2002, 8:33pm

Perhaps the military has more interest in controlling access than in
making sure John Q. Public is able to reach their sites? There's also
little commercial interest in making sure they're available.

I'm willing to bet the important stuff doesn't rely on DNS anyway.

Just my 2�

Best regards,

Vinny_Abello1 · August 21, 2002, 8:45pm

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.

% 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

Mikael_Abrahamsson · August 21, 2002, 10:09pm

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.

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?

Brad_Knowles · August 21, 2002, 11:14pm

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)
     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)
     Location: Boston, Massachusetts
  Institution: Global Networking and Computing, Inc.

Chris_Adams3 · August 22, 2002, 4:09am

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.).

Dave_Stewart · August 22, 2002, 4:19am

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

Mikael_Abrahamsson · August 22, 2002, 5:19am

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.

Return-Path: <owner-nanog@merit.edu>
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
        by uplift.swm.pp.se (8.11.6/8.9.3) with ESMTP id g7LLDkM25219
        for <swmike@swm.pp.se>; Wed, 21 Aug 2002 23:13:46 +0200
Received: by trapdoor.merit.edu (Postfix)
        id 1EDD29138D; Wed, 21 Aug 2002 17:10:18 -0400 (EDT)
Delivered-To: nanog-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
        id 3A048913BB; Wed, 21 Aug 2002 17:09:25 -0400 (EDT)
Delivered-To: nanog@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
        by trapdoor.merit.edu (Postfix) with ESMTP id 5D91191313
        for <nanog@trapdoor.merit.edu>; Wed, 21 Aug 2002 16:50:00 -0400
(EDT)
Received: by segue.merit.edu (Postfix)
        id 3D8E65DDAF; Wed, 21 Aug 2002 16:50:00 -0400 (EDT)
Delivered-To: nanog@nanog.org
Received: from mx0.inoc.net (mx0.inoc.net [64.246.130.30])
        by segue.merit.edu (Postfix) with ESMTP id 120745DD9F
        for <nanog@nanog.org>; Wed, 21 Aug 2002 16:50:00 -0400 (EDT)
Received: from nimbus (unverified [10.0.0.111]) by mx0.inoc.net
(Vircom SMTPRS 5.3.232) with ESMTP id <B0004784738@mx0.inoc.net>;
Wed, 21 Aug 2002 16:49:59 -0400

Another example:

Return-Path: <owner-nanog@merit.edu>
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
        by uplift.swm.pp.se (8.11.6/8.9.3) with ESMTP id g7LL0AM24539
        for <swmike@swm.pp.se>; Wed, 21 Aug 2002 23:00:11 +0200
Received: by trapdoor.merit.edu (Postfix)
        id 1440191379; Wed, 21 Aug 2002 16:37:29 -0400 (EDT)
Delivered-To: nanog-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
        id 6EB0991384; Wed, 21 Aug 2002 16:32:55 -0400 (EDT)
Delivered-To: nanog@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
        by trapdoor.merit.edu (Postfix) with ESMTP id CC01891378
        for <nanog@trapdoor.merit.edu>; Wed, 21 Aug 2002 16:31:04 -0400
(EDT)
Received: by segue.merit.edu (Postfix)
        id AB8455DDAF; Wed, 21 Aug 2002 16:31:04 -0400 (EDT)
Delivered-To: nanog@nanog.org
Received: from lerlaptop.iadfw.net (lerlaptop.iadfw.net [206.66.13.21])
        by segue.merit.edu (Postfix) with ESMTP id 1D19A5DD9F
        for <nanog@nanog.org>; Wed, 21 Aug 2002 16:31:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
        by lerlaptop.iadfw.net (8.12.5/8.12.5) with ESMTP id
g7LKV0dQ003881;
        Wed, 21 Aug 2002 15:31:00 -0500 (CDT)
        (envelope-from ler@lerctr.org)

Brad_Knowles · August 22, 2002, 9:24pm

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 · August 22, 2002, 9:26pm

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.

Mikael_Abrahamsson · August 23, 2002, 5:21am

> 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.

The cause is overload. There is a definate relation between amount of mail
going thru the list handling system and the delay. When there are a lot of
email being posted the delay is longer. I also notice that you ignored the
20 minute delay within the mailinglist delivery system:

Received: by trapdoor.merit.edu (Postfix)
        id 1EDD29138D; Wed, 21 Aug 2002 17:10:18 -0400 (EDT)
<cut>
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
        by trapdoor.merit.edu (Postfix) with ESMTP id 5D91191313
        for <nanog@trapdoor.merit.edu>; Wed, 21 Aug 2002 16:50:00 -0400

We just don't have enough information to make a determination as
to whose fault this problem is.

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.

All the replies to the .mil email took 10+ minutes to deliver, most of
them 20 minutes, that's why there were so many replies because people just
did not see each others replies. All the answers to the original post were
done within a 30 minute window (the first one 13 minutes after the
original post) so there are quite a few people seeing long delivery times
here.

I am on mailing lists with many hundreds of people at other places and
normal delivery time there is sub-minute. I see no technical reason today
why an important list like nanog-l should reside on a mailing list
platform where 10+ minute delivery time is reached in 20+ % of the cases
and reached immediately when there is any load or moderate usage, and
sub-5-minute delivery is reached in less than 20% of the cases.

Majdi_S_Abbas1 · August 23, 2002, 5:38am

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

Jim_Popovitch2 · August 23, 2002, 6:01am

my $.02...

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

I run a mailinglist with ~750 members and ~25 posts per day. This server is
a 300Mhz Cobalt RaQ3i w/ 256Mb of memory on a 256Kbs pipe (also running
Apache w/ a fairly busy website: flagspot.net). Email turns around in the
<5 minute time frame, and usually a heck of a lot quicker. Attached is a
graph from yesterday showing the number of running Sendmail processes
(green), and the number of emails in mailq (blue). Notice how there are
very few emails that make it into the mailq in time to be polled by MRTG,
most of these involve delivery issues with the remote mailserver
(delays,timeouts,etc.). The trick to speedy turnaround is in the MTA
configuration. 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.

-Jim P.