Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----

On Mon, 17 Feb 1997 17:35:15 -0600 (CST), karl@mcs.net writes:
>
>We've been running on eDNS now for something like seven months, and have
>had ZERO operational incidents recorded by our NOC which have been related
>to root server failures or problems.

Somehow, I'm not impressed. Say, shouldn't the inability of any AOL customers
to send email to user@domain.audio be considered an operational problem?
And shouldn't "root servers" have recursive queries turned off?:

; <<>> DiG 8.1 <<>> @192.160.127.86 worf.netins.net
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; worf.netins.net, type = A, class = IN

;; ANSWER SECTION:
worf.netins.net. 21h38m10s IN A 167.142.225.4

;; AUTHORITY SECTION:
NETINS.NET. 1d1h56m48s IN NS NS.MCI.NET.
NETINS.NET. 1d1h56m48s IN NS NS2.NETINS.NET.
NETINS.NET. 1d1h56m48s IN NS NS1.NETINS.NET.

;; ADDITIONAL SECTION:
NS.MCI.NET. 9h26m20s IN A 204.70.128.1
NS2.NETINS.NET. 20h24m56s IN A 167.142.225.6
NS1.NETINS.NET. 1d10h22m52s IN A 167.142.225.5

;; Total query time: 5097 msec
;; FROM: vis-admin.dmacc.cc.ia.us to SERVER: 192.160.127.86
;; WHEN: Mon Feb 17 18:51:56 1997
;; MSG SIZE sent: 33 rcvd: 164

And what happens if usage of the eDNS root servers goes up? The eDNS
root servers don't appear to be very well situated network-wise,
either. It looks like all of them are in North America. The IANA has
at least one non-North American root server (i.root-servers.net).

>Give it a shot folks. I know lots of you have political dislikes for the
>eDNS concept and implementation, but if your nameservice is unreliable now,
>having trouble, and you can *FIX IT* for your customers by using eDNS
>instead, isn't finding and using a better mousetrap what your customers
>all pay for you?

Some fix.

>Think about it!


[A copy of the headers and the PGP signature follow.]

Date: Mon, 17 Feb 1997 19:13:56 -0600
From: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us>
In-reply-to: Your message of "Mon, 17 Feb 1997 17:35:15 CST."
<199702172335.RAA19906@Jupiter.Mcs.Net>
Subject: Re: Just got on this thing (perhaps very belatedly) - root server trouble?
To: nanog@merit.edu

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news.

iQCVAwUBMwkCWpwkOQz8sbZFAQFe1AQA303n5zzxPj/Ns/Voe3QyOrMxMD3wpOr6
8s4XPV7RqU00EIjMCRkhE6Sag4/NmonC7hGhyRghyFTTuIzFNGdt0yw1uXFs0U3n
BDNHpyZvFybvWMk3TAr2c5YVXtOHwdWyxXm8LTtXPOUvIOXO1RfkmrLnkuyuIsT+
CVBKYenw0zc=
=tyIh
-----END PGP SIGNATURE-----
--
Jeffrey C. Ollie | Should Work Now (TM)
Python Hacker, Mac Lover |


- - - - - - - - - - - - - - - - -

Karl Denninger writes:
> For what its worth, I haven't seen any. Then again, I don't run here with
> the IANA roots -- I run eDNS.
>
> Perhaps those who are unhappy with the stability of the IANA roots these
> days should try them...

Perhaps those who are unsatisfied with the U.S. government should try
joining the Freemen.

Perry
Speaking for myself and not for the IAHC
- - - - - - - - - - - - - - - - -

In <199702180144.TAA23839@Jupiter.Mcs.Net>,
Karl Denninger <karl@Mcs.Net> wrote:

> > And shouldn't "root servers" have recursive queries turned off?:
>
> Until VERY recently they weren't on the existing roots. And, by the way,
> while we're talking about that, what is this about hosting the 800,000-some-
> odd NSI domains on the roots?

Nice dodge. But you do then admit to having recursion available on
your "new improved r00t n@m3s3rv3rs" for several months, until someone
else pointed it out to you?

"They did the same thing a while back!" isn't an acceptable answer. (I
don't even think it's true. I haven't seen a recursive query answered
via a root nameserver since I started actively doing DNS administration
over a year ago.) Even if that is so, you shouldn't have made the same
mistake, especially *after* the operators of the IANA root servers
corrected the misconfiguration.

> The point at hand, though, is that we haven't had *any* operational incidents
> since eDNS was launched that could be in any way traced to the other root
> servers. None at all.
>
> Meanwhile, there have been several service-affecting issues on the
> IANA-sponsored roots in the same time frame.

I haven't seen any problems because of these supposed "service-affecting
issues". Perhaps you should check the quality of your network connectivity?

> What was that edict again? "Rough consensus and operational code"? We
> certainly do seem to have that.

The code's fine; it just appears you don't know how to configure it correctly.
Try reading the BIND Operations Guide (BOG) next time; it says explicitly
that the root nameservers should run with "options no-recursion".

--
Michael Handler <handler@sub-rosa.com> Washington, D.C.
- - - - - - - - - - - - - - - - -

> BTW, there are 2010-complient roots going in. And, if you secondary root
> from us, you'll get that update automatically when it happens.....

And, if you secondary "." from MCS, you will get data that only a small
fraction of the net sees, and it will conflict with data that large portions
of the net see, and it will conflict with other petty fiefdoms run by other
provincial wannabes who think that THEY and not MCS ought to run/own ".".
- - - - - - - - - - - - - - - - -

On Tuesday, February 18, 1997 12:40 PM, Paul A Vixie[SMTP:paul@vix.com] wrote:
@ > BTW, there are 2010-complient roots going in. And, if you secondary root
@ > from us, you'll get that update automatically when it happens.....
@
@ And, if you secondary "." from MCS, you will get data that only a small
@ fraction of the net sees, and it will conflict with data that large portions
@ of the net see, and it will conflict with other petty fiefdoms run by other
@ provincial wannabes who think that THEY and not MCS ought to run/own ".".
@ -----------------------------------------------------------------------------
@ This is the Newdom mailing list, newdom@vrx.net. To subscribe or
@ unsubscribe or get help , send the word "subscribe" or "unsubscribe" or
@ "help" in the body (not subject) to newdom-request@vrx.net
@
@

Folks, please face the facts. The U.S. Government controls
the Internet. It has always been that way and it will likely always
be that way. It is a resource that many people depend on and
businesses are investing because of the stability, security, and
opportunities that the U.S. Government provides.

If you want to assemble a real "Blue Ribbon Panel" that
represents the real Internet society, I suggest that you start
with some or all of the people below. These are the people who
control the popular Root Name Servers and are the people
mandated by the people to "do the right thing". They are also
some of the people supported by U.S. taxpayers dollars to
make sure that federal government resources such as the
Root Name Servers are used properly according to the laws
in the United States.

We are rapidly approaching March 1, 1997. There will be one
year left on the InterNIC agreements developed by the National
Science Foundation (NSF). Everyone needs to work together
to make sure that those agreements remain stable for one
more year and that plans are made to ensure that any transitions
are smooth and do not impact the stability of the Internet.

The current attempts to fragment the InterNIC are not in
the best interest of the Internet. Instead, the InterNIC should
be kept in tact and used as an educational model to help
create additional "NICs" across the United States to spread
the wealth and jobs around and to ensure better stability
via distributed management.

I have suggested that the NSF use the $12.6 million to
help launch 49 additional NICs, one in each state except for
Virginia. By March of 1998, hopefully enough NICs will be
operational to allow the current InterNIC as we know it to
take its place with the others as a state NIC controlled by
the people of Virginia.

Many people have worked hard over the past couple of years
to demonstrate that cooperating and competing regional NICs
can coexist. The technology is well understood and with the
stewardship of some or all of the people below, I am confident
that the original NSF plan to expand the NICs can be
accomplished by the time the NSF agreements with AT&T
and Network Solutions, Inc. end.

In order to get the regional NICs up to speed, I suggest that
states follow the NSF InterNIC model and "ousource" the
work to regional companies that have demonstrated their
expertise in not only Internet technology but also the emerging
registry industry. I suggest that these companies work with
their state governments to gain support to work with the
elected officials below to get things moving. There is only
one year left. Time is getting short.

Rather than have anyone rush into dismantling the InterNIC
why not join together to clone the InterNIC, not once, but
at least 49 times to help the Internet grow. Once this is
demonstrated, then obviously the lessons learned will
help fuel international growth. No one will be left out.

If other countries want to join in this effort, I suggest that
they follow a similar plan. Think global but start local. It
is the only way that you will make any real progress. I am
sure that many people in the U.S. will be glad to lend a
hand to get things moving. Hopefully, there will be many
examples and more educational programs developed as
these efforts unfold.

There is no reason why anyone should be left out but
there is also no reason why people should hold back
waiting for people to catch up. With the clock ticking
and $12.6 million in the bank, it is time to duplicate
the prototype in Virginia in every state and each country.

It is not time to dismantle the prototype. If that occurs
then much of the knowledge will be lost and the money
the U.S. taxpayers spent to build the InterNIC will be
wasted. Again, the following people have the mandate
of the people to make sure that money and the efforts
are not wasted. They work daily to maximize the return
on the taxpayer's investment. Let them know that you
want to work with them to make sure you also benefit


from those efforts in your states and countries.

Thank you for your time...

@@@@@@@@@@@@@@@@@@@@@@@@

President Bill Clinton and Vice President Al Gore
http://www.whitehouse.gov

National Science Board (NSB)
http://www.nsf.gov/nsb/nsb.htm
The NSB has dual responsibilities as:
. National science policy advisor to the President
and the Congress
. Governing body for the National Science Foundation

Chairman NSB - Dr. Richard N. Zare, Stanford University
rnz@chemistry.stanford.edu
http://www-leland.stanford.edu/group/Zarelab/

Office of Inspector General of the NSF (also links to Congress)
http://www.nsf.gov/oig/oig.htm
Inspector General - Linda G. Sundro - lsundro@nsf.gov
Investigator - Clara Kuehn - ckuehn@nsf.gov

National Science Foundation
Neal Lane - nlane@nsf.gov
<http://www.nsf.gov/od/lpa/forum/lane/quscipol.htm>
Juris Hartmanis - jhartman@nsf.gov
<http://www.cise.nsf.gov/oad/jhartman.html>
George Strawn - gstrawn@nsf.gov
<http://www.cise.nsf.gov/ncri/Georgehome.html>
Don Mitchell - dmitchel@nsf.gov
<http://www.cise.nsf.gov/ncri/Donhome.html>

=====

@@@@@ http://www.fnc.gov/mission.html

"The FNC supports the goals of the CIC, particularly those related
to building the national information infrastructure (NII). It also seeks
to address Federal technology transition goals and allow the
operational experiences of FNC agencies to influence future
Federal research agendas.

It also contributes funds to important Internet infrastructure organizations,
such as
the Internet Engineering Task Force (IETF),
Internet Assigned Number Authority (IANA),
and the Computer Emergency Response Team (CERT)."

@@@@@ http://www.fnc.gov/FNC_Members.html

Federal Networking Council

George Strawn - Chairman GSTRAWN@NSF.GOV
Walter Wiebe - Executive Director WWIEBE@NSF.GOV
Bruce Almich ALMICH.BRUCE@EPAMAIL.EPA.GOV
Bruce Bottomley BBB@ROMULUS.NCSC.MIL
Dick desJardins DESJARDI@EOS.NASA.GOV
Frank Hartel HARTEL@BOX-H.NIH.GOV
Craig Hunt CHUNT@NIST.GOV
Pamela G. Kruzic PJK@NRC.GOV
Henry Lai HENRY.LAI@GSA.GOV
Fred Lee FLEE@NSF.GOV
Fred Long FLONG@SUN1.WWB.NOAA.GOV
Hilarie Orman HORMAN@DARPA.MIL
Camillo J. Pasquariello PASQUARC@NCR.DISA.MIL
Alexis Poliakoff ALEX_POLIAKOFF@ED.GOV
Ken Roko KROKO@USAID.GOV
Elaine Stout ESTOUT@USGS.GOV

@@@@@ http://www.fnc.gov/FNCAC.html

The Federal Networking Council Advisory Committee (FNCAC) is chartered by
the National Science Foundation to provide the FNC with technical, tactical,
and strategic advice from the constituencies involved in the NREN Program..."

FNCAC Members

Dr. Sidney Karin KARIN@SDSC.EDU
Dr. George Brandenburg BRANDENBURG@HUHEPL.HARVARD.EDU
Dr. Henriette Avram AVRAM@IVORY.EDUCOM.EDU
Mr. Jim Beall, Jr. BEALL@VNET.IBM.COM
Mr. Alan Blatecky ALANB@MCNC.ORG
Mr. Matt Blaze MAB@RESEARCH.ATT.COM
Ms. Susan Estrada SESTRADA@ALDEA.COM
Dr. Kenneth S. Flamm FLAMM@BROOK.EDU
Dr. John Gage JOHN.GAGE@ENG.SUN.COM
Ms. Carol Henderson CCH@ALAWASH.ORG
Dr. Kenneth J. Klingenstein KJK@SPOT.COLORADO.EDU
Mr. Richard Liebhaber 2714743@MCIMAIL.COM
Mr. Stu Loken SCLOKEN@LBL.GOV
Dr. Paul Mockapetris PVM@SOFTWARE.COM
Mr. Robert G. Moskowitz RGM3@IS.CHRYSLER.COM
Dr. Ike Nassi NASSI@SCRUZNET.COM
Mr. Carl Edward Oliver OLIVERCE@ORNL.GOV
Dr. Stewart Personick SDP@BELLCORE.COM
Mr. Thomas C. Rindfleisch THOMAS_RINDFLEISCH@MEDMAIL.STANFORD.EDU.
Mr. Mike Roberts ROBERTS@EDUCOM.EDU
Ms. Connie D. Stout CSTOUT@TENET.EDU
Brigadier General Harold Thompson THOMPSON@ICN.STATE.IA.US
Dr. Stephen Wolff SWOLFF@CISCO.COM

@@@@@


U.S. Senate e-mail addresses

