Re: root and in-addr.arpa zone transfers

[Michael Monnerie]

On Montag 14 September 2009 Stephane Bortzmeyer wrote:
> > Faster queries after a named restart. Reverse lookups faster too,
> > good for the spam filters.
>
> Did you measure it or is it, like most claims "X is faster", just a
> guess?

In normal Setup, we see lots of querie to the 3rd DNS entry in 
resolv.conf for quite some time after a restart.
With root/arpa copies local, even after a restart very quick 
normalisation occurs.

I wouldn't recommend doing the slaving if you have to start new, but we 
already have the infrastructure/scripts running and tested, so I'll just 
keep it. We had no negative side effects so far. While it's a small 
gain, keeping it doesn't hurt, so: I won't touch the running system.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0660 / 415 65 31  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net  Key-ID: 1C1209B4

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Stephane Bortzmeyer]

On Fri, Sep 11, 2009 at 07:28:56AM +0200,
 Michael Monnerie  wrote 
 a message of 51 lines which said:

> Faster queries after a named restart. Reverse lookups faster too,
> good for the spam filters.

Did you measure it or is it, like most claims "X is faster", just a
guess?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Mark Andrews]

In message <20090912082415.ga13...@fantomas.sk>, Matus UHLAR - fantomas writes:
> > On Freitag 11 September 2009 Matus UHLAR - fantomas wrote:
> > > - it's quite useless to cache the .arpa and .in-addr.arpa since
> > > unlike other TLD's they are hierarchically organised so there won't
> > > be any valuable benefit from slaving them, only risks (see above).
> 
> On 12.09.09 09:27, Michael Monnerie wrote:
> > Every other point is OK, but I don't understand this one. They are all 
> > hierarchical, what's the difference with .in-addr.arpa?
> 
> while there are many manual mistypes in root and other domains, there are (ne
> arly) no
> mistypes in .arpa and in-addr.arpa domains since these domains are
> accessed by software and miskates here are unlikely to happen 
> (of course sw can have bugs but authors would soon notice it doesn't work).

Whether in-addr.arpa is useful or not depends on where you are in
the world and what the connectivity is like.  There was a time when
I would have recommended slaving the root and in-addr.arpa to every
Australian site.  When the one link connecting most of Australia
went down this sort of think kept a vast majority of the internal
communications within Australia working as you could find "au" and
you could do reverse lookups of the Australian address blocks.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Matus UHLAR - fantomas]

> On Freitag 11 September 2009 Matus UHLAR - fantomas wrote:
> > - it's quite useless to cache the .arpa and .in-addr.arpa since
> > unlike other TLD's they are hierarchically organised so there won't
> > be any valuable benefit from slaving them, only risks (see above).

On 12.09.09 09:27, Michael Monnerie wrote:
> Every other point is OK, but I don't understand this one. They are all 
> hierarchical, what's the difference with .in-addr.arpa?

while there are many manual mistypes in root and other domains, there are 
(nearly) no
mistypes in .arpa and in-addr.arpa domains since these domains are
accessed by software and miskates here are unlikely to happen 
(of course sw can have bugs but authors would soon notice it doesn't work).

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Michael Monnerie]

On Freitag 11 September 2009 Matus UHLAR - fantomas wrote:
> - it's quite useless to cache the .arpa and .in-addr.arpa since
> unlike other TLD's they are hierarchically organised so there won't
> be any valuable benefit from slaving them, only risks (see above).

Every other point is OK, but I don't understand this one. They are all 
hierarchical, what's the difference with .in-addr.arpa?

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0660 / 415 65 31  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net  Key-ID: 1C1209B4

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Matus UHLAR - fantomas]

