options Option …

Option kann dabei einen der folgenden Werte annehmen:

debug

setzt RES_DEBUG in _res.options (nur wirksam, falls Glibc mit Debug-Unterstützung gebaut wurde, siehe resolver(3)).

ndots:n

definiert einen Schwellwert für die Anzahl der Punkte, die in einem an res_query(3) übergebenen Namen enthalten sein müssen (siehe resolver(3)), damit ein initial absolute query ausgeführt wird. Der Standardwert für n ist 1. Das hat zur Folge, dass zunächst versucht wird, den Namen als absoluten Namen aufzulösen, bevor ihm ein Eintrag aus der search list angehängt wird. Der Wert für diese Option wird stillschweigend auf 15 begrenzt.

timeout:n

setzt die Wartezeit auf die Antwort eines Name-Servers in der Ferne fest, nach deren Ablauf der Resolver die Anfrage an einen anderen Name-Server richtet. Dies muss nicht die gesamte von dem Resolver-API-Aufruf verwandte Zeit sein und es gibt keine Garantie, dass ein einzelner Resolver-API-Aufruf auf eine einzelne Zeitüberschreitung passt. Sie wird in Sekunden gemessen, der Standardwert ist RES_TIMEOUT (derzeit 5, siehe <resolv.h>). Der Maximalwert für diese Option ist 30.

attempts:n

Diese Option legt die Anzahl der Anfragen fest, die der Resolver an seine Name-Server sendet, bevor er aufgibt und dem aufrufenden Programm einen Fehler meldet. Der Standardwert ist RES_DFLRETRY (derzeit 2, siehe <resolv.h>); der Maximalwert 5.

rotate

Diese Option setzt RES_ROTATE in _res.options, was eine Reihum-Auswahl der Name-Server aus der Liste zur Folge hat. Auf diese Weise werden die Anfragen auf alle aufgeführten Server verteilt, anstatt dass alle Clients sich zunächst an den ersten aufgeführten Server wenden.

no-aaaa (seit Glibc 2.36)

Setzt RES_NOAAAA in _res.options. Das unterdrückt vom Rumpf-Resolver durchgeführte AAAA-Anfragen, einschließlich AAAA-Nachschlagungen, die von NSS-basierten Schnittstellen wie getaddrinfo(3) ausgelöst werden. Es sind nur DNS-Nachschlagungen betroffen: IPv6-Daten in hosts(5) werden weiterhin benutzt, getaddrinfo(3) mit AI_PASSIVE wird weiterhin IPv6-Adressen erstellen und konfigurierte IPv6-Name-Server werden weiterhin verwandt. Um korrekte Namensfehler-Ergebnisse (NXDOMAIN) zu erzeugen, werden AAAA-Anfragen in A-Anfragen übersetzt. Diese Option ist hauptsächlich zu Diagnosezwecken gedacht, um auszuschließen, dass AAAA-DNS-Anfragen nachteilige Auswirkungen haben. Sie ist zur Verwendung mit EDNS0 und der DNSSEC-Validierung durch Anwendungen inkompatibel.

no-check-names

Diese Option setzt RES_ROTATE in _res.options. Damit wird die moderne von BIND durchgeführte Prüfung eingehender Rechner- und E-Mail-Namen auf ungültige Zeichen wie Unterstrich (_), Steuerzeichen und andere Kodierungen als ASCII deaktiviert.

inet6

setzt RES_USE_INET6 in _res.options. Dadurch wird innerhalb der Funktion gethostbyname(3) zunächst eine AAAA-Anfrage vor einer A-Anfrage durchgeführt. Außerdem werden IPv4-Antworten in »IPv6 tunneled form« abgebildet, wenn keine AAAA-Einträge gefunden werden, aber ein Satz von A-Einträgen existiert. Seit Glibc 2.25 ist diese Option veraltet; Anwendungen sollten getaddrinfo(3) statt gethostbyname(3) verwenden.

Wenn diese Option gewählt wurde, verhalten sich einige Programme recht merkwürdig.

ip6-bytestring (seit Glibc 2.3.4 bis 2.24)

setzt RES_USE_BSTRING in _res.options. Damit verwenden inverse IPv6-Suchen das in RFC 2673 beschriebene »bit-label«-Format. Wird die Option nicht gewählt (die Vorgabe), wird das Nibble-Format verwendet. Diese Option wurde in Glibc 2.25 entfernt, da sie auf einer rückwärts-inkompatiblen DNS-Erweiterung basiert, die im Internet niemals eingesetzt worden war.

