Mailing List Archive

Nick Hilliard <nick@eunet.ie> wrote:

> How about allocating some "good sounding" IP addresses for them,
> (like 1.0.0.x/32) and hard-wiring them into resolver code? Would
> save quite a lot of configuration headaches for newbies.

>Hardwiring anything like this into a system like DNS sounds like a really
>bad idea if only for the simple reason that DNS is not just used on the
>Internet, but also within private networks. Having hardwiring IP numbers in
>this case would cause headaches of unimaginable proportions.

Er. This is _root zone_. You either have access to it, or not.
Those are completely separated name spaces. If you have an intranet
you may want to have internal routes for local roots. A *lot* less
headache when all namseservers on all machines work out-of-box without
system administrator running in circles changing addresses.

Anyway, i would rather have an override for root NS addresses, instead of
required configuration. How many root caches out there are configured with all
correct addresses? My estimate is below 20%.

--vadim

PS. Thanks to those who pointed that it is not resolver but rather cacheing NS.
- - - - - - - - - - - - - - - - -

> > How about allocating some "good sounding" IP addresses for them,
> > (like 1.0.0.x/32) and hard-wiring them into resolver code? Would
> > save quite a lot of configuration headaches for newbies.
>
> Hardwiring anything like this into a system like DNS sounds like a really
> bad idea if only for the simple reason that DNS is not just used on the
> Internet, but also within private networks. Having hardwiring IP numbers
> in this case would cause headaches of unimaginable proportions.

It's DNS servers, not resolvers, that need to update their lists
of Internet root servers. The problem (IMHO) is that few sites know
or care that they have to maintain root server list periodically to
stay in sync with the rest of the Internet. One way to attack the
problem (not solve it) is to require nameserver vendors (IIS, Apple,
BIND, etc.) to provide the capability for periodic root server list
updates.

In Unix (BIND), it's quite easy:

In cron:

# pick a random time once a week
31 10 * * 4 /usr/sbin/update-root
# some other time during the week
23 20 * * 6 /usr/sbin/named.restart

The shell script (off the top of my head):

#!/bin/sh
tmp=/tmp/rs$$
trap "rm -f $tmp" 1 2 3 14 15
chdir /etc/namedb
ncftp -a -d 600 -g 5 ftp.root-servers.net:/named.root
if [ ! -r named.root ]; then
Mail -s "Could not get root nameserver list" hostmaster
fi
diff root.cache root-servers > $tmp
if [ -s $tmp ]; then
mv named.root root.cache # fails if couldn't download
Mail -s "Root server update" hostmaster < $tmp
fi
rm -f $tmp

Perhaps something similar could be done in a C program on
any NT or Mac internet DNS server. If there's no "cron"
functionality, have the nameserver periodically check once
every N seconds (where N ~= one week + random seconds)
against a configured named resource for the list of root
servers. For example, on the internet, it might be
"ftp://ftp.root-servers.net/named.root". For a local admin-
istrator it might be "file:config/named.root".

An RFC describing this mechanism would be yet another checkoff
mark that nameserver vendors would want to comply with. To
promote compliance, nameserver vendors that comply would get
listed on the "Good Netkeeping Seal of Approval List" at
http://www.root-servers.net (where other neat new RFC features
like dynamic updating or secure AXFR are also listed).


The best part about these updates is that your root server list
is always updated from a named resource than can change its IP
address whenever it needs to rather than forcing some IP addresses
to be static.


People who don't update eventually lose. Internet service providers
can detect losers (occasionally sniffing for domain/udp traffic to
outdated servers) and mail them to let them know they should look at
http://www.root-servers.net for more info about updating servers.
Administrators of old root nameservers can do this as well (if ISPs
are uncomfortable sniffing traffic).

.... just fantacizing.
--
Eric Ziegast
- - - - - - - - - - - - - - - - -

> From: Eric Ziegast <ziegast@zee.im.gte.com>
> To: nanog@merit.edu; namedroppers@internic.net
> Subject: Re: The SWAMP
> Date: Monday, September 09, 1996 7:47 PM

