orm@doc-tcpip.org

Erstellt: Mai 2001 - Letzte Modifikation: November 2005

[ Main | Local ]


Named Troubleshooting


Doc Tcpip ist ein Trottel, ich möchte Mr. Dns fragen!
Der Secondary/Slave antwortet nicht sofort, obwohl der Primary/Master down ist!
Logging und Auswertung der Logs
Nslookup zum Troubleshooten
Statistiken, die named freundlicherweise anlegt
Zonen Transfers
Performance
BIND 8 Einrichten - unter AIX
Was man im Zusammenspiel mit IPv6 beachten muß
Troubleshooting auf der Client Seite
Ist NIS unser Problem?

Ich finde keine Lösung zu meinem Problem

Dem Manne kann geholfen werden: Bei Acme Byte & Wire findet sich Mr. Dns. Man kann Fragen stellen und findet einen Link zu der sehr umfangreichen Sammlung aller möglichen DNS-Fehlermeldungen (von Kevin O'Neill). Einfach Klasse. Hier die Links: Um Mr. Dns eine Frage zu stellen: www.acmebw.com/askmrdns und die Sammlung der BIND 8 Messages: www.acmebw.com/askmrdns/bind-messages.html. Wenn es das auch nicht bringt (kaum Vorzustellen), dann kann man noch die Mailing-Listen beim ISC durchsuchen www.isc.org/ml-archives/bind-users/. Und wenn es da auch nichts gibt - dann Pech. Beten?

Nameserver Timeout - "Performance" des Slaves

Diese Problem wird in der Regel als "Performance Problem" betrachtet. Es wird beobachtet, das ein beliebiger Host, der in seiner /etc/resolv.conf einen Master (Primary) Server und einen zusätzlichen Slave (Secondary) Server eingetragen hat, bei Ausfall des Masters 5-7 Sekunden braucht, um einen Namen aufzulösen.
Das ist natürlich ganz normal, da ja der Host festeingestellte Werte für die Zeit, die er auf eine Antwort wartet (5 Sekunden) sowie für die Anzahl der Versuche, die er unternimmt (4) hat. Diese Zeiten werden durch einen Backoff-Algorithmus ergänzt. Sind nun mehrere Server in der /etc/resolv.conf konfiguriert (drei sind möglich), so versucht der Resolver zuerst den ersten Eintrag, und wenn von diesem innerhalb der 5 Sekunden keine Antwort kommt, geht er zum nächsten Eintrag. In der zweiten Runde werden die Timeouts vergrößert.

Abhilfe schafft die Änderung folgender Parameter auf Client Seite:
Mit der Shell Variablen RES_TIMEOUT kann man den Timeout anpassen, der Client wird also weniger Zeit auf eine Antwort warten und schnell den Slave-Serve ansprechen - der dann hoffentlich antwortet.
Eine weitere Shell Variable, RES_RETRY bestimmt die Anzahl der Versuche, die durchgeführt werden. Diesen Wert kann man herabsetzen, wenn z.B. keine dauernde Verbindung zum Internet besteht. Der Server gibt dann schneller einen endgültigen Status zurück. Systemweit kann man das in der /etc/environment einstellen. Und es ist alles im O'Reilly Buch bzw. im Stevens genau erklärt.
Unter AIX gibt es noch ein anderes Problem, das mit IPv4/IPv6 zu tun hat. Dazu mehr weiter unten

Logging einrichten und Auswerten

Hier unterscheiden sich bind 4.x und bind 8.x bzw. bind 9.
Hat man ein Problem mit dem Start des Deamons, so muß man das Syslog der Maschine aufsetzen und sehen, was man erhält. Dem Deamon als solchem kann man auch anweisen, ein Debug-Log zu schreiben (wenn er entsprechend Kompiliert worden ist). Alle Deamons loggen nach /usr/tmp (oder auch nach /var/tmp. Wobei das File named.run geschrieben wird. Man kann den Deamon entweder neu starten und ihm mit -d loglevel ein Debuglevel mitgeben, oder man sendet eine dem Level entsprechende Anzahl an Signale an den Deamon:
kill -USR1 'cat /etc/named.pid'
Das zweimal läßt den Deamon im Level 2 Debug-Information schreiben. Mit einem kill auf USR2 schaltet man das Logging wieder aus.
Auf AIX kann man das ganze auch bequemer mit dem SRC erledigen.
Der Unterschied zwischen den einzelnen Versionen ist der, daß ab bind 8 das Logging in der named.conf konfigurierbar geworden ist. Bind 4 läßt nur eine Auswahl des Levels zu.

Es gibt noch mehr Debug-Level (bis 11), die aber normalerweise nicht zum Troubleshooten gebraucht werden. Bind 8 und 9 lassen sich zusätzlich noch sehr detailiert konfigurieren. Man kann sowohl ins bind-log wie auch ins syslog loggen etc. pp. Ist das Logging nicht in der named.conf eingetragen, so wird auch nicht geloggt. In diesem Beispiel wird alles noch /tmp/bind8.log geschrieben:


logging {
channel my_file {
file "/tmp/bind8.log" versions 3 size 100k;
print-category yes;
print-severity yes;
};

category default  { my_file; };
category panic    { my_file; };
category packet   { my_file; };
category eventlib { my_file; };
category queries  { my_file; };
};

Das erzeugt maximal drei Files mit je 100K - Es kann einem kein Filesystem mehr volllaufen. Andererseits muß man sich genau überlegen, was man loggt. 300K sind schnell geschrieben, und das älteste File wird von dem neuen Überschrieben - und das Problem vielleicht auch.

Troubleshooting mit nslookup

Eine coole Sache zum schnellen Debuggen ist dieser Aufruf: RES_OPTIONS=debug LANG=C ping hostname
Das setzt die DEBUG-Umgebungsvariable und die Sprache; dann wird ping oder z.B. das host-Kommando aufgerufen. Es wird dann die Namensauflösung im einzelnen auf dem Bildschirm ausgegeben, was wertvolle Hinweise gibt.

Für den Start der Zuständigkeit für jede Zone:
nslookup -d -qtype=soa Die entsprechende Zone

Um den auhoritären Server zu finden:
nslookup -d -qtype=a hostname

Statistiken und Troubleshooting

Bind ermöglicht Zugang zu ausführlichen Statistiken über Art und Intensität der Nutzung. In Bind 4 muß man die Statistiken von Hand erzeugen, ab Bind 8 kann man den Deamon so konfigurieren, das er nach bestimmten Intervallen eine kondensierte Statistik in das Syslog loggt.

Um den Dump der Statistik zu veranlassen, sendet man dem Deamon-Prozess das Signal ABRT (unter AIX ist das Signal 6 - unter BSD ist 6 aber INT. Also vorher mit kill -l prüfen, wie es gehandbhabt wird).
Die Sequenz
kill -ABRT 'cat /etc/named.pid'
dumpt also die Stats. Diese finden sich als named.stats im Verzeichnis /usr/tmp oder auch /var/tmp.

Was noch hilfreich sein kann, ist ein Dump der Datenbank des Servers. Hier sind einmal die eigenen, also die aus den Daten-Files eingelesenen RR zu sehen sowie alles, was der Server im Laufe seiner Uptime bisher gelernt und gesehen hat (also der Server-Cache).
Das geht ähnlich wie beim Erzeugen der Statistiken:
kill -INT 'cat /etc/named.pid'
(kill -INT ist kill -2 unter AIX....)
Hier heisst das File: /var/tmp/named_dump.db

Probleme mit Zonen-Transfers


Dazu führt man am besten einen Zonentransfer von Hand durch und erzwingt durch geschickte Wahl der Seriennummer, das der Transfer auch wirklich passiert.Man kann die Daten dann in ein File schreiben, und so auch eventuellen Beschädigungen der Information während des Transfers auf die Spur kommen.
/etc/named-xfer -z xxxx.com -f /tmp/named.data -s 0 -d 4 9.3.6.70
Ich will vom Server 9.3.6.70 die Zone (Domain) xxxx.com in das File /tmp/named.data schreiben. Die Serien-Nummer soll 0 sein, damit in jedem Fall ein Update stattfindet und ich möchte Debug-Messages im Level 4 sehen.
Mit echo prüft man den Rückgabewert und kann seine Schlüße ziehen...:
echo $?
Das bedeuten die Rückgabewerte:
==> 0 zone data up to date, no transfer needed
==> 1 successful transfer
==> 2 no server available, error mess. may have been loggedr
==> 3 error message logged

Das sind die Flags:
-z zone_to_transfer
specifies the name of the zone to be transferred.

-f db_file
specifies the name of the db_file into which the zone should be dumped when it is received from the primary server.

-s serial_no
specifies the serial number of our current copy of this zone. If the SOA RR we get from the primary server does not have a serial number higher than this, the transfer will be aborted.

-d debuglevel
Print debugging information. The debuglevel is a number de- termines the level of messages printed.

-l debug_log_file
Specifies a log file for debugging messages. The default is system- dependent but is usually in /var/tmp or /usr/tmp. Note that this only applies if ``-d'' is also specified.

Dieses Flag gibt es unter AIX nicht (-i):
-i ixfr_file
Specifies the name of the ixfr_file into which the zone changes from Incremental Zone Transfer (IXFR) should be dumped when it is received from the primary server.

-t trace_file
Specifies a trace_file which will contain a protocol trace of the zone transfer. This is probably only of interest to peo- ple debugging the name server itself.

-p port#
Use a different port number. The default is the standard port number as returned by getservbyname(3) for the service ``domain''.

-S
Perform a restricted transfer of only the SOA, NS records and glue A records for the zone. The SOA record will not be load- ed by named(8) but will be used to determine when to verify the NS records. See the ``stubs'' directive in named(8) for more information.

BIND Performance-Probleme


Das größte Problem ist der Verbrauch an Memory. Wenn der Server authoritär für viele Zonen ist, kann er viel Memory brauchen - und wenn die Summe des Memory-Verbrauches aller Prozesse größer ist als das real mem, dann geht das pagen und swappen los. Dazu kommt noch, das named für Zonentransfers noch eine Instance des Deamons startet, die dann natürlich auch wieder Speicher braucht - und es können mehrere Deamons zugleich sein. Man sollte also den Verbrauch im normalen Betrieb ermitteln und diesen Wert mal 2 oder 3 rechnen.

Daß, was der named an CPU braucht - ist wenig, viel Verbrauch ist ein Zeichen eines Problemes mit der Konfiguration (5% ist wohl ok, 10% ist nur für einen reinen DNS-Server akzeptabel).
So sieht das bei mir aus:
#ps aux|egrep "PID|named"
USER       PID %CPU %MEM   SZ  RSS    TTY STAT    STIME  TIME COMMAND
root     22108  0.0  5.0 3384 3104      - A      Feb 01  9:12 /usr/sbin/named
Wichtig ist dann natürlich die Anzahl der Anfragen pro Minute oder Sekunde. Das sieht man in den Stats, die man wie oben beschrieben bekommt, oder mit Bind 8 auch regelmässig abziehen kann:
options {
statistics-interval 60;
};
Im syslog output sieht das dann so aus:
Feb 20 14:43:03 nimmaster named[22108]: NSTATS 982676583 981026034 A=1926 PTR=840 ANY=19
Feb 20 14:43:03 nimmaster named[22108]: XSTATS 982676583 981026034 RQ=2785 RR=14308 RIQ=0 RNXD=2126
RFwdQ=237 RFwdR=2229 RDupQ=0 RDupR=205 RFail=0 RFErr=0 RErr=0 RTCP=4 RAXFR=0 RLame=0 ROpts=0 SSysQ
=15897 SAns=2550 SFwdQ=237 SFwdR=2229 SDupQ=375 SFail=2027 SFErr=0 SErr=0 RNotNsQ=2785 SNaAns=102 S
NXD=115
Und eine Stunde später:
Feb 20 15:43:12 nimmaster named[22108]: NSTATS 982680192 981026034 A=1929 PTR=842 ANY=19
Feb 20 15:43:12 nimmaster named[22108]: XSTATS 982680192 981026034 RQ=2790 RR=14334 RIQ=0 RNXD=2131
RFwdQ=237 RFwdR=2234 RDupQ=0 RDupR=205 RFail=0 RFErr=0 RErr=0 RTCP=4 RAXFR=0 RLame=0 ROpts=0 SSysQ
=15926 SAns=2555 SFwdQ=237 SFwdR=2234 SDupQ=375 SFail=2030 SFErr=0 SErr=0 RNotNsQ=2790 SNaAns=102 S
NXD=115
RQ ist die Anzahl der erhaltenen Anfragen, bildet man die Differenz, dann kommt man auf satte 5 in diesem Fall. Will man ungefähr die Netzlast wissen, muss man RQ plus SAns (die gesendeten Antworten) mal 800 Bit (100 Byte, durchschnittliche Paketgröße) durch 3600 (weil es eine Stunde ist) rechnen... Dafür gibt es eine Reihe Tools: (www.dns.net/dnsrd).
Der Dump der Datenbank zeigt, wo was wann hingeht. Das ist wichtig, wenn man sich überlegt, zb. noch einen Server einzurichten.
+++ Statistics Dump +++ (982762849) Wed Feb 21 14:40:49 2001
1736815 time since boot (secs)
1736815 time since reset (secs)
0       Unknown query types
2014    A queries
845     PTR queries
20      ANY queries
++ Name Server Statistics ++
(Legend)
RQ      RR      RIQ     RNXD    RFwdQ
RFwdR   RDupQ   RDupR   RFail   RFErr
RErr    RTCP    RAXFR   RLame   ROpts
SSysQ   SAns    SFwdQ   SFwdR   SDupQ
SFail   SFErr   SErr    RNotNsQ SNaAns
SNXD
(Global)
2879 15042 0 2214 240  2320 0 209 0 0  0 4 0 0 0  16681 2641 240 2320 379  2088 0 0 2879 10
4  115
[0.0.0.0]
0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0 0 0 2215 0  1955 0 0 0 0  0
[9.14.1.3]
0 497 0 0 0  0 0 0 0 0  0 0 0 0 0  549 0 0 0 0  0 0 0 0 0  0
....................................
.... Hier weitere Datensätze ....

BIND 8 Einrichten - unter AIX


Die Programme named und named-xfer werden unter AIX mittels zweier Links angesprochen, sodaß man verschiedene Versionen parallel vorhalten kann. Per Default zeigen die Links auf die bind 4 Versionen. Um bind 8 zu nutzen ist es also erforderlich, die Links entsprechend anzupassen.
/usr/sbin/named -> /usr/sbin/named4 (oder named8)
Dasselbe für xfer-named...

Weiterhin erwartet bind 8 eine Konfigurationsdatei /etc/named.conf. Diese kann man anhand von Beipielen in /usr/samples/tcpip selbst erstellen, oder mit dem Skript /usr/samples/tcpip/named-bootconf.pl aus der named.boot erstellen.
Man braucht eine resolv.conf mit diesem Eintrag:
nameserver 127.0.0.1

Das wäre im Prinzip alles, bis auf ein weiteres Problem, was viel Arbeit machen kann:
Der bind 8 ist erheblich empfindlicher als bind 4, was die Syntax der Data-Files angeht. Es ist daher in der Regel nicht möglich, einfach mit den "alten" Files weiterzumachen, die man unter bind 4 jahrelang benutzt hat - es sei denn, man hat diese Files immer sehr sorgfältig gepflegt...
In den meisten Fällen wird man nach der Umstellung viele Fehler im Syslog sehen.
Man sollte volles Logging einschalten, dann den named starten und im Log lesen, was nicht geht - und das dann nach und nach korrigieren.

Was man im Zusammenspiel mit IPv6 beachten muß

AIX Version 4 ML 3 ist von der IBM AIX-Entwicklung als "IPv6 Migration Platform" konzipiert worden. Jetzt sind IPv6 IP-Adressen bekanntlich 128 bit lang, während IPv4 Adressen nur 32 bit lang sind. Das hat eine Änderung im Protokoll nach sich gezogen, und es ist ein neuer Query Typ eingführt worden: Type 28 für eine IPv6 konforme Anfrage.

Um auf einem Netz mit IPv4 Maschinen koexistieren zu können, also ohne ein eigenes, paralleles System an dedizierten DNS Servern aufbauen zu müssen, wurde der Resolver einfach angewiesen, zuerst eine IPv6 Anfrage zu schicken. Ein normaler IPv4 Server hätte darauf sofort geantwortet, und erklärt, das er diesen Typ nicht kennt. Was den Resolver veranlassen würde, direkt eine IPv4 Anfrage nach zu schieben.

Leider sind sehr viele Server schlecht konfiguriert und wenden sich in einem solchen Fall an die Root-Server, sogar wenn die Anfrage nach einem Namen in der eigenen Domain war. Ist der Root-Server nicht zu erreichen, dann geben diese Maschinen SERVFAIL zurück. Was immer bedeutet, das ein Server falsch konfiguriert ist. In den meisten Fällen ist kein Link zum Internet da oder im Cache sind Rootserver drin, die nicht erreicht werden können. Es mag auch sein, das der fragliche Server an einen Forwarder weitergibt, der solch ein Problem hat.

In jedem Fall führt SERVFAIL dazu, das die Typ 28 Anfrage wiederholt wird - und das solange, bis die etwa 75 Sekunden Timeout durch sind. Dann geht der Resolver auf IPv4 und stellt seine Anfrage neu - was wie ein Wunder funktioniert.

Es ist dann von Seiten der IBM an den Keywords in der /etc/netsvc.conf verändert worden: Neu hinzu kamen "local4" und "bind4". Das zwingt den Resolver dazu, direkt eine IPv4 konforme Anfrage zu schicken. Wegen diverser Probleme mit dem "local4" Keyword (sendmail..) ist es in so einem Fall das Beste "hosts=local,bind4" in /etc/netsvc.conf zu setzen und keine IPv6 Adressen in die /etc/hosts zu setzen.

Troubleshooting des DNS Clients

  • Wird direkt wie auch revers richtig aufgelöst?
  • Das testet man, indem man einen Namen auflöst, und das Ergebnis (die IP Adresse) gleich nochmal auflöst:
    host eine_Maschine
    host IP_der_Maschine
    
    Es muß bei beiden Abfragen dasselbe herauskommen.
  • Existiert die Datei /etc/resolv.conf?
  • Das wird einfach mit ls -l /etc/resolv.conf geprüft. Wenn diese Datei existiert, dann benutzt das System das DNS zur Namensauflösung. In der Datei muß die Adresse des oder der Nameserver stehen. Ist die Datei leer, dann sollte ein Nameserver auf dem lokalen Rechner laufen.
  • Ist die Datei /etc/resolv.conf korrekt?
  • Es muß mindestens ein Nameserver (maximal 3) angegben sein. Die "domain" oder "search" Statements sind optional. Sie dienen dazu, die entsprechenden Endungen an die kurzen Hostnamen zu hängen. D.h.: fragt man nach der Maschine "dumpy" dann wird eine Anfrage nach "dumpy.meine.domain" losgeschickt - wenn das "domain" Statement "meine.domain" heisst. Das "search" Statement ist genauso, nur das mehrere Angaben möglich sind, die nacheinander abgearbeitet werden. Lautet das "search" Statement z.B. "mainz.ibm.com de.ibm.com uk.ibm.com" so wird der Name "dumpy" in dieser Reihenfolge gesucht: dumpy.mainz.ibm.com, dumpy.de.ibm.com und dumpy.uk.ibm.com. Ein Beispiel für die /etc/resolv.conf:
    domain orm.org
    nameserver 192.168.140.2
    nameserver 171.168.140.6
    
    Alle Namen wird vom Resolver ein "orm.org" angehängt, und es werden die beiden genannten Nameserver in dieser Reihenfolge befragt.
  • Antwortet das DNS überhaupt?
  • Das kann man entweder mit dem host-Kommando, nslookup oder mit "dig" prüfen. Man sollte ein paar Rechner im selben Netz versuchen aufzulösen. Geht das nicht, dann ist vielleicht der Server down? Da hilft dann ein ping weiter...
  • Das host-Kommando:
  • Das Host-Kommando kennt einige nützliche Schalter:

    Ist NIS unser Problem?

    NIS kann man auch zur Namensauflösung benutzen. Eventuell hat es aber eine andere Ansicht darüber, wie ein gegebener Host heißt.
    Eigentlich geht es nur darum, herauszufinden, ob NIS läuft (man kann es dann testweise abschalten..).
    Mit ypwhich sehe ich, an welchen NIS-Server die Maschine gerade gebunden ist. Dann muß geprüft werden, ob der ypbind läuft - mit ps oder unter AIX mit lssrc -s ypbind. Gibt es einen NIS-Server und läuft der ypbind, dann kann man mit ypcat hosts einen Blick in die host map werfen, die das NIS verteilt.


    [ Main | Local ]

    [ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

    Copyright 2001-2014 by Orm Hager - Es gilt die GPL
    Feedback bitte an: Orm Hager (orm@doc-tcpip.org )