ip6-dotint/no-ip6-dotint (Glibc 2.3.4 bis 2.24)

Löscht/Setzt RES_NOIP6DOTINT in _res.options. Wenn diese Option gelöscht ist (ip6-dotint), werden inverse IPv6-Suchen in der ip6.int-Zone durchgeführt, wovon abgeraten wird. Wurde die Option gewählt (no-ip6-dotint), werden inverse IPv6-Suchen standardmäßig in der ip6.arpa-Zone durchgeführt. Diese Optionen sind bis Glibc 2.24 verfügbar, wo no-ip6-dotint die Vorgabe ist. Da die Unterstützung von ip6-dotint seit langer Zeit nicht mehr im Internet verfügbar ist, wurden diese Optionen in Glibc 2.25 entfernt.

edns0 (seit Glibc 2.6)

setzt RES_USE_EDNS0 in _res.options. Damit wird die Unterstützung für die in RFR 2671 beschriebenen DNS-Erweiterungen aktiviert.

single-request (seit Glibc 2.10)

setzt RES_SNGLKUP in _res.options. Standardmäßig erledigt die Glibc seit Glibc 2.9 das Abfragen von IPv4- und IPv6-Adressen parallel. Diese Anfragen können einige Appliance-DNS-Server nicht korrekt verarbeiten und führen zu Zeitüberschreitungen (timeouts). Diese Option deaktiviert die parallelen Anfragen und lässt Glibc die IPv6-und IPv4-Anfragen nacheinander erledigen (wodurch der Prozess etwas langsamer wird).

single-request-reopen (seit Glibc 2.9)

setzt RES_SNGLKUPREOP in _res.options. Der Resolver verwendet die gleichen Sockets für die A- und AAAA-Anfragen. Einige Hardware sendet fälschlicherweise nur eine Antwort zurück. Wenn das passiert, wird das Client-System auf die zweite Antwort warten. Das Einschalten dieser Option ändert das Verhalten: Wenn zwei Anfragen von dem gleichen Port nicht korrekt gehandhabt werden wird es das Socket schließen und einen neuen vor dem Versand der zweiten Anfrage öffnen.

no-tld-query (seit Glibc 2.14)

setzt RES_NOTLDQUERY in _res.options. Diese Option führt dazu, dass res_nsearch() nicht versucht, einen nicht qualifizierten Namen aufzulösen, als ob er ein »top level domain« (TLD) wäre. Diese Option kann zu Problemen führen, falls die Site »localhost« als TLD verwendet, statt »localhost« als ein oder mehrere Elemente auf der Suchliste zu haben. Diese Option hat keinen Effekt, falls weder RES_DEFNAMES noch RES_DNSRCH gesetzt ist.

use-vc (seit Glibc 2.14)

setzt RES_USEVC in _res.options. Diese Option erzwingt die Verwendung von TCP für DNS-Auflösungen.

no-reload (seit Glibc 2.26)

setzt RES_NORELOAD in _res.options. Diese Option deaktiviert das automatische Neuladen einer geänderten Konfigurationsdatei.

trust-ad (seit Glibc 2.31)

setzt RES_TRUSTAD in _res.options. Diese Option steuert das Bit AD-Bit-Verhalten des Stub-Resolvers. Falls ein überprüfender Resolver das AD-Bit in einer Antwort setzt, zeigt er an, dass die Daten in der Antwort entsprechend des DNSSSEC-Protokolls überprüft wurden. Um sich auf das AD-Bit zu verlassen, muss das lokale System sowohl dem DNSSEC-überprüfenden Resolver als auch dem dahin führenden Netzwerkpfad vertrauen, weshalb eine ausdrückliche Zustimmung zur Nutzung notwendig ist. Falls die Option trust-ad aktiv ist, setzt der Stub-Resolver das AD-Bit in ausgehenden DNS-Anfragen (um AD-Bit-Unterstützung zu aktivieren) und behält das AD-Bit in Antworten bei. Ohne diese Option wird das AD-Bit in Anfragen nicht gesetzt und immer in Antworten entfernt, bevor diese an die Anwendung zurückgeliefert werden. Das bedeutet, dass Anwendungen dem AD-Bit in Antworten vertrauen können, wenn die Option trust-ad korrekt eingerichtet wurde.

Bis Glibc 2.30 wurde AD in Abfrage nicht automatisch gesetzt und in Antworten an Anwendungen unverändert weitergegeben.