Alabama - Shelby, Richard C. (R) - senator@shelby.senate.gov
Alaska - Stevens, Ted (R) - senator_stevens@stevens.senate.gov
Arizona - Kyl, Jon (R) - info@kyl.senate.gov
Arizona - McCain, John (R) - senator_mccain@mccain.senate.gov
Arkansas - Bumpers, Dale (D) - senator@bumpers.senate.gov
Arkansas - Hutchinson, Tim (D) - senator.hutchinson@hutchinson.senate.gov
California - Boxer, Barbara (D) - senator@boxer.senate.gov
California - Feinstein, Dianne (D) - senator@feinstein.senate.gov
Connecticut - Dodd, Christopher J. (D) - sen_dodd@dodd.senate.gov
Connecticut - Lieberman, Joseph I. (D) - senator_lieberman@lieberman.senate.gov
Delaware - Biden, Joseph R., Jr. (D) - senator@biden.senate.gov
Florida - Graham, Bob (D) - bob_graham@graham.senate.gov
Georgia - Coverdell, Paul (R) - senator_coverdell@coverdell.senate.gov
Hawaii - Inouye, Daniel K. (D) - senator@inouye.senate.gov
Idaho - Craig, Larry E. (R) - larry_craig@craig.senate.gov
Idaho - Kempthorne, Dirk (R) - dirk_kempthorne@kempthorne.senate.gov
Illinois - Moseley-Braun, Carol (D) - senator@moseley-braun.senate.gov
Iowa - Grassley, Chuck (R) - chuck_grassley@grassley.senate.gov
Iowa - Harkin, Tom (D) - tom_harkin@harkin.senate.gov
Kansas - Brownback, Sam (R) - sam_brownback@brownback.senate.gov
Kentucky - Ford, Wendell H. (D) - wendell_ford@ford.senate.gov
Kentucky - McConnell, Mitch (R) - senator@mcconnell.senate.gov
Louisiana - Breaux, John B. (D) - senator@breaux.senate.gov
Maine - Collins, Susan (R) - senator@collins.senate.gov
Maine - Snowe, Olympia J. (R) - olympia@snowe.senate.gov
Maryland - Mikulski, Barbara A. (D) - senator@mikulski.senate.gov
Maryland - Sarbanes, Paul S. (D) - senator@sarbanes.senate.gov
Massachusetts - Kennedy, Edward M. (D) - senator@kennedy.senate.gov
Massachusetts - Kerry, John F. (D) - john_kerry@kerry.senate.gov
Michigan - Abraham, Spencer (R) - michigan@abraham.senate.gov
Michigan - Levin, Carl (D) senator@levin.senate.gov
Minnesota - Grams, Rod (R) - mail_grams@grams.senate.gov
Minnesota - Wellstone, Paul D. (D) - senator@wellstone.senate.gov
Mississippi - Cochran, Thad (R) - senator@cochran.senate.gov
Missouri - Ashcroft, John (R) - john_ashcroft@ashcroft.senate.gov
Missouri - Bond, Christopher S. (R) - kit_bond@bond.senate.gov
Montana - Baucus, Max (D) - max@baucus.senate.gov
Montana - Burns, Conrad R. (R) - conrad_burns@burns.senate.gov
Nebraska - Kerrey, J. Robert (D) - bob@kerrey.senate.gov
Nevada - Bryan, Richard H. (D) - senator@bryan.senate.gov
Nevada - Reid, Harry (D) - senator_reid@reid.senate.gov
New Hampshire - Gregg, Judd (R) - mailbox@gregg.senate.gov
New Hampshire - Smith, Bob (R) opinion@smith.senate.gov
New Jersey - Lautenberg, Frank R. (D) - frank_lautenberg@lautenberg.senate.gov
New Mexico - Bingaman, Jeff (D) - senator_bingaman@bingaman.senate.gov
New Mexico - Domenici, Pete V. (R) - senator_domenici@domenici.senate.gov
New York - D'Amato, Alfonse M. (R) - senator_al@damato.senate.gov
New York - Moynihan, Daniel Patrick (D) - senator@dpm.senate.gov
North Carolina - Faircloth, Lauch (R) - senator@faircloth.senate.gov
North Carolina - Helms, Jesse (R) - jesse_helms@helms.senate.gov
North Dakota - Dorgan, Byron L. (D) - senator@dorgan.senate.gov
Ohio - DeWine, Mike (R) - senator_dewine@dewine.senate.gov
Oklahoma - Nickles, Don (R) - senator@nickles.senate.gov
Oregon - Wyden, Ron (D) - senator@wyden.senate.gov
Pennsylvania - Santorum, Rick (R) - senator@santorum.senate.gov
Pennsylvania - Specter, Arlen (R) - senator_specter@specter.senate.gov
Rhode Island - Chafee, John H. (R) - senator_chafee@chafee.senate.gov
South Carolina - Hollings, Ernest F. (D) - senator@hollings.senate.gov
South Carolina - Thurmond, Strom (R) - senator@thurmond.senate.gov
South Dakota - Daschle, Thomas A. (D) - tom_daschle@daschle.senate.gov
Tennessee - Frist, William H. (R) - senator_frist@frist.senate.gov
Tennessee - Thompson, Fred (R) - senator_thompson@thompson.senate.gov
Texas - Hutchison, Kay Bailey (R) - senator@hutchison.senate.gov
Utah - Bennett, Robert F. (R) - senator@bennett.senate.gov
Utah - Hatch, Orrin G. (R) - senator_hatch@hatch.senate.gov
Vermont - Jeffords, James M. (R) - vermont@jeffords.senate.gov
Vermont - Leahy, Patrick J. (D) - senator_leahy@leahy.senate.gov
Virginia - Robb, Charles S. (D) senator@robb.senate.gov
Virginia - Warner, John W. (R) - senator@warner.senate.gov
Washington - Gorton, Slade (R) - senator_gorton@gorton.senate.gov
Washington - Murray, Patty (D) - senator_murray@murray.senate.gov
West Virginia - Byrd, Robert C. (D) - senator_byrd@byrd.senate.gov
West Virginia - Rockefeller, John D., IV (D) - senator@rockefeller.senate.gov
Wisconsin - Feingold, Russell D. (D) - senator@feingold.senate.gov
Wisconsin - Kohl, Herb (D) - nator_kohl@kohl.senate.gov
Wyoming - Enzi, Mike (R) - senator@enzi.senate.gov
Wyoming - Thomas, Craig (R) - craig@thomas.senate.gov

@@@@@@@@@@@@@@@@@

U.S. GOVERNMENT (NSF, etc.)
Contact:
Dr. George Strawn
Division Director
Division of Networking and Communication
Research and Infrastructure
National Science Foundation
4201 Wilson Boulevard, Room 1175
Arlington, VA 22230
Phone: (703) 306-1950
Fax: (703) 306-0621
Email: gstrawn@nsf.gov
http://www.cise.nsf.gov/ncri/Georgehome.html

NS.INTERNIC.NET 198.41.0.4
Network Solutions, Inc. (NS45-HST)

AOS.ARL.ARMY.MIL 128.63.2.53
Army Research Laboratory (BRL-AOS)

NS.NASA.GOV 192.203.230.10
Moffett Field (NS-NASA)

NS.NIC.DDN.MIL 192.112.36.4
GSI (DIIS-NS)

STATE UNIVERSITIES

NS1.ISI.EDU 128.9.0.107
University of Southern California (ISI2)
Contact:
Dr. Stephen B. Sample
President
ADM 110
University of Southern California
University Park, mc-0012
Los Angeles, CA 90089-0012
(213) 740-2111
http://www.usc.edu/cgi-bin/uscinfo/directory-2?STAF+6630
http://www.usc.edu/People/snailmail.html

TERP.UMD.EDU 128.8.10.90
University of Maryland (UMD-TERP)
Contact:
Dr. William E. Kirwan
President, University of Maryland at College Park
<http://www.inform.umd.edu:8080/CampusInfo/Departments/PRES/>
<http://inform.umd.edu/kirwan-biography.html>
Legal Affairs
Dr. J. Terrance Roach <mailto: troach@deans.umd.edu>

U.S. PRIVATE INDUSTRY & INDIVIDUALS

C.PSI.NET 192.33.4.12
Performance Systems International Inc. (C-NYSER)
Contact:
PSINet, Inc (PSI-NET-DOM)
510 Huntmar Park Drive
Herndon, VA 22070
USA

NS.ISC.ORG 192.5.5.241
Internet Software Consortium (ISC)
Contact:
Internet Software Consortium (ISC2-DOM)
c/o UUNET Communications Services
3110 Fairview Park Drive
Suite 570
Falls Church, VA 22042
Domain Name: ISC.ORG

SWEDEN
Contact: (See below)

NIC.NORDU.NET 192.36.148.17
[No name] (NORDU)


@@@@@@


SERVER NS.ISC.ORG 192.5.5.241
Internet Software Consortium (ISC)

Hostname: F.ROOT-SERVERS.NET
Address: 192.5.5.241
System: DEC ALPHA running BIND 4.9.5

Host Administrator:
Vixie, Paul (PV15) paul@VIX.COM
+1 415 747 0204

Domain Server

Record last updated on 09-Oct-96.


-------
SERVER NS.INTERNIC.NET 198.41.0.4
Network Solutions, Inc. (NS45-HST)
505 Huntmar Park Drive
Herndon, VA 22070

Hostname: A.ROOT-SERVERS.NET
Address: 198.41.0.4
System: SUN running SUNOS

Host Administrator:
Kosters, Mark A. (MAK21) markk@NETSOL.COM
(703) 742-4795 (FAX) (703) 742-4811

Record last updated on 31-Aug-95.


-------
SERVER NS1.ISI.EDU 128.9.0.107
University of Southern California (ISI2)
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Hostname: B.ROOT-SERVERS.NET
Address: 128.9.0.107
System: ? running ?

Host Administrator:
Koda, Jim (JK7) koda@ISI.EDU
310) 822-1511

Record last updated on 12-Aug-95.


-------
SERVER TERP.UMD.EDU 128.8.10.90
University of Maryland (UMD-TERP)
Computer Science Center
College Park, MD 20742

Hostname: D.ROOT-SERVERS.NET
Address: 128.8.10.90
System: MICROVAX-II running UNIX

Coordinator:
Sneeringer, Gerry (GS307) sneeri@NI.UMD.EDU
(301) 405-2996

domain server

Record last updated on 12-Aug-95.


-------
SERVER AOS.ARL.ARMY.MIL 128.63.2.53
Army Research Laboratory (BRL-AOS)
Aberdeen Proving Ground, MD 21005-5066

Hostname: H.ROOT-SERVERS.NET
Address: 128.63.2.53
System: SUN running UNIX

Host Administrator:
Fielding, James L. (JLF) jamesf@ARL.MIL
(410)278-8929 (DSN) 298-8929 (410)278-6664 (FAX) (410)278-5077

domain server

Record last updated on 17-Aug-95.


-------
SERVER C.PSI.NET 192.33.4.12
Performance Systems International Inc. (C-NYSER)

Hostname: C.ROOT-SERVERS.NET
Address: 192.33.4.12
System: SUN running UNIX

Coordinator:
Administration, PSINet Domain (PDA4) psinet-domain-admin@PSI.COM
(703) 904-4100

domain server

Record last updated on 17-Apr-96.


-------
SERVER NIC.NORDU.NET 192.36.148.17
[No name] (NORDU)

Hostname: I.ROOT-SERVERS.NET
Address: 192.36.148.17
System: SUN-4/60 running UNIX

Coordinator:
Rendahl, Matti [President] (MR164) matti@COMEDIA.SE
+46 8 612 49 26 +46 70 533 13 56 (FAX) +46 8 612 49 36

Record last updated on 24-Aug-95.


-------
SERVER NS.NASA.GOV 192.203.230.10
Moffett Field (NS-NASA)
NASA Ames Research Center, Mail Stop 233-8
Moffett Field, CA 94035-1000
USA

Hostname: E.ROOT-SERVERS.NET
Address: 192.203.230.10
System: SUN running SUNOS

Host Administrator, Coordinator:
Schlapfer, Marcel (MS4039) marcel@NSIPO.NASA.GOV
1-415-604-0955 (FAX) 1-415-604-0036

domain server

Record last updated on 25-Oct-96.


-------
SERVER NS.NIC.DDN.MIL 192.112.36.4
GSI (DIIS-NS)
Suite 200
14200 Park Meadow Dr.
Chantilly, VA 22021

