Einzelne Hosts über Bind9 nicht auflösbar

TiTux

New Member
Einzelne Hosts über Bind9 nicht auflösbar [gelöst]

Servus,

habe hier auf meinem CentOS Server bind9 installiert. Der Dienst läuft und ich habe testhalber ein paar Hosteinträge drin,
bis jetzt noch alles ausschließlich lokal im eigenen Netzwerk. Hier mal die Konfig der Forward-Zone:
Code:
$TTL 3600
@        IN     SOA    centos.homebase.local. titux1.gmx.de. (
                                2015042001  ;    Serial
                                3H          ;    refresh after 3 hours
                                1H          ;    retry after 1 hour
                                1W          ;    expire after 1 week
                                1D)         ;    minimum TTL of 1 day

; Name Server

                        IN      NS              centos.homebase.local.  ; lokal

; Hostnamen

centos                  IN      A               192.168.100.122
inv                     IN      A               192.168.100.57
dx800a                  IN      A               192.168.100.210
hom-swt-001             IN      A               192.168.100.230
lancom-wlan54g          IN      A               192.168.100.253
hom-wks-001             IN      A               192.168.100.105
x200t                   IN      A               192.168.100.110
lancom-1711             IN      A               192.168.100.254
Meine named.conf sieht so aus:
Code:
//

options {
        listen-on port 53 { 127.0.0.1; 192.168.100.122; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; };

        /*
         - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
         - If you are building a RECURSIVE (caching) DNS server, you need to enable
           recursion.
         - If your recursive DNS server has a public IP address, you MUST enable access
           control to limit queries to your legitimate users. Failing to do so will
           cause your server to become part of large scale DNS amplification
           attacks. Implementing BCP38 within your network would greatly
           reduce such attack surface
        */
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

zone "homebase.local" {
        type master;
        file "db.homebase.local";
};

zone "100.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.100";
};

Die 3 Windows-Hosts inv, hom-wks-001 und x200t können sich untereinander via dem Hostnamen anpingen,
funktioniert also. Alle anderen Geräte kann ich nicht auflösen, dx800a ist z.B. ein Siemens Telefon,
lancom-1711 mein Lancom Router und auch der Switch hom-swt-001 funktioniert nicht.

Der CentOS Server selber kann alle eingetragenen Hostnamen erfolgreich pingen.
Er selber kann von einem Windows-Client aus nicht per DNS aufgelöst werden.

Ich verstehe noch nicht, weshalb das nur unter den Windows-Maschinen funktioniert, wer kann mir
da auf die Sprünge helfen?

Gruß
TiTux
 
Last edited by a moderator:
Mal is Blaue hinein geraten: Die Windows-Hosts benutzen deinen DNS-Server nicht. Deshalb könne sie nichts auflösen, was nicht Windows ist. Die anderen Windows-Kisten bekommen sie aufgelöst per Windows-eigenem Discovery-Protokoll.
 
Um den DNS zu überprüfen ist Ping nur zweite Wahl.

Nimm mal ein dafür vorgesehenes Tool - also

host <hostname> <dns-server-ip>
dig @<dns-server-ip> <hostname>
nslookup <hostname> <dns-server-ip>

nslookup gibt es auch auf den Windows-Kisten.

Wenn das läuft, analog elias5000 Hinweis: Sauber DNS Konfigurieren. Ggf. kannst du ja gleich den DHCP-Server auf den DNS-Server packen...

Gruß
Markus
 
Also ich habe jetzt auf homebase.test umgestellt. An dem Problem hat sich leider nichts geändert. Auch Linux-Clients, was ich gestern noch nicht getestet hatte, bekommen keine Verbindung. Eingetragen ist bei den Clients nur der eine CentOS DNS-Server.

Befehle auf dem CentOS-Server (bind Installation):

Code:
[root@centos ~]# [B]dig  axfr homebase.test @localhost
[/B]
; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.1 <<>> axfr homebase.test @localhost
;; global options: +cmd
homebase.test.          3600    IN      SOA     centos.homebase.test. post.invenient.de. 2015042001 10800 3600 604800 86400
homebase.test.          3600    IN      NS      centos.homebase.test.
centos.homebase.test.   3600    IN      A       192.168.100.122
dx800a.homebase.test.   3600    IN      A       192.168.100.210
hom-swt-001.homebase.test. 3600 IN      A       192.168.100.230
hom-wks-001.homebase.test. 3600 IN      A       192.168.100.105
inv.homebase.test.      3600    IN      A       192.168.100.57
lancom-1711.homebase.test. 3600 IN      A       192.168.100.254
lancom-wlan54g.homebase.test. 3600 IN   A       192.168.100.253
x200t.homebase.test.    3600    IN      A       192.168.100.110
homebase.test.          3600    IN      SOA     centos.homebase.test. post.invenient.de. 2015042001 10800 3600 604800 86400
;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Di Apr 21 11:38:26 CEST 2015
;; XFR size: 11 records (messages 1, bytes 337)

Code:
[root@centos ~]# [B]host inv 192.168.100.122[/B]
Using domain server:
Name: 192.168.100.122
Address: 192.168.100.122#53
Aliases:

inv.homebase.test has address 192.168.100.57

Code:
[root@centos ~]# [B]nslookup inv 192.168.100.122[/B]
Server:         192.168.100.122
Address:        192.168.100.122#53

Name:   inv.homebase.test
Address: 192.168.100.57

Auf einem Linux-Client:

Code:
root@debian:~# [B]host inv 192.168.100.122[/B]
;; connection timed out; no servers could be reached

Code:
root@debian:~# [B]dig @192.168.100.122 inv[/B]

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @192.168.100.122 inv
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Code:
root@debian:~# [B]nslookup inv 192.168.100.122[/B]
;; connection timed out; no servers could be reached

Wenn ich mit nmap einen Scan auf den Server mache, wird mir kein offener DNS-Server Port 53 angezeigt,
sollte doch eigentlich auftauchen? Der Dienst läuft ja definitiv. Aber auch auf den Windows-Clients gibt ein nslookup nur ein:

DNS request time out
Server: UnKnow
Address: 192.168.100.122

Habe die folgenden iptables Regeln in der iptables-config mit aufgenommen:

Code:
# Bind9 Konfig
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

Hmpf, irgendwo liegt noch der Hund begraben.
 
Also scheinen die Clients den Server nicht erreichen zu können.
Auf Anfang:

Client:
ifconfig -a
ip route show
cat /etc/resolv.conf

Server
netstat -tulpen (als root)

Gruß
Markus
 
Hi Markus,

erstmal Danke für Deine Hilfe!

Debian ist in diesem Fall der Client, centos der Server:

Code:
[B]root@debian:~# ifconfig -a[/B]

eth0      Link encap:Ethernet  Hardware Adresse 00:0c:29:11:3d:a6
          inet Adresse:192.168.100.238  Bcast:192.168.100.255  Maske:255.255.255.0
          inet6-Adresse: fe80::20c:29ff:fe11:3da6/64 G▒ltigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:2622 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1279 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenl▒nge:1000
          RX bytes:288149 (281.3 KiB)  TX bytes:179448 (175.2 KiB)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 G▒ltigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenl▒nge:0
          RX bytes:272 (272.0 B)  TX bytes:272 (272.0 B)

___________________________________________________________________________

[B]root@debian:~# ip route show[/B]

default via 192.168.100.254 dev eth0
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.238

___________________________________________________________________________

[B]root@debian:~# cat /etc/resolv.conf[/B]

domain homebase.test
search homebase.test
nameserver 192.168.100.122

Code:
[B][root@centos ~]# netstat -tulpen[/B]

Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Benutzer   Inode      PID/Program name
tcp        0      0 192.168.100.122:53      0.0.0.0:*               LISTEN      25         18606      1895/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      25         18604      1895/named
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          17938      1280/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          19202      2372/master
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      25         18651      1895/named
tcp6       0      0 ::1:53                  :::*                    LISTEN      25         18608      1895/named
tcp6       0      0 :::22                   :::*                    LISTEN      0          17940      1280/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      0          19203      2372/master
tcp6       0      0 ::1:953                 :::*                    LISTEN      25         18652      1895/named
udp        0      0 192.168.100.122:53      0.0.0.0:*                           25         18605      1895/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           25         18603      1895/named
udp6       0      0 ::1:53                  :::*                                25         18607      1895/named
 
Das sieht auf den ersten Blick schon mal nicht schlecht aus.

Kannst du mal die gesamte iptables-regeln posten?

iptables -L -n

Ansonsten, wie sieht das Netzwerk verkabelungstechnisch aus. Direkt an einem Switch oder was hast du da vorliegen?

Gruß
Markus
 
Also der Server als auch der Debian Client laufen in einer VmWare Umgebung im Bridge-Modus, also ganz normal mit eigener IP. Die VmWare Workstation hängt an einem Switch, der hängt am Lancom Router (GW) und der wiederum am Kabelmodem.

Hier die Ausgabe von iptables -L -n:

