BIND DNS-Server löst nicht auf

[Brandenburger]

Hallo,

ich habe auf meinem NAS mit Openmedialvault (statisch:192.168.0.10) ein Docker mit BIND-Dns aufgesetzt (listen on 192.168.0.10:53)

Der DNS ist auch aufrufbar mit WebMin über 192.168.0.10:10000

In meinem Router habe ich BIND als DNS mit 192.168.0.10 konfiguriert (cloudflare als 2. DNS)

Wenn ich prüfe:

; <<>> DiG 9.10.6 <<>> @192.168.0.1 nas.tst.lan
; (1 server found)
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53271
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

...

;; ANSWER SECTION:
nas.tst.lan.    38400    IN    A    192.168.0.10

;; Query time: 45 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sun Dec 27 11:59:19 CET 2020
;; MSG SIZE  rcvd: 63

PROBLEM:
Wenn ich die URL im Browser eingebe, passiert gar nichts.

Es kommt:

Versuchen Sie Folgendes:​

• Changing DNS over HTTPS settings

DNS_PROBE_FINISHED_NXDOMAIN

DNS ist im MAC auf den Router gestellt und im Router ist als primary 192.168.0.10 definiert.

Was passiert hier?

Beste Grüße

 

[Chris_S04]

Ohne das Zonenfile zu kennen wird es schwierig.
I.d.R. sollte im Zonenfile aber ein NS Record stehen an den die Anfragen weitergeleitet werden, wenn Bind sie nicht selbst auflösen kann.

Hast du in Bind noch eine Zonenkonfiguration erstellt, in der eine interne und eine externe Zone definiert sind, z.B. 192.168.0.0/24 als intern und 0.0.0.0/0 als extern?
Evtl. fehlen hier der internen Zone Berechtigungen.

 

[Brandenburger]

Danke für Antwort.

Ich habe es über das Webinterface von Webmin gemacht.

Das local zonefile sieht so aus:

zone "tst.lan" {
    type master;
    file "/var/lib/bind/tst.lan.hosts";
    };

das default zone file sieht so aus:

// prime the server with knowledge of the root servers
zone "." {
    type hint;
    file "/usr/share/dns/root.hints";
};


// 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";
};

mein options file sieht so aus:

options {
    directory "/var/cache/bind";


    dnssec-validation auto;


    listen-on-v6 { any; };
    
    forwarders {
        1.1.1.1;
        1.0.0.1;
        };
    allow-query {
        192.168.0.0/24;
        };
    recursion yes;                 # enables resursive queries
    allow-recursion {
        trusted;
        };
    
};
    acl "trusted"   { 192.168.0.0/24; };

 

[Chris_S04]

Ja das ist in Ordnung, der DNS soll ja der Master sein.
Aber du hast sicher ein Zonenfile, in der deine A-Records, CNAMEs, etc. drin stehen. Z.B. sowas:
example.com IN A 192.168.0.222
Oder sowas eben.
Hier müsste auch ein NS-Record stehen, an den Anfragen weitergeleitet werden, z.B.
@ IN NS deine.Fritzbox.
Außerdem musst du in der named.conf.options eine ACL mit vertrauenswürdigen Clients anlegen, in deinem Fall vermutlich 192.168.0.0/24 und dort die DNS Forwarder festlegen, also z.B. Google 8.8.8.8 oder Cloudflare 1.1.1.1

Ist leider schon etwas her, dass ich Mal einen Bind aufgesetzt habe und seitdem steht der Ecke und tut was er soll, bin deshalb etwas eingerostet, sorry

Schau Mal hier, das ist ganz gut dokumentiert:
https://wiki.ubuntuusers.de/DNS-Server_Bind/#Konfiguration-IPv4-IPv6

 

[RalphS]

Keine Ahnung wie das mit dem Dockerimage aussieht, daher:

• Irgendwelche Zonen re: 0.0.0.0 oder sowas vergessen
• Prüfen wie die Forwarder-Konfiguration aussieht.

Evtl schießt auch der DNS Client Cache quer. Dann irgendwo (in Windows) ipconflg /flushdns sagen.

Protip: Unter der Kommandozeile kann man mit nslookup <FQDN> 192.168.0.10 direkt schauen was der DNS-Dienst wie auflöst.

 

[Raijin]

Der DNS ist auch aufrufbar mit WebMin über 192.168.0.10:10000

Das ist aber nicht der DNS, sondern eben Webmin, zwei Paar Schuhe. Prüfe mit "nslookup computerbase.de 192.168.0.10" ob der DNS-Dienst selbst auch tatsächlich erreichbar ist.

