# [gelöst] DNS Probleme

## fenris_der_wolf

Hallo liebe Leute, 

ich bräuchte mal Hilfe bei einem echt nervigen DNS-Problem:

Das Problem:

Seit ca. 1 - 2 Monaten haben wir bei uns im Netzwerk immer mal wieder DNS Probleme. Diese äußern sich dahingehend, dass man keine Verbindung aus dem Intranet ins Internet bekommt, egal ob via HTTP,FTP,SSH etc. Wenn man aber die IP zur Kontaktaufnahme benutzt, dann geht alles einwandfrei. Die Aussetzer dauern meist nur 1 -2 Minuten, sind aber trotzdem (oder gerade deshalb) extrem nervig. 

Anfangs kam es nur alle 2 - 3 Tage dazu, die Häufigkeit stieg aber nach und nach an, bis gestern plötzlich kaum noch ein Arbeiten möglich war. Heute ist es zwar wieder etwas besser aber...

Unser Netzwerk:

Liegt hinter einem Cisco Router hinter dem sich zwei große 24Port Switches befinden. Wir betreiben 5 Server direkt an dem Router, die Arbeitsplätze, Drucker, Telefonanlage etc. hängen an den Switches. Der lokale DNS-Server (Bind) teilt sich mit dem Mailserver ein Gentoo-System.

Die Server Hardware

Ist ein IBM Server mit einem Intel Xeon 5140 mit 16G RAM

Kernel: 4.3.3-hardened-r4

Bind: 9.10.3_p2 (Useflags: berkdb caps dlz ssl threads urandom xml aktiviert)

Mailserver: postfix-3.0.3. / dovecot-2.2.19

Der Internetzugang ist ein SDSL 25MBit mit fester IP.

Die named.conf

Sorry das sie ein Bisschen "gerupft" aussieht, aber ich hab' gestern alles mögliche geändert.

```

acl "xfer" {

        none;

};

acl "trusted" {

        127.0.0.0/8;

        192.168.0.0/24;

};

options {

        directory "/var/bind";

        pid-file "/var/run/named/named.pid";

        forward only;

        query-source address * port *;

        listen-on-v6 { none;};

        listen-on port 53 { 127.0.0.1; 192.168.0.10; };

        allow-query {

                trusted;

        };

        allow-query-cache {

                trusted;

        };

        allow-transfer {

                none;

        };

        forwarders {

                213.133.98.98;

                213.73.91.35;

                217.79.186.148;

                213.133.100.100;

                85.214.73.63;

                62.141.58.13;

                87.118.100.175;

        };

        auth-nxdomain no;

        version none;

};

view "internal" {

        match-clients { 192.168.0.0/24; localhost; };

        recursion yes;

        zone "ourdomain" {

                type master;

                file "/etc/bind/db.ourdomain";

                allow-transfer { any; };

        };

        zone "0.168.192.in-addr.arpa" {

                type master;

                file "/etc/bind/db.192.168.0";

        };

};

view "external" {

        match-clients { any; };

        recursion no;

        zone "." in {

                type hint;

                file "/etc/bind/db.root";

        };

        zone "localhost" IN {

                type master;

                file "/etc/bind/db.local";

                notify no;

        };

        zone "127.in-addr.arpa" IN {

                type master;

                file "/etc/bind/db.127";

                notify no;

        };

        zone "0.in-addr.arpa" {

                type master;

                file "/etc/bind/db.0";

        };

        zone "255.in-addr.arpa" {

                type master;

                file "/etc/bind/db.255";

        };

};

logging {

        channel default_log {

                file "/var/log/named/named.log" versions 5 size 200M;

                severity info;

                print-time yes;

                print-severity yes;

                print-category yes;

        };

        category default { default_log; };

        category general { default_log; };

};

include "/etc/bind/rndc.key";

controls {

        inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys { "rndc-key"; };

};

```

Fehlersuche

Zuerst habe ich die Logs des Nameservers durchforstet, was zu nichts führte, selbst wenn ich das Loggen in der named.conf auf "Debug" stellte, bekomme ich nicht mal ein Warning.

ABER ein 

```
/etc/init.d/named restart
```

 behebt das Problem vorläufig. (Bis zum nächsten Aussetzer)

Au0erdem ergibt auch ein 

```
/etc/init.d/named checkconfig
```

 keine Fehler.

Wenn ich aber von meinem Arbeitsplatz aus dig ausführe, dann bekomme ich folgendes zurück:

```

; <<>> DiG 9.10.3-P2 <<>> www.gentoo.org

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63991

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.gentoo.org.                        IN      A

;; Query time: 4999 msec

;; SERVER: 192.168.0.10#53(192.168.0.10)

;; WHEN: Fri Jan 29 11:27:54 CET 2016

;; MSG SIZE  rcvd: 43

```

Wenn ich das selbe z.B. auf unser Warenwirtschaftssystem (Intranet) mache, dann bekomme ich keinen Fehler zurück.

Auch eine Verbindung per telnet auf den Server Port 53 brachte kein Problem zu Tage.

Sonstiges:

-Die DNS-Zugriffe im Intranet funktionieren wie gesagt auch während der Ausfälle einwandfrei

-Subjektiv kommt es mir so vor, als ob das Problem häufiger auftritt, wenn mehr Mitarbeiter im Netzwerk unterwegs sind

-Die Konfiguration habe ich schon lange bevor die Probleme Auftraten (Ausnahme gestern) nicht mehr verändert

-Allerdings habe ich das ein oder andere Update (nur stable) gemacht

-Alles was ich gestern geändert und zurück geändert habe hat die Situation nicht im geringsten verändert.