Code:
[root@centos ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
INPUT_direct  all  --  0.0.0.0/0            0.0.0.0/0
INPUT_ZONES_SOURCE  all  --  0.0.0.0/0            0.0.0.0/0
INPUT_ZONES  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
FORWARD_direct  all  --  0.0.0.0/0            0.0.0.0/0
FORWARD_IN_ZONES_SOURCE  all  --  0.0.0.0/0            0.0.0.0/0
FORWARD_IN_ZONES  all  --  0.0.0.0/0            0.0.0.0/0
FORWARD_OUT_ZONES_SOURCE  all  --  0.0.0.0/0            0.0.0.0/0
FORWARD_OUT_ZONES  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
OUTPUT_direct  all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD_IN_ZONES (1 references)
target     prot opt source               destination
FWDI_public  all  --  0.0.0.0/0            0.0.0.0/0           [goto]
FWDI_public  all  --  0.0.0.0/0            0.0.0.0/0           [goto]

Chain FORWARD_IN_ZONES_SOURCE (1 references)
target     prot opt source               destination

Chain FORWARD_OUT_ZONES (1 references)
target     prot opt source               destination
FWDO_public  all  --  0.0.0.0/0            0.0.0.0/0           [goto]
FWDO_public  all  --  0.0.0.0/0            0.0.0.0/0           [goto]

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
target     prot opt source               destination

Chain FORWARD_direct (1 references)
target     prot opt source               destination

Chain FWDI_public (2 references)
target     prot opt source               destination
FWDI_public_log  all  --  0.0.0.0/0            0.0.0.0/0
FWDI_public_deny  all  --  0.0.0.0/0            0.0.0.0/0
FWDI_public_allow  all  --  0.0.0.0/0            0.0.0.0/0

Chain FWDI_public_allow (1 references)
target     prot opt source               destination

Chain FWDI_public_deny (1 references)
target     prot opt source               destination

Chain FWDI_public_log (1 references)
target     prot opt source               destination

Chain FWDO_public (2 references)
target     prot opt source               destination
FWDO_public_log  all  --  0.0.0.0/0            0.0.0.0/0
FWDO_public_deny  all  --  0.0.0.0/0            0.0.0.0/0
FWDO_public_allow  all  --  0.0.0.0/0            0.0.0.0/0

Chain FWDO_public_allow (1 references)
target     prot opt source               destination

Chain FWDO_public_deny (1 references)
target     prot opt source               destination

Chain FWDO_public_log (1 references)
target     prot opt source               destination

Chain INPUT_ZONES (1 references)
target     prot opt source               destination
IN_public  all  --  0.0.0.0/0            0.0.0.0/0           [goto]
IN_public  all  --  0.0.0.0/0            0.0.0.0/0           [goto]

Chain INPUT_ZONES_SOURCE (1 references)
target     prot opt source               destination

Chain INPUT_direct (1 references)
target     prot opt source               destination

Chain IN_public (2 references)
target     prot opt source               destination
IN_public_log  all  --  0.0.0.0/0            0.0.0.0/0
IN_public_deny  all  --  0.0.0.0/0            0.0.0.0/0
IN_public_allow  all  --  0.0.0.0/0            0.0.0.0/0

Chain IN_public_allow (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW

Chain IN_public_deny (1 references)
target     prot opt source               destination

Chain IN_public_log (1 references)
target     prot opt source               destination

Chain OUTPUT_direct (1 references)
target     prot opt source               destination
 
Bist du dir sicher, dass du die Bridge-Konfiguration sauber drin hast und nicht beim irgendwo eine NAT-Konfig drin hast?

Bin jetzt nicht der iptables-Spezi, aber sieht ganz gut aus. Evtl. mal testweise ausschalten?

Gruß
Markus
 
Hi Markus,

Problem konnte mittlerweile gelöst werden. Ich hatte den Bind nochmal auf einem anderen System (keine virtuelle Maschine) aufgesetzt, um sicher zu gehen, aber das war nicht das Problem.

Ab CentOS 7 läuft kein Iptables mehr, sondern FirewallD, dass kannte ich noch gar nicht und das hat den DNS-Port erstmal dicht gemacht. Keine Ahnung, weshalb der iptables Befehle trotzdem soviel Output gezeigt hat, da er ja eigentlich abgeschaltet war. Ich hatte ihn dann wieder aktiviert und den Port 53 für TCP u. UDP freigemacht. Dann ging's aber immer noch nicht.

In einem anderen Forum wurde ich darauf hingewiesen, dass ich noch nicht die:

Code:
allow-query
Option angepasst hätte, die hat nämlich noch "localhost" als Wert. Den habe ich dann auf mein Netzwerk angepasst u. danach funktionierte alles wie gewünscht.

Danke für Deine Hilfe!

Schönes Wochenende
TiTux
 
Back
Top