I have setup Bind caching server but why do i cannot see any records
cached in the bind server ? Pls advise. Thanks
Regards
Daniel

Sun, 01 Jan 2006 17:04:22 +0100, Daniel <Danieltbt05@gmail.comwrote:
I have setup Bind caching server but why do i cannot see any records
cached in the bind server ? Pls advise. Thanks
Provide more information.
-Enrique

Sun, 01 Jan 2006 08:04:22 -0800, Daniel wrote:

I have setup Bind caching server but why do i cannot see any records
cached in the bind server ? Pls advise. Thanks

# rndc dumpdb

The file named_dump.db, containing the cache, will be created in the
directory where your zone files reside.

Sun, 01 Jan 2006 19:55:22 +0100, Michael Heiming wrote:

In comp.os.linux.misc Dave Uhring <daveuhring@yahoo.com>:

># rndc dumpdb
>
>The file named_dump.db, containing the cache, will be created in the
>directory where your zone files reside.
>
Presuming you run bind >9.2 (or so), rndc/named are already
configured for the purpose, yes.

s/9.2/9.0/

Sun, 01 Jan 2006 21:41:22 +0100, Michael Heiming wrote:

In comp.os.linux.misc Dave Uhring <daveuhring@yahoo.com>:
>Sun, 01 Jan 2006 19:55:22 +0100, Michael Heiming wrote:

Presuming you run bind >9.2 (or so), rndc/named are already
configured for the purpose, yes.
>
>s/9.2/9.0/
>
Iirc not with 9.0 dumpdb wasn't available to rndc.

Perhaps, I seldom use that command, although I'm somewhat certain that
dumpdb was available in the first BIND-9 release.

In either case it is probable that the P is running a recent distro with
BIND-9.2.X. course, it was too much trouble for the P to indicate
just what nameserver daemon he was using.

Sun, 01 Jan 2006 15:12:42 -0500, Jean-David Beyer wrote:

Dave Uhring wrote:

># rndc dumpdb
>>
>The file named_dump.db, containing the cache, will be created in the
>directory where your zone files reside.
>>
It does not work for me because I am running in chroot mode with named
running as named, not root. named can read anything it wants up there, but
it cannot write or create files. I would have to allow named to write up
there, which is a (small) security risk.

If you run DDNS you are going to have to allow user named to write to the
directory where the zone files reside.

[~]# cd /var/named/namedb
[namedb]# ls -l
total 644
-rw-r 1 named named 198 Feb 20 2004 127.0.0.rev
-rw 1 named named 687 Jan 1 04:03 192.168.0.rev
-rw-r 1 named named 204591 Jan 1 03:48 192.168.0.rev.jnl
-rw-r 1 named named 2517 Feb 17 2004 db.cache
-rw-r 1 root named 2517 Jan 28 2004 named.root
-rw-r 1 named named 103977 Jan 1 12:31 named_dump.db
-rw 1 named named 646 Jan 1 04:03 localnet.tld
-rw-r 1 named named 288231 Jan 1 03:48 localnet.tld.jnl

Sun, 01 Jan 2006 19:07:35 -0500, Jean-David Beyer wrote:

I do not want to make the directory writable by named (bind-9.2.4-7_EL3)
because if something is wrong with it and a black hat compromises it, he
would re-write stuff up there, and that would make matters worse. Too bad
there is not a command line option to tell it where to write. I could make a
directory in the chroot area where it would be safe for named to write.

The user named has no shell and cannot overwrite much of anything.
Besides, if you run two nameservers automatic update of the secondary
cannot be accomplished unless user named can write to the zone records.

course, if you are running only one nameserver on your local network
this is not a consideration. Nor does user named require write access if
you do not use DHCP and dynamic DNS.

Mon, 02 Jan 2006 04:07:46 +0100, Jean-David Beyer <jdbeyer@exit109.comwrote:

Dave Uhring wrote:
>Sun, 01 Jan 2006 19:07:35 -0500, Jean-David Beyer wrote:
>>
>>
I do not want to make the directory writable by named (bind-9.2.4-7_EL3)
because if something is wrong with it and a black hat compromises it, he
would re-write stuff up there, and that would make matters worse. Too bad
there is not a command line option to tell it where to write. I could make a
directory in the chroot area where it would be safe for named to write.
>>
>>
>The user named has no shell and cannot overwrite much of anything.
>Besides, if you run two nameservers automatic update of the secondary
>cannot be accomplished unless user named can write to the zone records.
>
Yes he probably can. Consider the following hypothetical case, which is the
only reason to run something like named in a chroot environment:

There is a bug in named that a cracker discovers. By sending an
"appropriate" request to named, he manages to get it to re-write the zone
files to make you innocently go to his infernal servers instead of the ones
you want

Now if named is in chroot area where it has no write permission, this bug
would be harmless (other than denial of service possibilities).

Now the solution is for named to pick up another directory where it could
write the named dbdump file, or even have the named program specify it to be
in, say, /var/named/dbdumpdir, for example, that could be owned by named
( course, this would be the /var/named/dbdumpdir in the chroot environment.)
>>
>course, if you are running only one nameserver on your local network
>this is not a consideration. Nor does user named require write access if
>you do not use DHCP and dynamic DNS.

