filippg
Goto Top

DNS Additional Section Processing - RfC-Konformes Verhalten

Hallo Zusammen,

eine Frage an DNS-Checker: Wie verhält sich ein Resolver korrekt beim Auswerten von Additional Sections bzw. bei Fehlern darin?

Beispiel: Bei einer Anfrage nach www.administrator.de liefert der Root-Server für .de (a.nic.de) nicht nur den Name des NS für administrator.de, sondern auch gleich in der Additional Section die zugehörige IP mit:

;; Answer received from 194.0.0.53 (130 bytes)
;;
;; Security Level : UNCHECKED
;; HEADER SECTION
;; id = 49845
;; qr = true opcode = Query aa = false tc = false rd = false
;; ra = false ad = false cd = false rcode = NOERROR
;; qdcount = 1 ancount = 0 nscount = 2 arcount = 3

OPT pseudo-record : payloadsize 4096, xrcode 0, version 0, flags 0

;; QUESTION SECTION (1 record)
;; www.administrator.de. IN A

;; AUTHORITY SECTION (2 records)
administrator.de. 86400 IN NS ns.namespace4you.de.
administrator.de. 86400 IN NS ns2.namespace4you.de.

;; ADDITIONAL SECTION (3 records)
ns.namespace4you.de. 86400 IN A 80.67.16.124
ns2.namespace4you.de. 86400 IN A 193.223.77.3

So weit, so schön. Nur: Was ist jetzt, wenn diese Additional Section eine fehlerhafte IP enthält? Wir haben immer mal wieder den Fall, dass dort IPs von Nameservern stehen, die es schon läääängst nicht mehr gibt. Klar, sollte nicht sein - ist aber so. Verhält sich dann unser Resolver korrekt wenn er sagt "abc.xyz.com konnte ich nicht auflösen, weil ich keinen der Nameserver für xyz.com erreicht habe" (sprich: Wenn er sich auf die falschen Einträge der Additional Section verlässt), oder müsste der Resolver in dem Fall die IPs der Nameserver selbständig nochmal über den gesamten Baum auflösen?

Grüße & Danke

Filipp

Content-Key: 224088

Url: https://administrator.de/contentid/224088

Printed on: February 29, 2024 at 08:02 o'clock

Member: AndiEoh
AndiEoh Dec 10, 2013 at 13:22:26 (UTC)
Goto Top
Hallo,

das Stichwort ist "glue record". Wenn der Name des NS in der gleichen Domaine liegt muß der übergeordnete NS eine IP mitliefern, sonst hast du nichts mit dem du die Baumstruktur weiter nach unten gehen kannst. Früher wurden meines Wissen nach von Caching Resolvern alles dankbar aufgenommen was in den additional sections war, heute beschränkt man sich üblicherweise auf Werte die in der selben DNS Domaine liegen um Cache-Poisoning zu erschweren. Theoretisch müsste der Resolver also nach den Nameservern für namespace4you.de fragen und falls diese im .de Bereich liegen auf die IP vertrauen die mitgeliefert wird und dort nach ns.namespace4you.de und ns2.namespace4you.de fragen. Sind aber in diesem Fall eh die gleichen face-wink

Gruß

Andi
Member: filippg
filippg Dec 10, 2013 at 20:35:32 (UTC)
Goto Top
Hi Andi,

danke für deine Antwort!
Das mit dem Glue und dem "sonst hast du nichts mit dem du die Baumstruktur weiter nach unten gehen kannst" war mir vorhin im Büro dann auch aufgefallen... In sofern war auch mein Beispiel schlecht gewählt: da wo es nicht funktioniert ist immer der NS in einer anderen TLD als der gesuchte A-Record.

Früher wurden meines Wissen nach von Caching Resolvern alles dankbar aufgenommen was in den additional sections war,
heute beschränkt man sich üblicherweise auf Werte die in der selben DNS Domaine liegen um Cache-Poisoning zu erschweren.
Das ist genau der springende Punkt, bzw. die Frage: Was ist Standardkonform? Der Resolver, um den es geht, bereitet uns Ärger dadurch, dass er die Additional Section auch wenn der NS in einer anderen TLD liegt verwendet. Der Hersteller verweist erstmal darauf, dass da halt alte/falsche Informationen im DNS sind, für die er ja nun nichts kann (womit er natürlich nicht unrecht hat)

Grüße

Filipp
Member: AndiEoh
AndiEoh Dec 12, 2013 at 16:12:32 (UTC)
Goto Top
Hallo,

hier gibt es eine (wenn auch etwas emotionale) "Diskussion" zu diesem Thema:

http://cr.yp.to/djbdns/notes.html

Bezüglich Standardkonform hat der Hersteller wohl recht, wenn man einen hinreichend alten Standard (RFC 1034) verwendet face-wink
Auf der sicheren Seite wäre man mit DNSSEC, außerdem gibt es meines Wissens nach kein DNSSEC fähiger resolver der additional sections ohne Prüfung übernimmt, auch wenn die Domain nicht signiert ist. Lange Rede kurzer Sinn: Mit der Sicherheit des Resolver scheint es nicht weit her zu sein, falls möglich solltet Ihr etwas anderes verwenden, z.B. den hier http://www.unbound.net/

Gruß

Andi
Member: filippg
filippg Dec 14, 2013 at 15:20:56 (UTC)
Goto Top
Hi Andi,

Danke für den Link, den Artikel finde ich ziemlich gut!

Resolver-Wechseln kommt leider nicht in Frage, es geht um eine Appliance - lustigerweise aus dem Security-Bereich. Werden wir mal versuchen, mit dem Hersteller zu reden. Ob dadrüber tatsächlich Cache-Poisioning möglich wäre, weiß ich nicht - Voraussetzung dazu wäre ja, dass die out-of-baliwick-Antwort auch für andere Anfragen gecacht wird.

Grüße

Filipp