-Die Hardware Server, Router, Switches scheint einwandfrei zu laufen.

Leider bin ich was DNS betrifft ein unbeschriebenes Blatt. Also lange Rede kurzer Sinn ich wäre für jede Hilfe echt dankbar!  :Smile: 

Natürlich, poste ich auch gerne noch weiter Konfigurationen und berichte gern auch im Detail über alle Änderungen die ich an der named.conf vorgenommen habe.

PS: Wahrscheinlich sehe ich mal wieder den Wald vor lauter Bäumen nicht, wenn dem so ist bitte ich das zu entschuldigen.  :Wink: Last edited by fenris_der_wolf on Fri Feb 05, 2016 9:23 am; edited 1 time in total

----------

## py-ro

Sind die Server im "trusted"/"match-clients" Netz?

Ggf. beantwortet der sonst nämlich nur Dinge die er eh im Cache hat, macht aber sonst kein Recursing.

----------

## fenris_der_wolf

 *Quote:*   

> Sind die Server im "trusted"/"match-clients" Netz?

 

Ja das sind sie. Danke für's schnelle Melden!  :Wink: 

Das ganze Netz Server, Arbeitsplätze etc ist ein großes 192.168.0.0/24 Netz und der Nameserver hat die IP 192.168.0.10 

Um es noch einmal ganz genau hervorzuheben, die ganze Sache ist einfach nach und nach "passiert". An der Konfiguration hat sich außer hin und wieder ein Update seit über einem Jahr nichts geändert.

----------

## py-ro

Haben die Server ausschließlich die interen IP-Adresse?

----------

## Marlo

Hi fenris_der_wolf,

deine forwarders sind bis auf den vom ccc down oder völlig vom Netz.

Und die Antwortzeit vom ccc ist seeeehr träge. Insofern herzlichen Glückwunsch!

Auf dein Gefühl kannst du dich verlassen. Nur ein langsamer forwarder, viele User

macht alles lahm und es gibt Aussetzer. Einfach mal 8.8.8.8 und 8.8.4.4 eintragen

und die Ergebnisse vergleichen.

```

tux# host 213.133.98.98

98.98.133.213.in-addr.arpa domain name pointer ns1-coloc.hetzner.de.

#

tux# ping 213.133.98.98

PING 213.133.98.98 (213.133.98.98) 56(84) bytes of data.

^C

--- 213.133.98.98 ping statistics ---

24 packets transmitted, 0 received, 100% packet loss, time 22999ms

#

#########################################################

#

tux # host 213.73.91.35

35.91.73.213.in-addr.arpa domain name pointer dnscache.berlin.ccc.de.

#

tux# ping 213.73.91.35

PING 213.73.91.35 (213.73.91.35) 56(84) bytes of data.

64 bytes from 213.73.91.35: icmp_seq=1 ttl=54 time=49.3 ms

64 bytes from 213.73.91.35: icmp_seq=2 ttl=54 time=67.8 ms

64 bytes from 213.73.91.35: icmp_seq=3 ttl=54 time=50.7 ms

^C

--- 213.73.91.35 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2001ms

rtt min/avg/max/mdev = 49.385/56.012/67.897/8.424 ms

#

tux# host 217.79.186.148

Host 148.186.79.217.in-addr.arpa. not found: 3(NXDOMAIN)

#

#############################################################

#

tux# host 213.133.100.100

100.100.133.213.in-addr.arpa domain name pointer ns3-coloc.hetzner.de.

#

tux# ping 213.133.100.100

PING 213.133.100.100 (213.133.100.100) 56(84) bytes of data.

^C

--- 213.133.100.100 ping statistics ---

21 packets transmitted, 0 received, 100% packet loss, time 20000ms

#

##############################################################

#

tux# host 85.214.73.63

63.73.214.85.in-addr.arpa domain name pointer h2490989.stratoserver.net.

#

tux# ping  85.214.73.63

PING 85.214.73.63 (85.214.73.63) 56(84) bytes of data.

^C

--- 85.214.73.63 ping statistics ---

15 packets transmitted, 0 received, 100% packet loss, time 13999ms

#

###############################################################

#

tux# host  62.141.58.13

13.58.141.62.in-addr.arpa domain name pointer spftor2.privacyfoundation.de.

#

tux# ping 62.141.58.13

PING 62.141.58.13 (62.141.58.13) 56(84) bytes of data.

^C

--- 62.141.58.13 ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 3999ms

#

################################################################

#

tux# host 87.118.100.175

175.100.118.87.in-addr.arpa domain name pointer ns.anon.privacyfoundation.de.

#

tux# ping 87.118.100.175

PING 87.118.100.175 (87.118.100.175) 56(84) bytes of data.

^C

--- 87.118.100.175 ping statistics ---

10 packets transmitted, 0 received, 100% packet loss, time 8999ms

```

----------

## fenris_der_wolf

 *Quote:*   

> Einfach mal 8.8.8.8 und 8.8.4.4 eintragen und die Ergebnisse vergleichen. 

 

Werd' ich machen. Das schlimme ist, seit Samstag morgen läuft das ganze ohne, dass ich die geringste Änderung vorgenommen habe, wieder mal ohne Probleme. Ich werde trotzdem mal die beiden Server "rein-googeln".

----------

## fenris_der_wolf

So der DNS-Server läuft jetzt seit fast einer Woche ohne Probleme. Wie üblich kam ich nicht auf die einfachste Lösung, die natürlich die Richtige war. THX Marlo 

Millionen Zombies können nicht irren. Manchmal ist alles was man braucht ein weiteres Gehirn.  :Wink: 

----------