Bei Docker muss man ein paar Dinge bedenken. Docker erzeugt ein internes virtuelles Subnetz im Host und das kann bei der Konfiguration der Firewall einiges ändern, wenn man nicht aufpasst. Ein nativ gehosteter Dienst wäre stets über die INPUT-Chain der Firewall geregelt. Bei Docker wird der Dienst aber in besagtes virtuelles Subnetz weitergeleitet und somit ist plötzlich die FORWARD-Chain entscheidend. Unter Umständen wird also der DNS-Dienst einfach von der Firewall geblockt.

 

[Brandenburger]

Ja das ist in Ordnung, der DNS soll ja der Master sein.
Aber du hast sicher ein Zonenfile, in der deine A-Records, CNAMEs, etc. drin stehen. Z.B. sowas:
example.com IN A 192.168.0.222
Oder sowas eben.
Hier müsste auch ein NS-Record stehen, an den Anfragen weitergeleitet werden, z.B.
@ IN NS deine.Fritzbox.

Das sieht bei mir so aus:

tst.lan.    IN    SOA    00cd82808b82. bla.bla.net. (
            1609059401
            10800
            3600
            604800
            38400 )
tst.lan.    IN    NS    00cd82808b82.
nas.tst.lan.    IN    A    192.168.0.10
licht.tst.lan.    IN    A    192.168.0.11

Ist leider schon etwas her, dass ich Mal einen Bind aufgesetzt habe und seitdem steht der Ecke und tut was er soll, bin deshalb etwas eingerostet, sorry

Schau Mal hier, das ist ganz gut dokumentiert:
https://wiki.ubuntuusers.de/DNS-Server_Bind/#Konfiguration-IPv4-IPv6

Danke für den Hinweis! Ich wusste nicht welche die "man-page" für BIND ist.
Und ja, das ist auch mein Ziel. Aufsetzen, Spaß haben, und so wenig wie möglich vergessen.

Keine Ahnung wie das mit dem Dockerimage aussieht, daher:

• Irgendwelche Zonen re: 0.0.0.0 oder sowas vergessen
• Prüfen wie die Forwarder-Konfiguration aussieht.

Evtl schießt auch der DNS Client Cache quer. Dann irgendwo (in Windows) ipconflg /flushdns sagen.

Protip: Unter der Kommandozeile kann man mit nslookup <FQDN> 192.168.0.10 direkt schauen was der DNS-Dienst wie auflöst.

Den DNS Client Cache hab ich immer gelöscht und hab auch die TTL kurz gesetzt, in der Hoffnung, dass dann der Cache das nur 10 Sekunden zwischenspeichert (die gesetzte Zeit)

Das weitere prüfe ich jetzt erstmal. (dazu muss ich mich noch mehr einlesen )

Das ist aber nicht der DNS, sondern eben Webmin, zwei Paar Schuhe. Prüfe mit "nslookup computerbase.de 192.168.0.10" ob der DNS-Dienst selbst auch tatsächlich erreichbar ist.

Bei Docker muss man ein paar Dinge bedenken. Docker erzeugt ein internes virtuelles Subnetz im Host und das kann bei der Konfiguration der Firewall einiges ändern, wenn man nicht aufpasst. Ein nativ gehosteter Dienst wäre stets über die INPUT-Chain der Firewall geregelt. Bei Docker wird der Dienst aber in besagtes virtuelles Subnetz weitergeleitet und somit ist plötzlich die FORWARD-Chain entscheidend. Unter Umständen wird also der DNS-Dienst einfach von der Firewall geblockt.

Stimmt natürlich!

nslookup gibt:

nslookup computerbase.de 192.168.0.10
Server:        192.168.0.10
Address:    192.168.0.10#53
Non-authoritative answer:
Name:    computerbase.de
Address: 87.230.75.2

Ich vermute ebenfalls, dass es an der Docker-Subnetz-Konfiguration liegt.

EDIT:
Soeben habe ich eine neue Zone nach dem selben Muster wie die erste aufgesetzt und siehe da es funktioniert.
ABER nur für ein paar Minuten. Nach ca. 5-10 Minuten war die URL nicht mehr erreichbar von meinem Mac.
Dann habe ich wieder

sudo killall -HUP mDNSResponder

eingegeben, und es ging wieder.

 

[Raijin]

Wenn ein direkter DNS-Query an 192.168.0.10 funktioniert, ist mit der Firewall soweit alles ok, sonst würde der Query ins Leere laufen. Die Ursache wird also tendenziell im Router stecken, der den DNS-Query nicht korrekt forwarded. Du kannst natürlich die Aufrufkette des DNS auch umdrehen.

Statt