Hostname: G.ROOT-SERVERS.NET
Address: 192.112.36.4
System: SUN running UNIX

Coordinator:
McCollum, Robert W. (RM584) bobm@NIC.DDN.MIL
(703) 802-8476 (FAX) (703) 802-8376

Root Domain Server

Record last updated on 18-Aug-95.


-------


--
Jim Fleming
Unir Corporation

e-mail:
JimFleming@unety.net
JimFleming@unety.s0.g0 (EDNS/IPv8)

- - - - - - - - - - - - - - - - -

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 18 Feb 1997 13:01:06 -0600 (CST), karl@mcs.net writes:
>
>In fact, our solution has you *SECONDARYING* ".", which means that in
>general, other than the requirement for you to be able to reach a source for
>that file on a every-few-days basis (to check the SOA record) you no longer
>NEED connectivity to the root domain.
>
>This is demonstrably superior; you no longer need to make that query for
>".", as you already know who is authoritative for all the TLDs under ".".

Yiiii... Having everyone secondary "." sounds demonstrably inferior to
me. Just think what would happen if every nameserver that is
authoritative for a .com domain started secondarying ".". There are
approximately 50,000 name servers that are authoritative for .com
(according to the .com zone file from the InterNIC). That would mean
that the system ROOT-NS.MCS.NET would waste around 5 queries per
second because those 50,000 name servers would be trying to check the
SOA (at the time that I write this, the eDNS servers list a 3 *hour*
refresh interval for the root zone with a 15 *minute* retry
interval). Just think what will happen to poor ROOT-NS.MCS.NET when
the serial number changes!

With system currently in use, those 50,000 name servers would generate
around 6 queries per second as those name servers refresh their list
of root name servers - and those queries would be distributed fairly
evenly among all of the root servers.

And to top it all off, there are probably at least 2-3 times as many
name servers that are not authoritative for a .com domain. Boy, that
ROOT-NS.MCS.NET must be one huge piece of iron...

Hmmm... under your scheme, every name server would have authoritative
information for the root zone. So, really, the other eDNS root servers
are pointless, since they will never be contacted. That leaves
ROOT-NS.MCS.NET as a *single point of failure*. Plus, think of the
hassles when it's decided that the IP address of ROOT-NS.MCS.NET needs
to change.


[A copy of the headers and the PGP signature follow.]

Date: Tue, 18 Feb 1997 15:09:08 -0600
From: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us>
In-reply-to: Your message of "Tue, 18 Feb 1997 13:01:06 CST."
<199702181901.NAA06278@Jupiter.Mcs.Net>
Subject: Re: Just got on this thing (perhaps very belatedly) - root server trouble?
To: nanog@merit.edu

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news.

iQCVAwUBMwoafJwkOQz8sbZFAQELTwQAvwU0Ikj7s1kwUU6gqutWjsAOQQZy9WbU
qI/Xlyjh9S0ZGqf9RA/q9OaJkXjy2vweQ+y3JLbyrw5EL3Cbk302YmVEOX4CbUJF
nkfWNWrwK8mTvRuPamnB75YIHemEET8wxPueChxRY+7u7SRldTqLdeRaFfJuIFzL
noNEfUH7l5A=
=Q/l5
-----END PGP SIGNATURE-----
--
Jeffrey C. Ollie | Should Work Now (TM)
Python Hacker, Mac Lover |
- - - - - - - - - - - - - - - - -

What is your point? IMHO it's far better for NSI to accept the
applications without working SOA. Otherwise you lock people into paying
ISPs to hold domains for them. While that might give you business,
it's not something that NSI should enforce, or should have to enforce.

Furthermore, the NSI registration system has become FAR more reliable
since the removal of that check. In order to ensure that SOAs are
always available they would have to continually check all the zones.
I personally do not trust anyone, not you, not NSI, not even myself to
do that without dropping zones accidentally now and then. Why introduce
those problems into the system when it works just fine without them?

Furthermore, when I ran a similar survey four months ago things didn't
seem nearly this bad. Although I was only taking the com.zone NS records
and querying them for "nic." NS records. I was happy to see that less
than 1% of them were corrupted by a bogus "nic." tld.

Dean

On Tue, 18 Feb 1997, Karl Denninger wrote:

> > There are
> > approximately 50,000 name servers that are authoritative for .com
> > (according to the .com zone file from the InterNIC).
>
> No. There are approximately 50,000 unique nameserver hostnames. At least
> 1/3rd of these, according to the survey I'm running right now, are completely
> bogus and simply don't exist.
>
> The survey that I'm running to study penetration of the eDNS roots gives
> a best guess of the ACTUAL .COM domains which are resolvable to be somewhere
> between 30% and 60% of the zones listed.
>
> We're about 10% of the way through the list right now (started early this
> morning) so what I have at this point has statistical significance.
>
> You hear that right folks. About 30% of the nameservers which supposedly
> are authoritative for .COM domains are either:
> 1) Non-existant (they don't resolve to an IP address)
> 2) Unreachable
> or 3) Don't know what "." is (!)
>
> Now, if it turns out that the number of so-called delegations which aren't
> really backed by authority records is also 30% of the listing, then that
> means that of the 790,000+ domains in the COM zone, only about 265,000 are
> "real", in that they have both a nameserver online AND a proper authority
> record on that nameserver.
>
> This is a direct result of NSI accepting applications for domains, and
> listing them, without checking for authoritative SOA records before issuing
> the records in the COM zone!
>
> I'm apalled at these numbers. In general, DNS is so broken and polluted
> right now that anyone who wants to take cheap shots at the eDNS system had
> better clean up their own yard first.
>
> The huge majority of eDNS registrars verify SOA and authority records before
> allowing the zone to issue. I know that we do here, and I was shocked at
> the number of bogus registrations that I had seen over the last few months.
>
> Now that I've actually studied the existing .COM zone, I'm no longer
> astonished. What blows me away is the apparent fact that this large of a
> percentage of the data out there is absolute trash, and nobody has cleaned
> up the yard.
>
> BTW, "entropy" doesn't explain this. 7 out of 8 registrations in COM are
> less than 18 months old according to NSI.
>
> --
> --
> Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity
> http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
> | 99 Analog numbers, 77 ISDN, Web servers $75/mo
> Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/
> Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
>

