North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: NetSol screwing the pooch?

  • From: Newell, Tom
  • Date: Fri Apr 14 13:52:04 2000

Eric,

if you would have looked at the NS set for COM (instead of 
the NS set for .), you would have found that authoritive hosts 
for COM are:

com.			6D IN NS	A.ROOT-SERVERS.NET.
com.			6D IN NS	G.ROOT-SERVERS.NET.
com.			6D IN NS	F.GTLD-SERVERS.NET.
com.			6D IN NS	F.ROOT-SERVERS.NET.
com.			6D IN NS	B.ROOT-SERVERS.NET.
com.			6D IN NS	I.ROOT-SERVERS.NET.
com.			6D IN NS	E.ROOT-SERVERS.NET.
com.			6D IN NS	J.GTLD-SERVERS.NET.
com.			6D IN NS	K.GTLD-SERVERS.NET.
com.			6D IN NS	A.GTLD-SERVERS.NET.
com.			6D IN NS	H.GTLD-SERVERS.NET.
com.			6D IN NS	C.GTLD-SERVERS.NET.

 
...and their serials are:


Server                  COM.		Operator	
a.root-servers.net      2000041301	NSI
g.root-servers.net	2000041301	DOD
f.gtld-servers.net	2000041301	NSI
f.root-servers.net	2000041301	ISC
b.root-servers.net      No answer   ISI
i.root-servers.net	2000041301	Sweden (Royal Inst of Tech)
e.root-servers.net	2000041300	NASA
j.gtld-servers.net	2000041301	NSI
k.gtld-servers.net	2000041301	NSI
a.gltd-servers.net	2000041301	NSI
h.gtld-servers.net	2000041301	NSI
c.gtld-servers.net	2000041301	NSI


So in every case where NSI operates the host NS for COM, you
should see that the serialization is correct.  In those cases
where a traditional root server still serves COM, should
they get out of synch, our NOC contacts them to encourage
resolution.  However, as the host is not an NS operated by NSI, 
beyond encouraging them to fix the problem, there is little we 
can do.  This is part of the reason for moving COM off of the
traditional roots in just the same fashion as other first
level delegations are managed today.

Tom



> -----Original Message-----
> From: Eric Germann [mailto:[email protected]]
> Sent: Thursday, April 13, 2000 9:34 PM
> To: [email protected]
> Subject: NetSol screwing the pooch?
> 
> 
> 
> In trying to track down why an old DNS server dies I found 
> the following
> interesting stuff for the [a-i].root-servers.net over a 
> two-hour sample
> period ...
> 
> 
> Server             COM.                    .
> a                  2000041300              2000041300
> b                  no answer               no answer
> c                  no answer               no answer
> d                  answer with ref         2000041300
> e                  2000041300              2000041300
> f                  2000041201              2000041300
> g                  2000041101              2000041101
> h                  answer with ref         2000041101
> i                  2000041300              2000041300
> 
> So I thought the purpose of multiple DNS servers was to have 
> mirroring for
> redundancy.  Does anyone find 1-2 day lags in the updates 
> acceptable?  I'm
> glad NetSol is moving these to commercial grade data centers. :(
> 
> The no answers are pingable but don't answer queries from 
> here (over a two
> hour period).  The answer with ref answered with referrals to other
> servers.  I don't have the patience to recurse the whole mess of
> *.gtld-servers.net.
> 
> Any other observations other than NetSol has apparently 
> screwed the pooch
> again ?
> 
> Eric
> 
> 
> 
> 
> ==============================================================
> ============
>   Eric Germann                                        Inacom 
> Info Systems
>   [email protected]                             Lima, OH 45801
>                                                       Ph:  
> 419 331 9050
>   ICQ:  41927048                                      Fax: 
> 419 331 9302
> 
> "It is so easy to miss pretty trivial solutions to problems deemed
> complicated.  The goal of a scientist is to find an 
> interesting problem,
> and live off it for a while.  The goal of an engineer is to evade
> interesting problems :)"  -- Vadim Antonov <[email protected]> on NANOG
>