Client --vomDHCP--> 192.168.0.1 --forward--> 192.168.0.10 --forward--> 8.8.8.8

eben so:

Client --vomDHCP--> 192.168.0.10 --forward--> 8.8.8.8 bzw 192.168.0.1 (conditional forwarding)


Bei lokalen Namen kann man in BIND dann eine Zone für die lokale Domain anlegen, die als Forwarder nicht 8.8.8.8, sondern den Router nimmt.

 

[Brandenburger]

Wenn ein direkter DNS-Query an 192.168.0.10 funktioniert, ist mit der Firewall soweit alles ok, sonst würde der Query ins Leere laufen. Die Ursache wird also tendenziell im Router stecken, der den DNS-Query nicht korrekt forwarded. Du kannst natürlich die Aufrufkette des DNS auch umdrehen.

Statt

Client --vomDHCP--> 192.168.0.1 --forward--> 192.168.0.10 --forward--> 8.8.8.8

eben so:

Client --vomDHCP--> 192.168.0.10 --forward--> 8.8.8.8 bzw 192.168.0.1 (conditional forwarding)


Bei lokalen Namen kann man in BIND dann eine Zone für die lokale Domain anlegen, die als Forwarder nicht 8.8.8.8, sondern den Router nimmt.

Das beruhigt mich, dass die Firewall i.O. ist. Eine Sorge weniger!

Ich habe im Router als lokalen DNS 192.168.0.10 eingetragen. Der trägt das dann auch automatisch als WAN-DNS ein. Eine andere Option gibt es nicht.

Müsste ich für das conditional forwarding die Einstellung bei den Clients machen?

 

[Raijin]

Ich habe im Router als lokalen DNS 192.168.0.10 eingetragen. Der trägt das dann auch automatisch als WAN-DNS ein. Eine andere Option gibt es nicht.

Diese Aussage lässt viel Spielraum für Interpretationen.


Ein Router hat eigene DNS-Einstellungen, also welchen DNS er selbst benutzt. Dies ist ab Werk in der Regel der DNS des Providers, den er via DHCP vom Provider zugewiesen bekommt. Je nach Router kann man den DNS an dieser Stelle aber auch ändern und zB auf 8.8.8.8 setzen oder gar einen lokalen DNS im Netzwerk.

Darüber hinaus gibt es noch die DHCP-Einstellungen. Einige Router vergeben via DHCP ausschließlich ihre eigene IP-Adresse, ein benutzerdefinierter DNS ist via DHCP nicht möglich. Es gibt aber durchaus auch Router, die beim DHCP einen benutzerdefinierten DNS erlauben.

Ein DHCP-Client bekommt letztendlich den DNS-Server zugewiesen, der in den DHCP-Einstellungen steht, sei es hart codiert die IP des Routers oder ein benutzerdefinierter DNS.




Conditional forwarding kommt dann zum Tragen, wenn DHCP und DNS auf verschiedenen Geräten laufen. Wenn der Router DHCP spielt, kennt er auch die Namen der Clients und kann via DNS deren Namen auflösen. Nutzt man aber einen anderen DNS - zB bind, pihole, whatever - dann kennt er die Namen nicht und da kommt conditional forwarding ins Spiel. Sobald bei bind ein DNS-Query ankommt, der zB nach "meinNAS.local" fragt, dann kann man mittels einer entsprechenden Zone definieren, dass dieser Query NICHT an den Upstream-DNS (zB 8.8.8.8) weitergeleitet wird, sondern explizit an den Router weitergeleitet wird, der via DHCP .local (.fritz.box / .speedport.ip / whatever) vergeben hat.

Ein Client fragt also IMMER ein und denselben DNS, den der manuell im Client eingestellt wurde oder den er via DHCP bekommen hat. Dieser DNS ist jedoch dafür verantwortlich, zu entscheiden ob der Query ins www zu 8.8.8.8 weitergeleitet wird oder lokal an den Router.

 

[Brandenburger]

Diese Aussage lässt viel Spielraum für Interpretationen.

Du hattest recht. Da habe ich wohl selber auch ein wenig interpretiert...

Ich hatte als WAN-DNS meinen DNS-Server vor Ort angegeben. Es war möglich einen LAN-DNS-Server festzulegen. Hier habe ich nun 192.168.0.10 eingetragen. Den WAN-DNS habe ich zurückgesetzt auf die vorkonfigurierte Adresse.

Ich nutze jetzt dieses conditional forwarding. Per DHCP haben die Clienten nun die DNS-Server mitgeteilt bekommen, welche ich als LAN-DNS eingestellt habe.

Echt dickes Danke @All und insbesondere an @Raijin !

Einen guten Rutsch und klopfen auf Holz!