- - - - - - - - - - - - - - - - -

> You hear that right folks. About 30% of the nameservers which supposedly
> are authoritative for .COM domains are either:
> 1) Non-existant (they don't resolve to an IP address)
> 2) Unreachable
> or 3) Don't know what "." is (!)
>
> Now, if it turns out that the number of so-called delegations which aren't
> really backed by authority records is also 30% of the listing, then that
> means that of the 790,000+ domains in the COM zone, only about 265,000 are
> "real", in that they have both a nameserver online AND a proper authority
> record on that nameserver.
>
> This is a direct result of NSI accepting applications for domains, and
> listing them, without checking for authoritative SOA records before issuing
> the records in the COM zone!
>
> I'm apalled at these numbers.

For once we agree. NSI should have stopped this practice long ago. You'll
be pleased to hear that there are other name registries (for instance the
one serving the "no" (Norway) TLD that actually perform this check.

Note that checking when an application is received isn't really enough.
In Norway we run regular (monthly) checks of all the second-level domains
under "no", and we always find a number of name servers which have ceased
being authoritative in the time since last check.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
- - - - - - - - - - - - - - - - -

On Tuesday, February 18, 1997 3:09 PM, Jeffrey C. Ollie[SMTP:jeff@ollie.clive.ia.us] wrote:
@ -----BEGIN PGP SIGNED MESSAGE-----
@
@ On Tue, 18 Feb 1997 13:01:06 -0600 (CST), karl@mcs.net writes:
@ >
@ >In fact, our solution has you *SECONDARYING* ".", which means that in
@ >general, other than the requirement for you to be able to reach a source for
@ >that file on a every-few-days basis (to check the SOA record) you no longer
@ >NEED connectivity to the root domain.
@ >
@ >This is demonstrably superior; you no longer need to make that query for
@ >".", as you already know who is authoritative for all the TLDs under ".".
@
@ Yiiii... Having everyone secondary "." sounds demonstrably inferior to
@ me. Just think what would happen if every nameserver that is
@ authoritative for a .com domain started secondarying ".". There are
@ approximately 50,000 name servers that are authoritative for .com
@ (according to the .com zone file from the InterNIC). That would mean
@ that the system ROOT-NS.MCS.NET would waste around 5 queries per
@ second because those 50,000 name servers would be trying to check the
@ SOA (at the time that I write this, the eDNS servers list a 3 *hour*
@ refresh interval for the root zone with a 15 *minute* retry
@ interval). Just think what will happen to poor ROOT-NS.MCS.NET when
@ the serial number changes!
@

There are really two approaches being used. Actually three
if you include the current InterNIC approach of allowing
some TLDs (like .COM, .NET, etc.) to be served from the
Root Name Server.

The two approaches could be called:

1. Secondarying
2. TRUE Root

In both approaches you might want to keep in mind that
the objective is to create a Root Name Server (i.e. a
server for servers) as opposed to a standard ISP Name
Server or a TLD Name Server that might be found in
a TLD registry operation.

In the first approach, Secondarying, a Root Name Server
is created by taking a rather standard ISP Name Server
and pulling in (via the secodarying of ".") a rather static
base of information about the location of the TLD Name
Servers.

There are several benefits to this approach:
1. People can easily reconfigure an existing
server to do this as well as other name
services.
2. The zone transfer features can be used to
make the update of "." easy from some
central coordinator.
3. As Karl has pointed out, you mostly run with
better performance because you have pulled
a view of the entire TLD world in and periodically
get it updated.

The disadvantages are mostly philosophical in that
this type of Root Name Server can end up being a
jack of all trades and a master of too much or none
depending on how you view it. Keep in mind that as
a Root Name Server it still can be used to serve
ISP Name Servers which was the objective.

The second approach (TRUE Root) takes a purists
view of a Root Name Server and only TLD Name
Server referral information is hosted on the machine.
Queries that make their way to this type of server are
easily handled. A query about a .COM domain name
is answered with only information on where the .COM
TLD Name Servers can be found.

There are several benefits to this approach:
1. The software for this type of name server is
trivial and can be made to be very
efficient. The role of this server is
very bounded and therefore cumbersome
"named" software with years of whistles
and bells is not required. We have
written two versions of "named" for
such a server and each took little effort.
One is in Perl and the other is in C.
The flag-ship version will of course
be in C+@.
2. The administration and operations can be
made to be more robust again because
the server plays a limited role and
therefore there is no way that an
administrator can turn this type of
server into a complex multi-role
server as seen today on the legacy
Root Name Servers.
3. This type of server can be easily scaled and
generally has very little load because
it serves ISP Name Servers and they
rarely need to relocate the high runner
TLD Name Servers that do not move
that often, especially .COM, .NET, etc.

The major disadvantage of this type of server is
the added cost and the fact that it makes the most
sense isolated on a bullet-proof machine. Many ISPs
do not have the luxury of having spare machines to
throw at such problems as an experiment. The
InterNIC of course just deployed 4 such machines
but they have $8,000,000 per month in domain
registrations to help pay for gear.

In my opinion, it is good for NANOG members to
understand all of the ins and out of the DNS and
the various ways to configure name servers. It is
not productive for people to continue to tell people
that only certain individuals can understand what
really amounts to a protocol and a data base and
some rather trivial software to make it all work.

I hope these notes help NANOG members as
well as other people experimenting with the
AlterNIC, Root 64, Root 128, or even the new
IANA TRUE Root Name Servers....:-)

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming@unety.net
JimFleming@unety.s0.g0 (EDNS/IPv8)

