This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firewall Academy - DNS Timeout Video

Hi,

gibt es zu dieser Folie aus der FW Academy, die diese Woche stattgefunden hat, das Video irgendwo zum ansehen? Vermutlich weiß  als einer der durchführenden Techniker aus dem Webinar was?

Bei uns timed nämlich sehr häufig/fast immer der erste nslookup aus, wenn die Clients hinter der XG sind und die als Resolver verwenden. Also, der erste Zugriff auf den DNS Server timed out. Nach der ersten Abfrage klappt dann alles.

Ich befürchte nicht, aber vielleicht ist das Video ja hilfreich.

Hier der lookup aus RED Netzen:

nslookup
DNS request timed out.
    timeout was 2 seconds.
Standardserver:  UnKnown
Address:  192.168.9.41

> heise.de
Server:  UnKnown
Address:  192.168.9.41

Nicht autorisierende Antwort:
Name:    heise.de
Addresses:  2a02:2e0:3fe:1001:302::
          193.99.144.80

> sophos.com
Server:  UnKnown
Address:  192.168.9.41

Nicht autorisierende Antwort:
Name:    sophos.com
Address:  23.36.239.66

nslookup heise.de
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.10.161

Nicht autorisierende Antwort:
Name:    heise.de
Addresses:  2a02:2e0:3fe:1001:302::
          193.99.144.80



This thread was automatically locked due to age.
Parents
  • 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.

    , 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

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

    , 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

Children
  • 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