On 11.09.09 09:13, Rich Goodson wrote:
> Slaving root is certainly not something I would recommend to everyone.  
> In fact, I don't even use it on all of our name servers. I was just  
> answering the question regarding how one would go about doing something 
> rather than why or why not to do it.
>
> Here is why I do it and why I'm fairly comfortable with it.
> We have 6 geographically separated servers that are only used for  
> recursive resolution for residential customers.  90% of the traffic to  
> those boxes (about 30k queries per second, per machine, during peak  
> hours) is crap.  Having a locally slaved root zone cuts down on the  
> amount of crap we in turn forward out to the world (especially to the  
> root servers).  Being able to answer (reject, in a way) these queries  
> locally also helps save CPU cycles on boxes that run at around 75% of  
> CPU capacity.

Yesterdey I read (again, first time a ~year ago) the whole (hopefully)
thread and I'll try to summarize what I've remembered:

- too many "." slaves can cause overload of root nameservers - it's much
  easier to handle many UDP requests than a few TCP requests.

- it's not good to have that by default. There are many DNS recursive
  servers in the world (I'd say most) that only have a few clients, and are
  not generating enough of traffic so they wouldn't spare anything but it
  could overload root servers.

- if you have enough of different clients (which appears to be your case),
  it's apparently acceptable for you to slave the root zone, although it's
  recommended not to do from all of your servers. Local axfr hierarchy could
  do that.

- the crap sent to TLD servers (yes, there's much of it but they can handle
  it) changes at time and their operators are finding reasons what's
  happening and contacting companies that are responsible for it.

- only a few roots allow AXFR of root zone, despite RFC discourages that.
  ISC servers (and possibly others) do that for diagnostic reason, not for
  "ordinary" people doing that.

- it's quite risky if server(s) in the "masters" directive would stop
  providing AXFR, the zone could expire which would lead to troubles.

- there are scripts fetching the root zone via FTP from rs.internic.net,
  unluckily not all of them asre verifying all those check for its
  signature, which may lead to problems. Expiration doesn't happen here
  which can otoh cause problem when scripts fail to fetch the zone and new
  TLDs will appear or the root servers' IPs will change.

- it's quite useless to cache the .arpa and .in-addr.arpa since unlike other
  TLD's they are hierarchically organised so there won't be any valuable
  benefit from slaving them, only risks (see above).

- there's no way of slaving huge domains like .com .net (they aren't
  apparently slaved even by verisign's servers).

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux IS user friendly, it's just selective who its friends are...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Rich Goodson]

Slaving root is certainly not something I would recommend to everyone.  
In fact, I don't even use it on all of our name servers. I was just  
answering the question regarding how one would go about doing  
something rather than why or why not to do it.


Here is why I do it and why I'm fairly comfortable with it.
We have 6 geographically separated servers that are only used for  
recursive resolution for residential customers.  90% of the traffic to  
those boxes (about 30k queries per second, per machine, during peak  
hours) is crap.  Having a locally slaved root zone cuts down on the  
amount of crap we in turn forward out to the world (especially to the  
root servers).  Being able to answer (reject, in a way) these queries  
locally also helps save CPU cycles on boxes that run at around 75% of  
CPU capacity.


These are also boxes that are heavily monitored and that I am logged  
in to every day.


Insofar as extra load on the root servers is concerned, I think I am  
using far less root server resources by doing a few TCP connections  
that help me avoid sending tons of crap to them via UDP.


Like I said earlier.  Not something I would recommend for everyone,  
but it seems to work well for what I use it for.


-rich

On Sep 10, 2009, at 8:16 PM, Joseph S D Yao wrote:


On Thu, Sep 10, 2009 at 11:27:27AM +0200, Michael Monnerie wrote:

On Mittwoch 09 September 2009 Rich Goodson wrote:

zone "." {
zone "arpa" {
zone "in-addr.arpa" {


Thank you Rich, and the others. Can anyone confirm that this is the  
way
to do? Or should I stay with ftp updates from the websites? Is  
there an

"officially supported" or "recommended" way to do this or that?



RFC 2870, "Root Name Server Operational Requirements", says:

  2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
  queries from clients other than other root servers.  This
  restriction is intended to, among other things, prevent
  unnecessary load on the root servers as advice has been heard
  such as "To avoid having a corruptible cache, make your server a
  stealth secondary for the root zone."  The root servers MAY put
  the root zone up for ftp or other access on one or more less
  critical servers.

You may take from that what you will.  It sounds like discouragement  
to

me.

However, as M. Bortzmeyer has said, why do this?  I was doing it on a
smaller internet, and came back to find that transfers for "." had  
been

turned off [but not in-addr.arpa [???]], and lookups were slowed down
because they were looking at our local "root" first.  (It fixed itself
"by magic" when I complained, but nobody else had thought to do that.)


--
/ 
*\

**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Restarting named [was: Re: root and in-addr.arpa zone transfers]

[Chris Thompson]

On Sep 11 2009, Sam Wilson wrote:


In article ,
Michael Monnerie  wrote:


On Freitag 11 September 2009 Joseph S D Yao wrote:
> However, as M. Bortzmeyer has said, why do this?

Faster queries after a named restart. ...


How often do you restart named?


$ ps -o user,zone,pid,stime,time,comm -U namesrvr
   USER ZONE   PIDSTIMETIME COMMAND
namesrvr testdns0   104   Jul_28   00:16 /usr/local/BIND/bind/sbin/named
namesrvr authdns0  1169   Jul_2907:11:15 /usr/local/BIND/bind/sbin/named
namesrvr  recdns0  1611   Jul_29  3-08:01:37 /usr/local/BIND/bind/sbin/named

$  ps -o user,zone,pid,stime,time,comm -U namesrvr
   USER ZONE   PIDSTIMETIME COMMAND
namesrvr authdns1 13248   Jul_2905:03:41 /usr/local/BIND/bind/sbin/named
namesrvr  fakedns 12389   Jul_29   02:29 /usr/local/BIND/bind/sbin/named
namesrvr testdns1 13981   Jul_29   00:17 /usr/local/BIND/bind/sbin/named
namesrvr  recdns1 13748   Jul_29  1-13:48:35 /usr/local/BIND/bind/sbin/named

That was from the (somewhat urgent) upgrade from BIND 9.6.1 to 9.6.1-P1.
It's not unusual for them to run for months without interruption.

   We hit our master once a day, in the 
early hours but that's just habit and I've always thought we were a bit 
hyperactive.


I think so too.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Sam Wilson]

In article ,
 Michael Monnerie  wrote:

> On Freitag 11 September 2009 Joseph S D Yao wrote:
> > However, as M. Bortzmeyer has said, why do this?
> 
> Faster queries after a named restart. ...

How often do you restart named?  We hit our master once a day, in the 
early hours but that's just habit and I've always thought we were a bit 
hyperactive.  The slaves only get hit for upgrades or problems.

> ... Reverse lookups faster too, good 
> for the spam filters.

Only the first few, until the relevant X.in-addr.arpa NS records are 
cached. How many X in *.X.in-addr.arpa do you get spam from?

Sam
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Michael Monnerie]

On Freitag 11 September 2009 Joseph S D Yao wrote:
> However, as M. Bortzmeyer has said, why do this?

Faster queries after a named restart. Reverse lookups faster too, good 
for the spam filters.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0660 / 415 65 31  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net  Key-ID: 1C1209B4



signature.asc
Description: This is a digitally signed message part.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Joseph S D Yao]

On Thu, Sep 10, 2009 at 11:27:27AM +0200, Michael Monnerie wrote:
> On Mittwoch 09 September 2009 Rich Goodson wrote:
> > zone "." {
> > zone "arpa" {
> > zone "in-addr.arpa" {
> 
> Thank you Rich, and the others. Can anyone confirm that this is the way 
> to do? Or should I stay with ftp updates from the websites? Is there an 
> "officially supported" or "recommended" way to do this or that?


RFC 2870, "Root Name Server Operational Requirements", says:

   2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
   queries from clients other than other root servers.  This
   restriction is intended to, among other things, prevent
   unnecessary load on the root servers as advice has been heard
   such as "To avoid having a corruptible cache, make your server a
   stealth secondary for the root zone."  The root servers MAY put
   the root zone up for ftp or other access on one or more less
   critical servers.

You may take from that what you will.  It sounds like discouragement to
me.

However, as M. Bortzmeyer has said, why do this?  I was doing it on a
smaller internet, and came back to find that transfers for "." had been
turned off [but not in-addr.arpa [???]], and lookups were slowed down
because they were looking at our local "root" first.  (It fixed itself
"by magic" when I complained, but nobody else had thought to do that.)


-- 
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Stephane Bortzmeyer]

On Thu, Sep 10, 2009 at 12:31:45PM +0200,
 Michael Monnerie  wrote 
 a message of 70 lines which said:

> that's a clear statement, so I'll keep the ftp transfers.

It would be better to drop them completely and to return to ordinary
DNS resolution. What's the point of mirroring the root? What if your
cron job stops working?

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Michael Monnerie]

On Donnerstag 10 September 2009 Stephane Bortzmeyer wrote:
> > right now I'm using scripts to download root.zone and in-addr.arpa
> > from internic.net. But this is a non-standard way,
>
> But a secure way since the files on internic.net are PGP-signed.
>
> > I'd prefer to directly slave and zone-transfer those 2 zones.
>
> That's widely regarded as a bad practice.
>
> FreeBSD backed off:
> .html>
>
> Why it is a bad idea:
> .html>
>
> Discussion:
> 91.html>

Merci beaucoup, Stephane,
that's a clear statement, so I'll keep the ftp transfers.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0660 / 415 65 31  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net  Key-ID: 1C1209B4



signature.asc
Description: This is a digitally signed message part.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Michael Monnerie]

On Mittwoch 09 September 2009 Rich Goodson wrote:
> zone "." {
> zone "arpa" {
> zone "in-addr.arpa" {

Thank you Rich, and the others. Can anyone confirm that this is the way 
to do? Or should I stay with ftp updates from the websites? Is there an 
"officially supported" or "recommended" way to do this or that?

mfg zmi
-- 
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0660 / 415 65 31  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net  Key-ID: 1C1209B4

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Stephane Bortzmeyer]

On Wed, Sep 09, 2009 at 11:00:37AM -0400,
 Rick Dicaire  wrote 
 a message of 23 lines which said:

> Interestingcan any of the root servers be used, or must it be just
> these three?

No root server operator (except may be ISC for F) ever promised to
keep zone transfer open. It is not regarded as a mandatory
service. Therefore, the servers you list can stop this service at any
moment.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Stephane Bortzmeyer]

On Wed, Sep 09, 2009 at 08:23:23AM +0200,
 Michael Monnerie  wrote 
 a message of 54 lines which said:

> right now I'm using scripts to download root.zone and in-addr.arpa
> from internic.net. But this is a non-standard way,

But a secure way since the files on internic.net are PGP-signed. 

> I'd prefer to directly slave and zone-transfer those 2 zones.

That's widely regarded as a bad practice.

FreeBSD backed off:


Why it is a bad idea:


Discussion:

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[omight]

Apparently FreeBSD only slaves F.ROOT-SERVERS.NET in it's default
configuration for bind:
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/named.conf
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/named.conf?rev=1.21.2.9;content-type=text%2Fplain


/*  Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS

On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server.  Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts.  Use with caution.

To use this mechanism, uncomment the entries below, and comment
the hint zone above.
*/
/*
zone "." {
type slave;
file "slave/root.slave";
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
};
notify no;
};
zone "arpa" {
type slave;
file "slave/arpa.slave";
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
};
notify no;
};


2009/9/9 Matus UHLAR - fantomas :
> On 09.09.09 11:00, Rick Dicaire wrote:
>> On Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson  
>> wrote:
>> > zone "." {
>> >        type slave;
>> >        file "slave/root.slave";
>> >        masters {
>> >                192.33.4.12;    // C.ROOT-SERVERS.NET.
>> >                192.112.36.4;   // G.ROOT-SERVERS.NET.
>> >                193.0.14.129;   // K.ROOT-SERVERS.NET.
>> >        };
>> >        notify no;
>> > };
>>
>> Interestingcan any of the root servers be used, or must it be just
>> these three?
>
> you can try dig axfr from all of them but many of them don't allow
> transfers. I guess he already did it and above is list of servers that do
> allow transfers...
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Due to unexpected conditions Windows 2000 will be released
> in first quarter of year 1901
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Matus UHLAR - fantomas]

On 09.09.09 11:00, Rick Dicaire wrote:
> On Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson  
> wrote:
> > zone "." {
> >        type slave;
> >        file "slave/root.slave";
> >        masters {
> >                192.33.4.12;    // C.ROOT-SERVERS.NET.
> >                192.112.36.4;   // G.ROOT-SERVERS.NET.
> >                193.0.14.129;   // K.ROOT-SERVERS.NET.
> >        };
> >        notify no;
> > };
> 
> Interestingcan any of the root servers be used, or must it be just
> these three?

you can try dig axfr from all of them but many of them don't allow
transfers. I guess he already did it and above is list of servers that do
allow transfers...
-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Rick Dicaire]

On Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson  wrote:
> zone "." {
>        type slave;
>        file "slave/root.slave";
>        masters {
>                192.33.4.12;    // C.ROOT-SERVERS.NET.
>                192.112.36.4;   // G.ROOT-SERVERS.NET.
>                193.0.14.129;   // K.ROOT-SERVERS.NET.
>        };
>        notify no;
> };

Interestingcan any of the root servers be used, or must it be just
these three?

-- 
aRDy Music and Rick Dicaire present:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: root and in-addr.arpa zone transfers

[Rich Goodson]

Michael,

Here's a snippet from my named.conf which does what you're talking  
about.  I use this in our recursive resolvers, but for authoritative  
servers, I find the hints file to be somewhat more robust.
FYI, I stole this originally from the default FreeBSD named.conf file  
that got pushed out with a 6.something update. There was some  
controversy in the FreeBSD mailing lists about it, so I have no idea  
whether it's still used or not.


zone "." {
type slave;
file "slave/root.slave";
masters {
192.33.4.12;// C.ROOT-SERVERS.NET.
192.112.36.4;   // G.ROOT-SERVERS.NET.
193.0.14.129;   // K.ROOT-SERVERS.NET.
};
notify no;
};
zone "arpa" {
type slave;
file "slave/arpa.slave";
masters {
192.33.4.12;// C.ROOT-SERVERS.NET.
192.112.36.4;   // G.ROOT-SERVERS.NET.
193.0.14.129;   // K.ROOT-SERVERS.NET.
};
notify no;
};
zone "in-addr.arpa" {
type slave;
file "slave/in-addr.arpa.slave";
masters {
192.33.4.12;// C.ROOT-SERVERS.NET.
192.112.36.4;   // G.ROOT-SERVERS.NET.
193.0.14.129;   // K.ROOT-SERVERS.NET.
};
notify no;
};


Rich Goodson
Sr. Unix Administrator
Mediacom Communications

On Sep 9, 2009, at 1:23 AM, Michael Monnerie wrote:


Hello,

right now I'm using scripts to download root.zone and in-addr.arpa  
from

internic.net. But this is a non-standard way, I'd prefer to directly
slave and zone-transfer those 2 zones.
Is it possible, and can you show the bind config for these?

Thanks a lot,

mfg zmi
--
// Michael Monnerie, Ing.BSc-  http://it-management.at
// Tel: 0660 / 415 65 31  .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net  Key-ID: 1C1209B4

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users