BIND 9, ISC DHCPD und DNS Dynamic Update
Hallo Liste!
Ich habe mich heute mit der Frage DHCP und DNS Dynamic Update auseinander
gesetzt.
Folgende Ausgangslage:
Ein Server mit Debian testing. Hier läuft BIND 9 und ISC DHCPD
(isc-dhcpd-V3.1.0).
In Bind habe ich folgende Einstellungen:
root@marche:~# cat /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };
// From the release notes:
// Because many of our users are uncomfortable receiving undelegated answers
// from root or top level domains, other than a few for whom that behaviour
// has been trusted and expected for quite some length of time, we have now
// introduced the "root-delegations-only" feature which applies
delegation-only
// logic to all top level domains, and to the root domain. An exception list
// should be specified, including "MUSEUM" and "DE", and any other top level
// domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };
include "/etc/bind/named.conf.local";
root@marche:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "dlstest" IN {
type master;
file "/var/lib/bind/master/dlstest.zone";
allow-update {
127.0.0.1;
192.168.1.0/24;
};
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "/var/lib/bind/master/192.168.1.zone";
allow-update {
127.0.0.1;
192.168.1.0/24;
};
};
root@marche:~# cat /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
195.3.96.67;
195.3.96.68;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
DHCP habe ich wie folgt eingstellt:
root@marche:~# cat /etc/dhcp3/dhcpd.conf
#
# Sample configuration file for ISC dhcpd for Debian
#
# $Id: dhcpd.conf,v 1.1.1.1 2002/05/21 00:07:44 peloy Exp $
#
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
#
# The style parameter must be one of ad-hoc, interim or none. The
# ddns-update-style statement is only meaningful in the outer scope - it
# is evaluated once after reading the dhcpd.conf file, rather than each
# time a client is assigned an IP address, so there is no way to use
# different DNS update styles for different clients.
ddns-update-style interim;
# option definitions common to all supported networks...
option domain-name "dlstest";
option domain-name-servers ns1.dlstest, ns2.dlstest, ns3.dlstest;
default-lease-time 600;
min-lease-time 60;
max-lease-time 14400;
# Update DNS server zones
zone dlstest. {
primary 127.0.0.1;
}
zone 1.168.192.in-addr.arpa. {
primary 127.0.0.1;
}
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.50 192.168.1.100;
default-lease-time 1800;
allow booting;
allow bootp;
option routers router1.dlstest;
}
group {
next-server marche.dlstest;
filename "/pxelinux.0";
# host client-001.install.dlstest {
# hardware ethernet 00:0c:29:86:1a:fc;
# fixed-address client-001.install.dlstest;
# }
# host client-002.install.dlstest {
# hardware ethernet 00:0c:29:bc:58:de;
# fixed-address client-002.install.dlstest;
# }
# host client-003.install.dlstest {
# hardware ethernet 00:04:75:80:73:71;
# fixed-address client-003.install.dlstest;
# }
}
Beim einem kurzen Test erhalte ich folgendes Ergebnis:
root@marche:~# nsupdate
> update add basilicata.dlstest. 300 A 192.168.1.50
> send
update failed: SERVFAIL
> quit
Weiß jemand wo der Fehler vermutlich liegt oder zumindest wo er liegen könnte?
LG,
Leonhard
PS: Habe jetzt noch ein letztes mal Google angeworfen (mit "update failed:
SERVFAIL") und bin auf diesen Thread gestoßen:
https://internal.lboro.ac.uk/mail/public/lulu/2006-03/msg00011.html
Ich kann mir gut vorstellen, dass es auch hier ein Berechtigungsproblem gibt.
Schließlich muss BIND sein Journal schreiben.
Frage: Weiß jemand, wo BIND sein Journal (für DDNS) hinschreiben will?
Reply to: