Firewall Academy - DNS Timeout Video

Hi LHerzog

Normalerweise treten diese Timeouts auf, wenn irgendwo in der Resolver Kette irgendwelche DNS nicht korrekt funktionieren. In vielen Umgebungen sieht die DNS Resolverkette wie folgt aus:

Client => Interner DNS / DC => Firewall => Public DNS Resolver

Wenn da unterwegs einer der DNS Server nicht korrekt auflösen kann, dann wird oft eben nach dem 2-3s Timeout auf Root DNS Resolver zurückgefallen.

Es macht sicher Sinn, wenn man sich von der Firewall via internem DNS bis zum Client zurückarbeitet, und an jedem Punkt testet, ob der DNS jeweils korrekt auflöst.

ich habe da schon interne DNS gesehen, die sowohl weitere interne wie auch externe DNS Server als Forwarder eingetragen hatten - ein NoGo.

Dasselbe auf der Firewall - interne DNS (DC's) und externe DNS wie Google oder Cloudflare o.ä. als Forwarder eingetragen - ein Mischbetrieb interne/externe DNS ebenfalls ein NoGo

Man trägt auf der FIrewall entweder ausschliesslich externe oder interne DNS Server als Forwarder ein. Im Falle externe public DNS Server lassen sich dann bei Bedarf für interne Domains DNS Request Routen anlegen. Im Falle inerner DNS Server übernehmen diese dann auch die Public DNS Auflösung und sollten entsprechend Public DNS Server als Forwarder eingetragen haben.

Wenn die anderen DNS in der Kette korrekt und ohne delay auflösen, dann liegt es oft an der in dem Webinar erläuterten DNS Konfiguration - meistens, dass ggf. IPv6 DNS konfiguriert sind auf der Firewall, aber gar keine IPv6 Konnektivität vorliegt/kein WAN Interface IPv6 konfiguriert hat

Hier kann man am einfachsten einfach allfälligerweise eingetragene IPv6 DNS Server auf der Firewall aus der Konfig rauslöschen, und ggf. sogar die DNS Query Konfiguration von "Choose server based on incoming requests record type" (Default) auf "Choose IPv4 DNS server over IPv6" umstellen. Das hilft meistens schon, dass die Firewall ohne timeouts DNS auflöst

Und ich gehe jetzt einfach mal davon aus, dass die Zoneneinstellungen auf der Firewall korrekt sind, und die Zonen für welche die Firewall als DNS Proxy fungieren soll den Haken für DNS auch gesetzt haben ;o)

Ich hoffe das hilft weiter...

Danke - der Kollege hatte mir den Link zum aufgezeichneten Webinar geschickt. Darin wurde in diesem Punkt nichts für unseren Fall hilfreiches beschrieben.

SaschaParis, in unserem Fall funktioniert die DNS Auflösung, aber immer wenn Mitarbeiter an einer RED hängen und die XG selbst als DNS Resolver verwenden, zeigt ein nslookup einen Timeout beim Connect zum Nameserver auf - also der XG selbst. Danach klappt alles. Startet man einen zweiten nslookup hat man das beschriebene Problem sofort wieder.

Man sieht in meinem Post oben die rot markierten Einträge - das sind keine Namensauflösungen sondern nur connects zum DNS Server (XG). Die Namensauflösung selbst klappt ohne Probleme.

hier auch nochmal transparent: wechsele ich aus dem LAN den Nameserver in nslookup auf ein RED interface der XG: timeout. die Auflösung danach klappt.

> server 192.168.10.161
DNS request timed out.
    timeout was 2 seconds.
Standardserver:  [192.168.10.161]
Address:  192.168.10.161

> hallo.de
Server:  [192.168.10.161]
Address:  192.168.10.161

Nicht autorisierende Antwort:
Name:    hallo.de
Address:  78.35.44.39

we found the root cause for the nslookup timeout thing:

there was no reverse lookup zone for the Network of the REDs. We created the reverse lookup zone on the DNS server and tested again. Nslookup is no longer showing a timeout when connecting to the RED interface of the XG.

naja, hätte ich auch auf Deutsch schreiben können. Gewohnheit :-)

> server 192.168.10.161
Standardserver:  [192.168.10.161]
Address:  192.168.10.161

> hallo.de
Server:  [192.168.10.161]
Address:  192.168.10.161

Nicht autorisierende Antwort:
Name:    hallo.de
Address:  78.35.44.39

we found the root cause for the nslookup timeout thing:

there was no reverse lookup zone for the Network of the REDs. We created the reverse lookup zone on the DNS server and tested again. Nslookup is no longer showing a timeout when connecting to the RED interface of the XG.

naja, hätte ich auch auf Deutsch schreiben können. Gewohnheit :-)

> server 192.168.10.161
Standardserver:  [192.168.10.161]
Address:  192.168.10.161

> hallo.de
Server:  [192.168.10.161]
Address:  192.168.10.161

Nicht autorisierende Antwort:
Name:    hallo.de
Address:  78.35.44.39