Now I have seen repeated in this thread that there is no way to control
what file (actually what directory) named dumps its data to. Jean-David
is right, it is possible, and here is how you do it.

A few lines from my /etc/named.conf:

< cut here <
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
< cut here <

My named runs in a chroot jail, and the paths are relative to its root.

Next, if there is a bug in named and a cracker exploits it, I presume
there will be damage, not only dos, but clients of that instance of named
will be directed to the the crackers "infernal sites", even if the zone files
are not writable, until named is rebooted or reloaded.

Suppose named runs in a chroot jail and has write access to the zone files,
and assume there is a good copy of the zone files outside the jail, and assume
the startup script wipes the jail clean and populates it from the good copy
each time named is restarted. What is the difference?

There is a difference I can see, if you use a SIGHUP or rndc reload, the zone files
will not be restored from the good copy. But you can change your procedures.
-Enrique

hi, i have setup caching name server in bind server 9.2.4 but where are
those cached records ? forward zone ? I point my dns server to myself.
Rgds
Daniel

Hi, so it won't display cached records in bind server directly ? maybe
i used windows dns too much ;) .
Rgds
Daniel

Mon, 02 Jan 2006 16:37:20 +0100, Daniel <Danieltbt05@gmail.comwrote:

hi, i have setup caching name server in bind server 9.2.4 but where are
those cached records ? forward zone ? I point my dns server to myself.

The records are in memory (ram).

If you set up rndc and a few other things properly, you can ask
named to write the records to a file. "rndc dumpdb" The file is
usually written to /var/named/cache_dump.db, but that can be
changed in /etc/named.conf, look for a "dump-file" option. If the
server runs in a chroot jail, the path is relative to the jail root.

Forward zone? If it's caching, it does not use zone files. I don' know
how the in-memory data are structured, I guess the structure of the
dump file should give a hint at that.

"point my dns server to my self"? I don't understand. "Point"?
"Yourself"?
-Enrique

Mon, 02 Jan 2006 15:58:34 +0100, Jean-David Beyer <jdbeyer@exit109.comwrote:

Enrique Perez-Terron wrote:
>Now I have seen repeated in this thread that there is no way to control
>what file (actually what directory) named dumps its data to. Jean-David
>is right, it is possible, and here is how you do it.
>>
>>
>A few lines from my /etc/named.conf:
>>
>< cut here <
>options {
>directory "/var/named";
>dump-file "/var/named/data/cache_dump.db";
>statistics-file "/var/named/data/named_stats.txt";
>< cut here <
>>
>
1.) Where did you find that? I could not find it in "DNS and BIND" 4th
Edition" by Albitz & Liu. Is there a more recent edition?

Some weeks ago I read the manpage, which refuses to discuss the config file,
as it is too complex, but has a short discussion about selinux and
chroot security, and mentions putting the dump file elsewhere.

For the config file, it refers to

BIND 9 Administrator Reference Manual. (ARM)
The ARM is shipped in /usr/share/doc/bind-9*/arm/Bv9ARM.html

2.) My /etc/sysconfig/named looks like this:

# Currently, you can use the following options:
# RTDIR="/some/where" -- will run named in a chroot environment.
# you must set up the chroot environment before
# doing this.
#RTDIR=/var/named
RTDIR=/srv/named

# PTINS="whatever" -- These additional options will be passed to named
# at startup. Don't add -t here, use RTDIR instead.

So (now) my named.conf file, in /srv/named/etc, says this, since by the time
it reads this file, it is already in the chroot mode.

// N.B.: we are invoked in chroot environment /var/named:
options {
directory "/";
listen-on { "internal"; };
allow-query { "internal"; };
allow-recursion { "internal"; };
max-refresh-time 86400;// refresh should never be more than a day
min-refresh-time 3600;// or less than an hour
cleaning-interval 113;// minutes: server not very busy.
interface-interval 59;// minutes: dial-up interface.
dump-file "/var/named/data/cache_dump.db";

You too have a "data" subdirectory.

statistics-file "/var/named/data/named_stats.txt";
};

Check if you have a directory (/svr/named/var/named/data, and make it writable. :)

-Enrique

This is what inside my named.conf . Yes my server is running chroot
jail even i search in the chroot path. But i can't find the file
cache_dump.db.

options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";

Rgds
Daniel

Tue, 03 Jan 2006 17:08:57 +0100, Daniel <Danieltbt05@gmail.comwrote:

This is what inside my named.conf . Yes my server is running chroot
jail even i search in the chroot path. But i can't find the file
cache_dump.db.

It is only written on demand

options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";

You need to 1) set up rndc keys, 2) make sure named uses the keys,
3) restart named, then 4) use the command "rndc dumpdb".

Caveat: not tested.

Long time ago, one could get a a dump by sending SIGUSR1 (iirc),
but now it seems you have to use rndc, which I have never tried.
-Enrique