4.7-R-p3: j.root-servers.net
Hanspeter Roth
I have installed 4.7-RELEASE-p3.
/etc/namedb/named.root has the following version
$FreeBSD: src/etc/namedb/named.root,v 1.9 1999/09/13 17:09:08 peter Exp $
This has an obsolete j.root-servers.net.
I think I've executed mergemaster.
Are such changes not reflected when sticking with RELENG_4_7?
-Hanspeter
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Kevin Oberman
> From: Hanspeter Roth <ha...@rootshell.be>
> Sender: owner-free...@FreeBSD.ORG
>
> Hello,
>
> I have installed 4.7-RELEASE-p3.
> /etc/namedb/named.root has the following version
> $FreeBSD: src/etc/namedb/named.root,v 1.9 1999/09/13 17:09:08 peter Exp $
>
> This has an obsolete j.root-servers.net.
> I think I've executed mergemaster.
> Are such changes not reflected when sticking with RELENG_4_7?
No. Only security and critical operational patches go into the
RELENG_4_7 branch. This was heavily discussed at the time, but there
are no security or operational issues with this. (This is not
intuitively true, but is clear if you understand the nuts and bolts
of named and DNS caching.)
If you want to get a new version at any time, just issue the command:
dig ns . @b.root-servers.net. > /etc/named/named.root (or wherever
your named.conf tells it to look).
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
faSty
=D
-fasty
Hanspeter Roth
> > Date: Sat, 25 Jan 2003 23:17:25 +0100
> > From: Hanspeter Roth <ha...@rootshell.be>
> > Are such changes not reflected when sticking with RELENG_4_7?
>
> No. Only security and critical operational patches go into the
> RELENG_4_7 branch. This was heavily discussed at the time, but there
Ok.
> are no security or operational issues with this. (This is not
> intuitively true, but is clear if you understand the nuts and bolts
> of named and DNS caching.)
>
> If you want to get a new version at any time, just issue the command:
> dig ns . @b.root-servers.net. > /etc/named/named.root (or wherever
> your named.conf tells it to look).
Ok. I'll create a job as I have to update the instance in
/var/named/namedb anyway.
-Hanspeter
Marc Schneiders
> On Jan 25 at 14:25, Kevin Oberman spoke:
> > > Date: Sat, 25 Jan 2003 23:17:25 +0100
> > > From: Hanspeter Roth <ha...@rootshell.be>
> > If you want to get a new version at any time, just issue the command:
> > dig ns . @b.root-servers.net. > /etc/named/named.root (or wherever
> > your named.conf tells it to look).
>
> Ok. I'll create a job as I have to update the instance in
> /var/named/namedb anyway.
A more permanent solution is to run secondary for root. This has
several advantages. One being speed. The root data will be on your
machine and automatically refreshed every 30 minutes (only when there
are changes, so no useless traffic) by AXFR. If there is another DDoS
attack on the root-servers, you won't suffer from it, for you have the
data yourself. And they don't change much.
To do this replace in named.conf:
zone "." {
type hint;
file "named.root";
};
by this:
zone "." {
type slave;
file "named.root";
masters {
128.9.0.107; 192.33.4.12; 192.5.5.241};
};
The 3 IP numbers are from b, c, and f.root-servers.net, which do allow
an AXFR of the root-zone. The other root-servers don't.
If you care for alternative, extra domains, you replace the IP
numbers indicated by ORSC root-servers (that allow AXFR) and you put
in:
zone "." {
type slave;
file "named.root";
masters {
199.166.29.2; 213.196.2.97; 199.166.24.12; 195.206.104.13;
204.57.55.100};
};
--
[11] You must really read this.
http://logoff.org/
Barney Wolff
>
> A more permanent solution is to run secondary for root. This has
> several advantages. One being speed. The root data will be on your
> machine and automatically refreshed every 30 minutes (only when there
> are changes, so no useless traffic) by AXFR. If there is another DDoS
> attack on the root-servers, you won't suffer from it, for you have the
> data yourself. And they don't change much.
This strikes me as a Really Bad Idea. It increases the load on the roots
that you target, and leaves you high and dry if those roots decide to
deny zone transfers, as they should. The TTLs returned by the roots are
plenty long enough to provide a cushion for any outages, and if the roots
are truly gone longer than that, the whole Internet will not be working.
As has been amply pointed out, named will learn the current roots if even
one root that it knows about is correct and functioning. This is a
complete non-issue.
And of course, using the "alternate" roots is evil.
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
Marc Schneiders
> On Sun, Jan 26, 2003 at 11:48:00PM +0100, Marc Schneiders wrote:
> >
> > A more permanent solution is to run secondary for root. This has
> > several advantages. One being speed. The root data will be on your
> > machine and automatically refreshed every 30 minutes (only when there
> > are changes, so no useless traffic) by AXFR. If there is another DDoS
> > attack on the root-servers, you won't suffer from it, for you have the
> > data yourself. And they don't change much.
>
> This strikes me as a Really Bad Idea. It increases the load on the roots
> that you target,
Prove this. It is only true of your nameserver doesn't do anything or
much. If it is busy, it will actually mean less load on the
rootserver(s). For there will be no traffic for the many non-existing
top level domains that originate in typos. Your own machine will give
the NXDomain amswer.
> and leaves you high and dry if those roots decide to
> deny zone transfers,
This would be true for any other automatic method. That is why I
suggest to put in all three IP numbers.
> as they should.
Opinions differ on this. Since DNS-guru Paul Vixie still lets us AXFR
from his rootserver (F). it cannot be that bad.
> The TTLs returned by the roots are
> plenty long enough to provide a cushion for any outages, and if the roots
> are truly gone longer than that, the whole Internet will not be working.
There are two issues, which you are mixing up. Speed will always be
better when you secondary root. Security will not be much better, but
just a little.
> As has been amply pointed out, named will learn the current roots if even
> one root that it knows about is correct and functioning. This is a
> complete non-issue.
I am not saying, that hints does not work. Just that there is an
aletrnative method, which I and others prefer. Do not pretend there is
consensus about this among DNS people.
> And of course, using the "alternate" roots is evil.
I knew you were a religious person.
--
[01] All ideas are vintage not new or perfect.
http://logoff.org/
Barney Wolff
>
> I am not saying, that hints does not work. Just that there is an
> aletrnative method, which I and others prefer. Do not pretend there is
> consensus about this among DNS people.
Of course there is consensus, as represented by the mechanism used by
every DNS implementation, out of the box. There is not unanimity, but
there is consensus.
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
To Unsubscribe: send mail to majo...@FreeBSD.org
Mark.A...@isc.org
If you have to do this then please, please, please specify
"notify no;". The root servers don't need millions of
additional notify requests.
Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org
Matthew Dillon
:> On Jan 25 at 14:25, Kevin Oberman spoke:
:> > > Date: Sat, 25 Jan 2003 23:17:25 +0100
:> > > From: Hanspeter Roth <ha...@rootshell.be>
:
:> > If you want to get a new version at any time, just issue the command:
:> > dig ns . @b.root-servers.net. > /etc/named/named.root (or wherever
:> > your named.conf tells it to look).
:>
:> Ok. I'll create a job as I have to update the instance in
:> /var/named/namedb anyway.
:
:A more permanent solution is to run secondary for root. This has
:several advantages. One being speed. The root data will be on your
:machine and automatically refreshed every 30 minutes (only when there
It's better to pull the root list with a cronjob. I've included the
shell script I use. All you need to do is replace the named restart
code with whatever is appropriate for your machine (I'm using bind9 and
a chroot so 'ndc' doesn't work for me). You could get fancier and
compare the old and new zone files and only restart if they're
different but I only pull it once a week and there are almost always
differences so I didn't bother.
Pulling from a root server unnecessarily loads the root server,
especially when you use a secondary entry.
30 4 * * 0 cd /etc/namedb; ./getroot
-Matt
#!/bin/tcsh -f
#
# The root_hints file should be updated periodicly from
# ftp.rs.internic.net
umask 027
#set hostname = 'ftp.alternic.net'
#set remfile = 'db.root'
#set locfile = 'db.root'
set hostname = 'ftp.rs.internic.net'
set remfile = domain/root.zone.gz
set locfile = root.zone.gz
set path = ( /bin /usr/bin /sbin /usr/sbin )
fetch ftp://${hostname}:/${remfile}
if ( $status != 0) then
rm -f ${locfile}
echo "Download failed"
else
gunzip < ${locfile} > root.zone.new
if ( $status == 0 ) then
rm -f ${locfile}
if ( -f root.zone ) then
mv -f root.zone root.zone.bak
endif
mv -f root.zone.new root.zone
echo "Download succeeded, restarting named"
#
# CHANGE THESE LINES AS APPROPRIATE FOR YOUR SETUP
#
killall named
sleep 1
/usr/local/sbin/named -c named.conf -t /etc/namedb -u bind
else
echo "Download failed: gunzip returned error"
rm -f ${locfile}
endif
endif
Mark.A...@isc.org
> On Sun, Jan 26, 2003 at 11:48:00PM +0100, Marc Schneiders wrote:
> >
> > A more permanent solution is to run secondary for root. This has
> > several advantages. One being speed. The root data will be on your
> > machine and automatically refreshed every 30 minutes (only when there
> > are changes, so no useless traffic) by AXFR. If there is another DDoS
> > attack on the root-servers, you won't suffer from it, for you have the
> > data yourself. And they don't change much.
>
> This strikes me as a Really Bad Idea. It increases the load on the roots
> that you target, and leaves you high and dry if those roots decide to
> deny zone transfers, as they should. The TTLs returned by the roots are
> plenty long enough to provide a cushion for any outages, and if the roots
> are truly gone longer than that, the whole Internet will not be working.
Firstly there is no proof that it will actually increase the load
on the roots. It may well decrease the load. The analysis has not
been done.
Secondly it is more robust. You are no longer dependent on having
to be able to reach a root server when your nameserver starts.
Thirdly the vast majority (>90%) of the queries to the roots result
in negative answers. These are cached for a much shorter period
than the positive answers.
Forth you don't need to have every one of your nameservers talking
to the root servers. You can use one server to get the zone and
use it to distribute the zone to your other servers.
Mark
> As has been amply pointed out, named will learn the current roots if even
> one root that it knows about is correct and functioning. This is a
> complete non-issue.
>
> And of course, using the "alternate" roots is evil.
>
> --
> Barney Wolff http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via the 'Net.
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Matthew Dillon
Oh, I forgot to include the zone entry in named.conf that I use for that
script:
zone "." {
type hint;
file "root.zone";
};
-Matt
Marc Schneiders
> #set hostname = 'ftp.alternic.net'
> #set remfile = 'db.root'
> #set locfile = 'db.root'
> set hostname = 'ftp.rs.internic.net'
> set remfile = domain/root.zone.gz
> set locfile = root.zone.gz
Did you at some time change your root?
William Palfreman
> And of course, using the "alternate" roots is evil.
Why is that then? I'm slaving the OpenNIC ones here without any
trouble. DNS just being an information service in the end I can't see
why there has to be the only one of its type. In fact, how can it be a
standard if there is only one implementation? :-)
I can think of some very good reasons *to* have multiple roots, for one
allowing new TLD domains to evolve spontaneously, and secondly to
prevent TLD and subdomains from coming under control of oppressive
governments and quasi-government agencies like ICANN. AFAIK .za had to
move to the UK a while back precisely to avoid takeover by the South
African government, but even so, one fixed root is bound to lead to
increasing political control in the end.
So what is the great theoretical objection to multiple roots then?
--
W. Palfreman.
Jason Slagle
> So what is the great theoretical objection to multiple roots then?
We've already seen a conflict between the "official" roots and the
offshoots. What happens then? Anyone who registered a .biz in the fake
root is now somewhat screwed.
The second problem is visibility. Without multiple roots being global,
they offer a very limited utility.
The final problem is lack of direction. What if I tommorrow created my
own alternative root with a .geek TLD. There would be a conflict created.
Even if we HAD multiple roots, a single group would have to be in charge
of who got what TLD's and you still have the political drama because of
that.
Jason
--
Jason Slagle - CCNP - CCDP
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ / ASCII Ribbon Campaign .
X - NO HTML/RTF in e-mail .
/ \ - NO Word docs in e-mail .
Matthew Dillon
:On Sun, 26 Jan 2003, at 15:55 [=GMT-0800], Matthew Dillon wrote:
:
:> #set hostname = 'ftp.alternic.net'
:> #set remfile = 'db.root'
:> #set locfile = 'db.root'
:> set hostname = 'ftp.rs.internic.net'
:> set remfile = domain/root.zone.gz
:> set locfile = root.zone.gz
:
:Did you at some time change your root?
That's just old commented out stuff. Probably from quite a long time
ago, I've been using some variation of this script for almost 10 years.
-Matt
Matthew Dillon
<dil...@backplane.com>
Barney Wolff
>
> Firstly there is no proof that it will actually increase the load
> on the roots. It may well decrease the load. The analysis has not
> been done.
>
> Secondly it is more robust. You are no longer dependent on having
> to be able to reach a root server when your nameserver starts.
>
> Thirdly the vast majority (>90%) of the queries to the roots result
> in negative answers. These are cached for a much shorter period
> than the positive answers.
>
> Forth you don't need to have every one of your nameservers talking
> to the root servers. You can use one server to get the zone and
> use it to distribute the zone to your other servers.
Well! When ISC officially endorses this technique, by distributing
bind with it set up as the default, I'll be pleased to change my mind.
Until then, not.
Marc Schneiders
> Well! When ISC officially endorses this technique, by distributing
> bind with it set up as the default, I'll be pleased to change my mind.
> Until then, not.
Always best to only use default configurations. Never trust yourself!
--
[15] We are in need.
http://logoff.org/
Mark.A...@isc.org
> On Sun, 26 Jan 2003, Barney Wolff wrote:
>
> > And of course, using the "alternate" roots is evil.
>
> Why is that then? I'm slaving the OpenNIC ones here without any
> trouble. DNS just being an information service in the end I can't see
> why there has to be the only one of its type. In fact, how can it be a
> standard if there is only one implementation? :-)
Did you ever here the term "natual monopoly". The DNS root
is a example of such. When you try to change it all you
do is reproduce it with additional unnecessary baggage like
have to find all the "roots" to register the new TLD in.
> I can think of some very good reasons *to* have multiple roots, for one
> allowing new TLD domains to evolve spontaneously, and secondly to
> prevent TLD and subdomains from coming under control of oppressive
> governments and quasi-government agencies like ICANN.
And why do you think that you should have the right to
create arbitary new TLDs? Hell I would like the "prestige"
of my own TLD but I know that it is *not* in the best
interests of the world as a whole to have lots to TLDs which
is the natural consequence to allowing anyone to set one
up. In the end you end up with a massive root zone (similar
to the COM zone) that requires very large machines to serve
it or requires many smaller machines with a fancy front end.
> AFAIK .za had to
> move to the UK a while back precisely to avoid takeover by the South
> African government, but even so, one fixed root is bound to lead to
> increasing political control in the end.
Well "za" should have known from the start that the South
African government would possible want control at some point
in time. It was quite evident from the start that governments
would eventually wake up to the fact that the Internet
existed and the naming structure included country codes.
I know Robert Elz was aware that this was a possibility
when "au" was established. That's also why we use "oz"
not "au" for the top level of ACSnet.
>
> So what is the great theoretical objection to multiple roots then?
>
> --
> W. Palfreman.
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Barney Wolff
Please don't misattribute idiocy to me - my reputation is all I've got.
Barney Wolff
On Mon, Jan 27, 2003 at 02:58:54PM +1100, Mark.A...@isc.org wrote:
>
> > On Sun, 26 Jan 2003, Barney Wolff wrote:
> >
> > > And of course, using the "alternate" roots is evil.
> >
> > Why is that then? I'm slaving the OpenNIC ones here without any
> > trouble. DNS just being an information service in the end I can't see
> > why there has to be the only one of its type. In fact, how can it be a
> > standard if there is only one implementation? :-)
>
> Did you ever here the term "natual monopoly". The DNS root
> is a example of such. When you try to change it all you
> do is reproduce it with additional unnecessary baggage like
> have to find all the "roots" to register the new TLD in.
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
To Unsubscribe: send mail to majo...@FreeBSD.org
Marc Schneiders
> Just for the record, I wrote "... is evil" not the nonsense about OpenNIC.
> Please don't misattribute idiocy to me - my reputation is all I've got.
And that is that you have strong opinions and use strong words to
defend them in your recent messages to this list. Arguing something is
not your forte.
--
[08] We appreciate positive feedback.
http://logoff.org/
Hanspeter Roth
> A more permanent solution is to run secondary for root. This has
Hm, this is an interesting idea.
> several advantages. One being speed. The root data will be on your
> machine and automatically refreshed every 30 minutes (only when there
> are changes, so no useless traffic) by AXFR. If there is another DDoS
But if everybody does this the root servers will probably be much
more loaded, won't they?
So it's probably only for `privileged' users?
> attack on the root-servers, you won't suffer from it, for you have the
> data yourself. And they don't change much.
If root is handled in hint mode I shouldn't suffer too much anyway?
> If you care for alternative, extra domains, you replace the IP
> numbers indicated by ORSC root-servers (that allow AXFR) and you put
What is ORSC? Is it's data identical with the one from the NET
servers? Or das it have more or different data?
Is it where the hijacks (dns-spoofs) come from?
-Hanspeter
William Palfreman
> Did you ever here the term "natural monopoly". The DNS root is a
> example of such.
Yup, I'm a trained economist, so I know about natural monopolies. Or
rather I don't know, because in real life they never exist. What exist
are government supported monopolies, where an organisation and a
government discover a mutual interest in preventing rivals from
operating. I see no technical reason why this need happen to DNS.
> When you try to change it all you
> do is reproduce it with additional unnecessary baggage like
> have to find all the "roots" to register the new TLD in.
Isn't that the whole point of IRON / www.root-dns.org and alt.roots?
As usual the problem has been solved according to the principle of
co-operation and agreement before anyone "in authority" could "prove"
this wasn't possible.
> And why do you think that you should have the right to create arbitrary
> new TLDs?
If I had the bandwidth and the server power in redundant locations,
and I had convinced the operators of the applicable roots of my
technical competence, I don't see any reason why I should not operate my
own TLD. I already do for the lan on this site, so really it is just a
matter of scaling it up.
> Hell I would like the "prestige" of my own TLD but I know
> that it is *not* in the best interests of the world as a whole to have
> lots to TLDs which is the natural consequence to allowing anyone to
> set one up. In the end you end up with a massive root zone (similar
> to the COM zone) that requires very large machines to serve it or
> requires many smaller machines with a fancy front end.
As I read that, you are saying that unlimited TLDs are a bad idea
because that would make . as crowded as COM. Doesn't the popularity of
COM go to show that in use, people want domain names to be TLDs and
absolute? - So what they get is a COM, because COM has become a
shorthand for a domain. Using TLDs simply for primitive load-balancing
seems like the wrong approach to me, and is already being undermined by
reality.
> Well "za" should have known from the start that the South
> African government would possible want control at some point
> in time. It was quite evident from the start that governments
> would eventually wake up to the fact that the Internet
> existed and the naming structure included country codes.
If you look at the terms of RSA proposed takeover of the za domain you
can see that it would have been an absolute disaster. But it didn't
come to that because *DNS need not be a function of government*. The
beauty of the domain name system is that, not being a natural monopoly,
and being dependent on peer support (i.e. other DNS admins), there is a
natural method of preventing abuses from occurring.
As far as I can see, I've yet to hear a good technical argument why
there need be only one root. Possible problems with multiple roots
don't seem to actually occur in real life, whereas problems with the
mainstream root occur all the time - abusive behaviour by some
government wannabees, abusive interference by courts in domain name
ownership, ICANN, DDoS attacks, simple volume of traffic problems and so
on. All of these are alleviated by multiple roots.
--
W. Palfreman.
Tel: +44 (0)771 355 0354
Marc Schneiders
> On Jan 26 at 23:48, Marc Schneiders spoke:
>
> > A more permanent solution is to run secondary for root. This has
> But if everybody does this the root servers will probably be much
> more loaded, won't they?
As has been pointed out by Mark Andrews of ISC, the Bind maintainers,
the answer to this type of question as yet has to be determined. We
don't know. Let's not pretend we do.
> So it's probably only for `privileged' users?
Anybody can do it, and lots of people are doing it. I am imagining
that people who run just Windows Stable now, will not all start
messing with their DNS all of a sudden.
And anyway, it is unclear whether it would mean more or less traffic.
> > attack on the root-servers, you won't suffer from it, for you have the
> > data yourself. And they don't change much.
>
> If root is handled in hint mode I shouldn't suffer too much anyway?
Sure, when you need a new TLD, or one that has just expired in your
cache, with the hints system, you either get no answer, or it takes
longer.
> > If you care for alternative, extra domains, you replace the IP
> > numbers indicated by ORSC root-servers (that allow AXFR) and you put
>
> What is ORSC?
> Is it's data identical with the one from the NET
> servers? Or das it have more or different data?
"alternative, extra" in my message, fully answers that.
> Is it where the hijacks (dns-spoofs) come from?
No, those are Windows 2000 machines that try to update your zones.
Edwin Groothuis
> As far as I can see, I've yet to hear a good technical argument why
> there need be only one root. Possible problems with multiple roots
I'll give you one: distribution of new roots. Overcome that problem
and you have the same problem again: who is in charge of the
distribution of a new root?
Edwin
--
Edwin Groothuis | Personal website: http://www.mavetju.org
ed...@mavetju.org | Weblog: http://www.mavetju.org/weblog/weblog.php
Doug Barton
> Hello,
>
> I have installed 4.7-RELEASE-p3.
> /etc/namedb/named.root has the following version
> $FreeBSD: src/etc/namedb/named.root,v 1.9 1999/09/13 17:09:08 peter Exp $
>
> This has an obsolete j.root-servers.net.
> I think I've executed mergemaster.
> Are such changes not reflected when sticking with RELENG_4_7?
Your final question was already answered. I think that given all the heat
this subject has generated, a little light is in order.
1. The root zone had not changed for _years_ before this change.
2. The old j.root will continue to answer for a long time.
3. Your name server only needs ONE valid root server in the hints file
when it starts, since updating its internal view of the root zone is one
of the first things it does.
4. When your server does update its . zone, the NS records are cached
for 6 days, and the A records are cached for 5w6d16h (almost 6 weeks).
5. When you boot BIND 8.3.[34], it tells you if your hints file is out of
date once it's updated its cache.
Given this information, all the fuss about "regularly" updating your hints
file is fairly pointless.
As for making your local resolver a slave for the root zone, that
suggestion has some merit, but not because of anything having to do with
the root.hints file. Most resolvers are only ever going to query a few
TLD's, and most TLD NS records are cached for 2 days, or more.
IF you're going to slave the root zone, make sure to do something like
this:
zone "." {
type slave;
file "slave/root.slave";
masters {
128.9.0.107; // B.ROOT-SERVERS.NET.
192.33.4.12; // C.ROOT-SERVERS.NET.
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};
Take special note of the 'notify no;' statement. When a name server first
starts up, by default it sends out notifies for all its zones. This would
be a bad thing in this case. Also, try not to have all of the resolvers on
your network slave the zone. It would be better to have one server do it,
then slave it to the rest from there.
Hope this helps,
Doug
--
If it's moving, encrypt it. If it's not moving, encrypt
it till it moves, then encrypt it some more.
Mark.A...@isc.org
> On Sat, 25 Jan 2003, Hanspeter Roth wrote:
>
> > Hello,
> >
> > I have installed 4.7-RELEASE-p3.
> > /etc/namedb/named.root has the following version
> > $FreeBSD: src/etc/namedb/named.root,v 1.9 1999/09/13 17:09:08 peter Exp $
> >
> > This has an obsolete j.root-servers.net.
> > I think I've executed mergemaster.
> > Are such changes not reflected when sticking with RELENG_4_7?
>
> Your final question was already answered. I think that given all the heat
> this subject has generated, a little light is in order.
>
> 1. The root zone had not changed for _years_ before this change.
The root zone changes about every two weeks (or was that
twice weekly?). Anyway it is reasonably frequently but not
daily. By changes I mean changes other than serial number.
The serial number changes twice daily.
The root servers however have not changed in years prior to
J changing address.
> 2. The old j.root will continue to answer for a long time.
And it will be unusable for anything else for a long time after
it stops answering which will be years down the track.
> 3. Your name server only needs ONE valid root server in the hints file
> when it starts, since updating its internal view of the root zone is one
> of the first things it does.
>
> 4. When your server does update its . zone, the NS records are cached
> for 6 days, and the A records are cached for 5w6d16h (almost 6 weeks).
>
> 5. When you boot BIND 8.3.[34], it tells you if your hints file is out of
> date once it's updated its cache.
That reminds me I need to code the that check in BIND 9.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Doug Barton
>
> The root zone changes about every two weeks (or was that
> twice weekly?). Anyway it is reasonably frequently but not
> daily. By changes I mean changes other than serial number.
> The serial number changes twice daily.
Sorry, I meant the hints file had not changed for a long time before J was
changed recently. I realized that I had the hints file and the root zone
confused in my post, but I didn't change it everywhere I needed to.
Sorry for the confusion,
Matthew Dillon
downloading it from the internic once a week. The root.zone is like
an extended hints file: It not only has the name servers for ".",
it has the name servers for the TLDs (like .COM, .AU, etc) as well.
These change regularly. The zone file is around 50K.
What I have just realized however is that my name server may not be
using the TLD entries when I load root.zone as a 'hints' file. It
may just be using the root entries. Now I'm not sure whether I am
reaping all the benefits from the file I've been downloading for the
last 10 years or not :-)
In anycase, regardless of how the TLDs are handled as a hints file,
I strongly recommend the scripted download methodlogy over any other.
I've been using it a long time and have never had a problem. I think
it is somewhat more robust then depending on a secondary entry.
-Matt
:On Tue, 28 Jan 2003 Mark.A...@isc.org wrote:
:
:>
:> The root zone changes about every two weeks (or was that
:> twice weekly?). Anyway it is reasonably frequently but not
:> daily. By changes I mean changes other than serial number.
:> The serial number changes twice daily.
:
:Sorry, I meant the hints file had not changed for a long time before J was
:changed recently. I realized that I had the hints file and the root zone
:confused in my post, but I didn't change it everywhere I needed to.
:
:Sorry for the confusion,
:
:Doug
Doug Barton
On Tue, 28 Jan 2003, Matthew Dillon wrote:
> This discussion has got me to thinking a bit. I go the root.zone route,
> downloading it from the internic once a week.
Errr.. it would actually be better to do something like 'dig
@b.root-servers.net . axfr > file' than to download it from internic. Both
because it's updated more than once a week, and because the version
available for ftp is not always updated in a timely manner.
> The root.zone is like an extended hints file:
No it's not. The root zone file is just that. It's a real zone file for
the root zone. A hints file has a very different syntax. This is an
important distinction.
> What I have just realized however is that my name server may not be
> using the TLD entries when I load root.zone as a 'hints' file. It
> may just be using the root entries. Now I'm not sure whether I am
> reaping all the benefits from the file I've been downloading for the
> last 10 years or not :-)
I just tested this on bind 8.3.4, and the database has all of the contents
of the root zone, listed as hints. So, at least with recent bind 8 you've
been getting what you think you're getting... whether it's a good thing or
not is another question. :)
Mark.A...@isc.org
> I just tested this on bind 8.3.4, and the database has all of the contents
> of the root zone, listed as hints. So, at least with recent bind 8 you've
> been getting what you think you're getting... whether it's a good thing or
> not is another question. :)
Just because they are loaded into the hints doesn't mean that they
are accessed. Only the root NS records and glue address records
are used.
BIND 9 will complain if there is additional data in the hints.
Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Doug Barton
>
> > I just tested this on bind 8.3.4, and the database has all of the contents
> > of the root zone, listed as hints. So, at least with recent bind 8 you've
> > been getting what you think you're getting... whether it's a good thing or
> > not is another question. :)
>
> Just because they are loaded into the hints doesn't mean that they
> are accessed. Only the root NS records and glue address records
> are used.
That's good to know... I was kind of surprised that it was in the db at
all.
> BIND 9 will complain if there is additional data in the hints.
Even better. :)
--
If it's moving, encrypt it. If it's not moving, encrypt
it till it moves, then encrypt it some more.
To Unsubscribe: send mail to majo...@FreeBSD.org
Matthew Dillon
:
:That's good to know... I was kind of surprised that it was in the db at
:all.
:
:> BIND 9 will complain if there is additional data in the hints.
:
:Even better. :)
:
:--
Ok, I'm thinking then that it's better to load it as a real zone
file. Why do it that way instead of allowing updates via a root
server? Because in the last ten years I've had a number of problems
with individual root servers returning bad data. It doesn't happen
very often, but it does happen. I've have never had problems with
the downloaded root.zone, and if I ever do at least I'll know that
it's the likely cause since I only download it once a week on sunday,
and I can review the current and prior zone files without having to
dump named. From my point of view as an administrator that's the more
secure approach.
In anycase, there are obviously many ways to keep an up-to-date root
zone, my methodology is only one out of that list.
-Matt
Marc Schneiders
> Ok, I'm thinking then that it's better to load it as a real zone
> file. Why do it that way instead of allowing updates via a root
> server?
Because there is a feature in the DNS protocol called AXFR. It is
implemented by most if not all nameserver programs out there. It works
very well, with Bind in any case. It works automatically. It does not
cause much traffic if the zone is unchanged.
> Because in the last ten years I've had a number of problems
> with individual root servers returning bad data.
And did that cause any problems? Did your nameserver start to give out
weird answers? Or did it keep the old data?
> It doesn't happen
> very often, but it does happen.
I have never seen it, but that may not mean much. Sometimes a server
is unavailable for AXFR. Then Bind tries again a bit later. You may
the find files with weird extensions in your bind directory, like:
heist-centrum.be.db.6W6v6z
heist-centrum.be.db.vt3zUh
henkepak.com.db.2vq0pU
solidnetworks.org.db.FsG2hp
henkepak.com.db.HxO78P
All 0 bytes in size.
> I've have never had problems with
> the downloaded root.zone, and if I ever do at least I'll know that
> it's the likely cause since I only download it once a week on sunday,
> and I can review the current and prior zone files without having to
> dump named. From my point of view as an administrator that's the more
> secure approach.
Assuming:
1. That you don't forget it;
2. That you make no mistakes.
> In anycase, there are obviously many ways to keep an up-to-date root
> zone, my methodology is only one out of that list.
Naturally, but I prefer one that was invented for this purpose, AXFR,
and does the job without me wasting time. Once every few months I
clean up those empty temporary files of failed AXFRs. But that isn't
even necessary.
--
[08] We appreciate positive feedback.
http://logoff.org/
Fred Clift
> mainstream root occur all the time - abusive behaviour by some
> government wannabees, abusive interference by courts in domain name
> ownership, ICANN, DDoS attacks, simple volume of traffic problems and
Are you saying that there is some other way than courts (or violence) to
ultimately resolve things that exist only in terms of law? ie
'ownership'?
Since the concept of ownership is basically just a legal definition, then
legal means will be (leaving out violence) the ultimate means of resolving
issues surrounding it.
Fred
--
Fred Clift - fcl...@verio.net -- Remember: If brute
force doesn't work, you're just not using enough.
William Palfreman
> Are you saying that there is some other way than courts (or violence) to
> ultimately resolve things that exist only in terms of law? ie
> 'ownership'?
I'll reply on freebsd-chat, as this is OT for -stable
--
Bill.