> In cron:
>
> # pick a random time once a week
> 31 10 * * 4 /usr/sbin/update-root
> # some other time during the week
> 23 20 * * 6 /usr/sbin/named.restart
>
> The shell script (off the top of my head):
>
> #!/bin/sh
> tmp=/tmp/rs$$
> trap "rm -f $tmp" 1 2 3 14 15
> chdir /etc/namedb
> ncftp -a -d 600 -g 5 ftp.root-servers.net:/named.root
> if [ ! -r named.root ]; then
> Mail -s "Could not get root nameserver list" hostmaster
> fi
> diff root.cache root-servers > $tmp
> if [ -s $tmp ]; then
> mv named.root root.cache # fails if couldn't download
> Mail -s "Root server update" hostmaster < $tmp
> fi
> rm -f $tmp

I don't like "automatic" updates. Sure it is convenient, but for something
as mission-critical as name service, I would hesitate to automatically
trust whatever happens to be at ftp.root-servers.net:/named.root on any
given day. I would want to review it first. Plus, on most BSDish systems
/etc/crontab is world readable by default. A cracker would know the exact
time to attempt to hijack the FTP session and insert:
. IN NS you.got.hacked.net.
you.got.hacked.net. IN A 10.1.2.3

-BD
- - - - - - - - - - - - - - - - -

On Mon, 9 Sep 1996, Nick Hilliard wrote:

| Date: Mon, 9 Sep 1996 22:02:04 +0100 (BST)
| From: Nick Hilliard <nick@eunet.ie>
| To: nanog@merit.edu
| Cc: namedroppers@internic.net
| Subject: Re: The SWAMP
| Resent-Date: Mon, 9 Sep 1996 17:12:00 -0400 (EDT)
| Resent-From: randy@internic.net (Randy Bush)
| Resent-To: namedroppers <namedroppers@internic.net>
|
| > How about allocating some "good sounding" IP addresses for them,
| > (like 1.0.0.x/32) and hard-wiring them into resolver code? Would
| > save quite a lot of configuration headaches for newbies.
|
| Hardwiring anything like this into a system like DNS sounds like a really
| bad idea if only for the simple reason that DNS is not just used on the
| Internet, but also within private networks. Having hardwiring IP numbers in
| this case would cause headaches of unimaginable proportions.
|

I'm ambivalent on this. I think hardwiring the addresses is a good thing,
but a configuration flag should be provided to override the hardwired addresses
(this may simply be the existance of a 'cache' statement, or something
more explicit).

The real problem will be in re-education (or rather educating) all those DNS
admins out there who don't even know they are DNS admin :-)

regards
| Nick
|

Mathias Koerber | Tel: +65 / 471 9820 | mathias@staff.singnet.com.sg
SingNet NOC | Fax: +65 / 475 3273 | mathias@koerber.org
Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias@singnet.com.sg
2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
S'pore 148943 | Disclaimer: I speak only for myself
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *

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

> I don't like "automatic" updates.

... thus the mail when the file is updated and the restart a few
days later. For my example, the named.root FTP/HTTP/AXFR server
would have to be at least as secure as a root server, but would
not have to be more secure.

If people want to review the downloads first, sure, it's a good
idea. Change the shell script to not move the file and just
complain to the admin instead:

Mail -s "New Internet root DNS nameservers" hostmaster<<EOF
The list of root nameservers in `pwd`/named.root is newer
than your current root.cache file. Please run the following on
`hostname` after reviewing the contents of the new root server
list:
cd `pwd`
mv named.root root.cache

Sincerely,
DNS cron on `hostname`
EOF

The administrator would get around to installing it eventually.

For the PC or Mac servers, I'd want a PCN-style update:

A new root nameserver list has been downloaded.
Would you like to install it now?
o Yes
o Review it and give me an option to install it.
o No, not now, try me later.


The idea is to make sure periodic downloads are encouraged from the
start and to make sure there is a DNS-known place (whose name is not
attached to SRI-NIC.ARPA, NIC.DDN.MIL, or FTP.RS.INTERNIC.NET) where
sites can get root server information as long as Internet DNS lives.

IMHO, it's better than promoting laziness by making sure that the
root nameserver addresses are always the same. (What about IPV6? IPVn?)

My shell script was just an example. Implementation may vary.

--
Eric Ziegast
- - - - - - - - - - - - - - - - -

Eric Ziegast writes:
> It's DNS servers, not resolvers, that need to update their lists
> of Internet root servers. The problem (IMHO) is that few sites know
> or care that they have to maintain root server list periodically to
> stay in sync with the rest of the Internet. One way to attack the
> problem (not solve it) is to require nameserver vendors (IIS, Apple,
> BIND, etc.) to provide the capability for periodic root server list
> updates.

I hate to say it, but the ftp script you list to do this is
insecure. If I knew for a fact taht you were doing this regularly,
you would be meat on the table.

Perry
- - - - - - - - - - - - - - - - -

I can see it taking a while for the initial laziness to be overcome, but
once it is in place, it could provide for a lot of improvements including
multiply-rooted TLDs.

The big thing is WHO would do this distribution? The Internic's systems
are already too overwhelmed and customer support is spotty at best.

If we pass it to those service providers that service others [i.e. 1st
tier] then its more work for them, but I can see it being a much more
reliable process.

Just my two cents,

-Deepak.


On Mon, 9 Sep 1996, Eric Ziegast wrote:

> > I don't like "automatic" updates.
>
> ... thus the mail when the file is updated and the restart a few
> days later. For my example, the named.root FTP/HTTP/AXFR server
> would have to be at least as secure as a root server, but would
> not have to be more secure.
>
> If people want to review the downloads first, sure, it's a good
> idea. Change the shell script to not move the file and just
> complain to the admin instead:
>
> Mail -s "New Internet root DNS nameservers" hostmaster<<EOF
> The list of root nameservers in `pwd`/named.root is newer
> than your current root.cache file. Please run the following on
> `hostname` after reviewing the contents of the new root server
> list:
> cd `pwd`
> mv named.root root.cache
>
> Sincerely,
> DNS cron on `hostname`
> EOF
>
> The administrator would get around to installing it eventually.
>
> For the PC or Mac servers, I'd want a PCN-style update:
>
> A new root nameserver list has been downloaded.
> Would you like to install it now?
> o Yes
> o Review it and give me an option to install it.
> o No, not now, try me later.
>
>
> The idea is to make sure periodic downloads are encouraged from the
> start and to make sure there is a DNS-known place (whose name is not
> attached to SRI-NIC.ARPA, NIC.DDN.MIL, or FTP.RS.INTERNIC.NET) where
> sites can get root server information as long as Internet DNS lives.
>
> IMHO, it's better than promoting laziness by making sure that the
> root nameserver addresses are always the same. (What about IPV6? IPVn?)
>
> My shell script was just an example. Implementation may vary.
>
> --
> Eric Ziegast
>
- - - - - - - - - - - - - - - - -

Deepak Jain writes:
> I can see it taking a while for the initial laziness to be overcome, but
> once it is in place, it could provide for a lot of improvements including
> multiply-rooted TLDs.
>
> The big thing is WHO would do this distribution? The Internic's systems
> are already too overwhelmed and customer support is spotty at best.
>
> If we pass it to those service providers that service others [i.e. 1st
> tier] then its more work for them, but I can see it being a much more
> reliable process.

???

Surely you jest.

Well, maybe not. I can see *some* of the tier-1 providers being reasonably
reliable about this.

On the other hand... I can name at least three national providers that I
wouldn't trust to configure their *own* DNS properly. (Don't ask, this isn't
the time or place for flamewars. :-)

While I'm not particularly enchanted with the Internic, I think that their
day-to-day proceedures are working tolerably well. (Note that I'm not
discussing their policies, just implementation). I'd rather see them doing
it than many other organizations.

/a

---
Alexis Rosen Owner/Sysadmin,
PANIX Public Access Unix & Internet, NYC.
alexis@panix.com
- - - - - - - - - - - - - - - - -