- - - - - - - - - - - - - - - - -

From: Karl Denninger <karl@Mcs.Net>
Date: Tue, 18 Feb 1997 15:29:33 -0600 (CST)
> About 30% of the nameservers which supposedly
> are authoritative for .COM domains are either:
> 1) Non-existant (they don't resolve to an IP address)
> 2) Unreachable
> or 3) Don't know what "." is (!)

This might say more about the status of Internet reachability at a
particular point time and/or from a particular place in the Internet.

This exercise doesn't seem like particularly good science...

-tjs
- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Karl Denninger wrote:

[...]
> We're now well into the "C"s, and so far 32% of the NS lines in the TLD
> list for COM file fail one of these four tests!
>
> This is pretty clearly unacceptable, and far worse than I had ever
> imagined it was.

So does the fact that there are lots of unused-yet-allocated domains
in .com have any negative impact on you or anyone else?
--
Matt Ranney - mjr@ranney.com

This is how I sign all my messages.

- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Karl Denninger wrote:

[...]
> What do you think happens to the nameservers on the net when they're asked
> for a domain that doesn't have functional servers, and they sit and churn
> trying to resolve the names?
>
> BTW, churn is the right word. Its taking anywhere from 5-10 *seconds* to
> come back as NXDOMAIN on each request for those that fail to resolve, and
> this is from the IANA roots.

So aside from programs like yours, who ever asks for domains that
aren't in use?

> This IS a functional problem - and worse, all those non-existant zones and
> the VM churn they generate on the COM TLD servers is probably the REASON
> that we're looking at this kind of horrid performance!

Thats fair, I guess. Perhaps some of those $100 in fees for unused
domains could be used to buy more RAM for root server operators.
--
Matt Ranney - mjr@ranney.com

This is how I sign all my messages.

- - - - - - - - - - - - - - - - -

On Tue, 18 Feb 1997, Matt Ranney wrote:

> > BTW, churn is the right word. Its taking anywhere from 5-10 *seconds* to
> > come back as NXDOMAIN on each request for those that fail to resolve, and
> > this is from the IANA roots.
>
> So aside from programs like yours, who ever asks for domains that
> aren't in use?

Plenty of folks do, some gomer registers a domain, doesn't tell his upstream
about it, doesn't do DNS for it, but hands out an email address of
joe@my.*&^ed.domain.com, they try and email him.. you get the picture. Day
after day we see dozens of lame delegation errors. Very often for the same
domains time and time again. I don't usually agree with Karl but in this
case he's right.

> > This IS a functional problem - and worse, all those non-existant zones and
> > the VM churn they generate on the COM TLD servers is probably the REASON
> > that we're looking at this kind of horrid performance!
>
> Thats fair, I guess. Perhaps some of those $100 in fees for unused
> domains could be used to buy more RAM for root server operators.

Or better yet, to teach the idiots at NSI how to maintain a database.


[-] Brett L. Hawn (blh @ nol dot net) [-]
[-] Networks On-Line - Houston, Texas [-]
[-] 713-467-7100 [-]

- - - - - - - - - - - - - - - - -

At 5:23 PM 2/18/97, Karl Denninger wrote:

[...]
>What do you think happens to the nameservers on the net when they're asked
>for a domain that doesn't have functional servers, and they sit and churn
>trying to resolve the names?
>
>BTW, churn is the right word. Its taking anywhere from 5-10 *seconds* to
>come back as NXDOMAIN on each request for those that fail to resolve, and
>this is from the IANA roots.
>
>This IS a functional problem - and worse, all those non-existant zones and
>the VM churn they generate on the COM TLD servers is probably the REASON
>that we're looking at this kind of horrid performance!

Churn shmurn. Those domains are probably ones that have been paid for (to
the InterNIC), but aren't yet being used. Who's accessing those unused
domains and doing all this needless churning? We should find 'em and
string 'em up.

Seems like most of the churning would be caused by spammers and testers
like yourself.

I'd be interested in seeing actual machine statistics on how much
performance degredation can be attributed to lack of responses. Without
those statistics, I can't see how the InterNIC fees aren't covering this
scenario.

As was mentioned before, you shouldn't have to pay an ISP to have a domain
name reserved.

Chris Russo



------------------------------------------------------------------
A-Link Network Services (408) 720-6161
http://www.alink.net This space for rent.
------------------------------------------------------------------


- - - - - - - - - - - - - - - - -