4
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:
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
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
;;
;; 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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 224088
Url: https://administrator.de/contentid/224088
Printed on: April 25, 2024 at 14:04 o'clock
4 Comments
Latest comment
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
Gruß
Andi
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
Gruß
Andi
1
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.
Grüße
Filipp
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)heute beschränkt man sich üblicherweise auf Werte die in der selben DNS Domaine liegen um Cache-Poisoning zu erschweren.
Grüße
Filipp
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
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
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
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
1
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
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
