| orm@doc-tcpip.org | Erstellt: Mai 2001 - Letzte Modifikation: November 2005 |
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?
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
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.
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.
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
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.
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).#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/namedWichtig 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=115Und 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=115RQ 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).
+++ 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 ....
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.
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.
host eine_Maschine host IP_der_MaschineEs muß bei beiden Abfragen dasselbe herauskommen.
domain orm.org nameserver 192.168.140.2 nameserver 171.168.140.6Alle Namen wird vom Resolver ein "orm.org" angehängt, und es werden die beiden genannten Nameserver in dieser Reihenfolge befragt.
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.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL