bind9 Probleme
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tach auch,
ich habe auf meiner debian-box einen bind9-server aufgesetzt um im
lokalen Netzwerk Namen aufzulösen und Anfragen an die "Aussenwelt" an
die Nameserver meines ISPs weiterzureichen. So weit so einfach hab ich
gedacht
Konfiguration ist folgende:
named.conf:
| 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"; };
|
|
| include "/etc/bind/named.conf.local";
named.conf.options:
| acl "ratingen" { { 192.168.60.0/24; 127.0.0.1; 192.168.212.0/24; };
| };
|
|
| options { directory "/var/cache/bind"; pid-file
| "/var/run/bind/named.pid"; forwarders { 212.121.128.10;
| 212.121.128.11; }; forward only; listen-on port 53 { 127.0.0.1;
| 192.168.212.25; }; allow-query { "ratingen"; }; notify no;
| auth-nxdomain no; # conform to RFC1035 heartbeat-interval 2880;
| version "foo!";
|
|
| // 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 { // 0.0.0.0; // };
|
|
| // auth-nxdomain no; # conform to RFC1035
|
|
| };
named.conf.local:
| // // Do any local configuration here //
|
|
| zone "creativ-consulting.local" { type master; file
| "/etc/bind/db.creativ-consulting"; }; zone "212.168.192.in-addr-arpa"
| { type master; file "/etc/bind/db.192.168.212"; };
|
|
| // Consider adding the 1918 zones here, if they are not used in your
| // organization // include "/etc/bind/zones.rfc1918";
db.creativ-consulting:
| $TTL 7200 ;2hours
|
|
| creativ-consulting.local. IN SOA ns
| root.creativ-consulting.local. ( 2003091721;serial 10800 ;refresh
| (3 hours) 3600 ;retry (1 hour) 604800 ;expire (1 week) 86400
| ;minimum (1 day) ) IN NS ns
|
|
| ns IN A 192.168.212.25 router
| IN A 192.168.212.250 titom-x IN
| A 192.168.212.23 compaq IN CNAME
| ns
db.192.168.212:
| $TTL 7200 ;2hours 212.168.192.in-addr.arpa. IN SOA
| ns.creativ-consulting.local. root.creativ-consulting.local. (
| 2003091611;serial 10800 ;refresh (3 hours) 3600 ;retry (1 hour)
| 604800 ;expire (1 week) 86400 ;minimum (1 day) ) NS
| ns.creativ-consulting.local.
|
|
| 1 IN PTR ns.creativ-consulting.local.
| 2 IN PTR
| router.creativ-consulting.local. 3 IN
| PTR titom-x.creativ-consulting.local.
Das alles klappt auch wunderbar wenn ich auf der linux-box selbst
versuche die Namen aufzulösen.
Von jeder anderen Maschine im Netzwerk werden die lokalen Namen nicht
gefunden (Auflösung externer Namen klappt aber).
Um dieses Posting noch länger zu machen hier mal ein Mitschnitt der
Anfragen aus der Logdatei:
Anfrage des Hosts "192.168.212.23":
| Sep 17 11:31:20.453 client 192.168.212.23#49268: UDP request Sep 17
| 11:31:20.453 client 192.168.212.23#49268: using view '_default' Sep
| 17 11:31:20.453 client 192.168.212.23#49268: request is not signed
| Sep 17 11:31:20.453 client 192.168.212.23#49268: recursion available:
| approved Sep 17 11:31:20.453 client 192.168.212.23#49268: query Sep
| 17 11:31:20.453 client 192.168.212.23#49268: v6 synthesis denied Sep
| 17 11:31:20.453 client 192.168.212.23#49268: query (cache) approved
| Sep 17 11:31:20.453 client 192.168.212.23#49268: replace Sep 17
| 11:31:20.453 clientmgr @0x80c0dd0: createclients Sep 17 11:31:20.454
| clientmgr @0x80c0dd0: create new Sep 17 11:31:20.454 client
| @0x80927d0: create Sep 17 11:31:20.454 createfetch:
| 25.212.168.192.in-addr.arpa PTR Sep 17 11:31:20.454 fctx 0x8092f00:
| create Sep 17 11:31:20.454 fctx 0x8092f00: join Sep 17 11:31:20.454
| fetch 0x80cd090 (fctx 0x8092f00): created Sep 17 11:31:20.454 client
| @0x80927d0: udprecv Sep 17 11:31:20.454 fctx 0x8092f00: start Sep 17
| 11:31:20.454 fctx 0x8092f00: try Sep 17 11:31:20.454 fctx 0x8092f00:
| cancelqueries Sep 17 11:31:20.454 fctx 0x8092f00: getaddresses Sep 17
| 11:31:20.454 fctx 0x8092f00: query Sep 17 11:31:20.455 resquery
| 0x80e40b0 (fctx 0x8092f00): send Sep 17 11:31:20.455 resquery
| 0x80e40b0 (fctx 0x8092f00): sent Sep 17 11:31:20.455 resquery
| 0x80e40b0 (fctx 0x8092f00): senddone Sep 17 11:31:20.505 resquery
| 0x80e40b0 (fctx 0x8092f00): response Sep 17 11:31:20.505 fctx
| 0x8092f00: noanswer_response Sep 17 11:31:20.505 fctx 0x8092f00:
| ncache_message Sep 17 11:31:20.505 fctx 0x8092f00: cancelquery Sep 17
| 11:31:20.505 fctx 0x8092f00: done Sep 17 11:31:20.505 fctx 0x8092f00:
| stopeverything Sep 17 11:31:20.505 fctx 0x8092f00: cancelqueries Sep
| 17 11:31:20.505 fctx 0x8092f00: sendevents Sep 17 11:31:20.505 fetch
| 0x80cd090 (fctx 0x8092f00): destroyfetch Sep 17 11:31:20.505 fctx
| 0x8092f00: shutdown Sep 17 11:31:20.505 client 192.168.212.23#49268:
| send Sep 17 11:31:20.506 client 192.168.212.23#49268: sendto Sep 17
| 11:31:20.506 client 192.168.212.23#49268: senddone Sep 17
| 11:31:20.506 client 192.168.212.23#49268: next Sep 17 11:31:20.506
| client 192.168.212.23#49268: endrequest Sep 17 11:31:20.506 fctx
| 0x8092f00: doshutdown Sep 17 11:31:20.506 fctx 0x8092f00:
| stopeverything Sep 17 11:31:20.506 fctx 0x8092f00: cancelqueries Sep
| 17 11:31:20.506 fctx 0x8092f00: destroy
Und die (richtig beantwortete Anfrage) von der Linuxkiste selbst:
| Sep 17 11:32:47.521 client 192.168.212.25#32781: UDP request Sep 17
| 11:32:47.521 client 192.168.212.25#32781: using view '_default' Sep
| 17 11:32:47.521 client 192.168.212.25#32781: request is not signed
| Sep 17 11:32:47.521 client 192.168.212.25#32781: recursion available:
| approved Sep 17 11:32:47.521 client 192.168.212.25#32781: query Sep
| 17 11:32:47.521 client 192.168.212.25#32781: query
| 'ns.creativ-consulting.local/IN' approved Sep 17 11:32:47.522 client
| 192.168.212.25#32781: send Sep 17 11:32:47.532 client
| 192.168.212.25#32781: sendto Sep 17 11:32:47.533 client
| 192.168.212.25#32781: senddone Sep 17 11:32:47.533 client
| 192.168.212.25#32781: next Sep 17 11:32:47.533 client
| 192.168.212.25#32781: endrequest Sep 17 11:32:47.533 client
| @0x80927d0: udprecv
Hat von Euch jemand ne Idee was da los ist?
Danke,
- --
Thomas Liesner - c/o Creativ Consulting GmbH, Ratingen
Email: t.liesner@creativ-consulting.de
PGP Fingerprint: 7B6B 8364 D205 0FA2 8753 AEE0 70B7 AB3A 06B5 F368
PGP Public Key: http://www.creativ-consulting.de/keys
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQE/aW27cLerOga182gRAvk/AJ0V+2l7v5+DKc7bML1CH+5M/5taWgCgsKbY
gHTgV6tW+K33K1DRf8t0KoQ=
=rWXN
-----END PGP SIGNATURE-----
Reply to: