Outsourcing mit Hindernissen

Beim Durchsehen der Logfiles stieß ich darauf, dass wiki.mozilla.org nicht erreichbar ist. Grund dafür ist ein externer Dienstleister und ein Fehler, über den sich die Experten uneinig sind. Natürlich hängt es mit DNSSEC zusammen.

$ host wiki.mozilla.org 100.100.100.100
Host wiki.mozilla.org not found: 2(SERVFAIL)

$ host wiki.mozilla.org 10.10.10.10
Host wiki.mozilla.org not found: 2(SERVFAIL)

$ host wiki.mozilla.org 8.8.8.8
wiki.mozilla.org is an alias for www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.
www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org is an alias for wiki-prod-1394614349.us-west-2.elb.amazonaws.com.
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 52.89.171.193
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 34.213.203.225
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 54.68.243.126

$ host wiki.mozilla.org 1.1.1.1
wiki.mozilla.org is an alias for www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.
www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org is an alias for wiki-prod-1394614349.us-west-2.elb.amazonaws.com.
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 34.213.203.225
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 52.89.171.193
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 54.68.243.126

$ host wiki.mozilla.org 9.9.9.9
Host wiki.mozilla.org not found: 2(SERVFAIL) 

Das ist ein Chaos, oder etwa nicht?

Was sagt denn DNSViz?

wiki.mozilla.org-2018-04-20-18_49_55-UTC

Die Erklärungen zu den Fehlerdreiecken umfassen:

  • Die Liste der Nameserver für allizom.org unterscheidet sich bei der Mutterzone "org" von der realen Zone. Dieser Glue-Mismatch ist aber nicht tragisch.
  • Bestimmte Antworten für SOA etc. werden bei der unsignierten Zone nicht beantwortet. Das wird als kritisch bewertet, ist es aber in der Regel nicht, da diese Anfragen für die Namensauflösung nicht notwendig sind.

Woran scheitert also ein Teil der Nameserver?

unbound info: validation failure <wiki.mozilla.org. A IN>:
 no NSEC3 closest encloser from 184.26.160.65 for DS nubis.allizom.org.
 while building chain of trust 

Was ist denn nubis?

wiki.mozilla.org.  CNAME  www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.
;; Received 107 bytes from 2600:1401:2::f0#53(ns1-240.akam.net) in 16 ms 

Ahja, eine Zwischenzone auf dem Weg zum eigentlichen Ziel.

www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.  CNAME  wiki-prod-1394614349.us-west-2.elb.amazonaws.com.
;; Received 275 bytes from 2600:9000:5302:cf00::1#53(ns-719.awsdns-25.net) in 17 ms 

Der entscheidende Teil ist, dass allizom.org signiert ist.

allizom.org.  SOA infoblox1.private.mdc2.mozilla.com. sysadmins.mozilla.org. 2018032753 180 180 1209600 3600
allizom.org.  RRSIG   SOA 7 2 3600 20180423125954 20180420115954 42215 allizom.org. E...
;; Received 563 bytes from 23.211.133.65#53(use4.akam.net) in 22 ms 

Allerdings scheint die Implementierung der beteiligten Nameserver (oder gar der Quelle, also der Infoblox) defekt zu sein, denn die notwendigen Nichtexistenzbeweise über die Abwesenheit einer sicheren Delegierung (also eine unsichere Delegierung) fehlen.

Genau genommen handelt es sich um ein empty non-terminal, also einen DNS-Namen, den der keine eigenen Datensätze enthält. Stattdessen existiert er ausschließlich virtuell. Denn die reale Delegierung lautet:

appsvcs-generic.nubis.allizom.org. NS   ns-795.awsdns-35.net.
appsvcs-generic.nubis.allizom.org. NS   ns-1743.awsdns-25.co.uk.
appsvcs-generic.nubis.allizom.org. NS   ns-426.awsdns-53.com.
appsvcs-generic.nubis.allizom.org. NS   ns-1109.awsdns-10.org.
;; Received 481 bytes from 2600:1401:2::f0#53(ns1-240.akam.net) in 16 ms

Der Name "nubis.allizom.org" entsteht ausschließlich durch die Verwendung von Punkten im längeren Namen.

DNSSEC ist das aber völlig egal: Der Name ist ein gültiger Name im DNS, also muss darüber eine Aussage her. Und wenn es ein Nichtexistenzbeweis ist. Deswegen verlangt DNSSEC, dass auch für derartige virtuellen "empty non-terminals" entsprechende DNSSEC Records erzeugt werden.

Und genau die fehlen hier.

nubis.allizom.org-2018-04-20-19_30_18-UTC-1

Damit kann ein validierender Resolver nicht beweisen, dass die unsichere Delegation der Zone "appsvcs-generic.nubis.allizom.org" korrekt ist. Es könnte ja ein Man in the Middle versuchen, die mögliche Existenz einer sicheren Delegierung für "nubis.allizom.org" auszufiltern!

An dieser Stelle unterscheiden sich die Implementierungen der DNS-Resolver.

  • Es gibt welche, die jedes noch so kleine Detail prüfen. Wie unbound, den ich für die Server 10.10.10.10 und 100.100.100.100 benutze. Oder knot, der bei 1.1.1.1 läuft.
  • Und es gibt welche, die nur dem eigentlichen Pfad folgen und sich für die Infrastruktur auf andere interne Mechanismen verlassen. Wie Google und Cloudflare.

Interessant ist, dass bei Cloudflare und Google eigene DNS-Implementierungen laufen, die nicht auf die klassischen Opensource-Produkte zurück greifen. Auch Infoblox fährt sein eigenen Süppchen. Und Route66 von Amazon ist auch eine Eigenentwicklung.

Ich bin sehr an einigen Details interessiert, warum die Eigenentwicklungen genau versagen: Die einen beim Erzeugen oder Verteilen, die anderen beim Validieren.

Merke, Mozilla: Größe ist nicht alles.

Avatar
Jens Hofer 30/09/2022 11:45 pm
Infoblox kocht da kein eigenes Süppchen, die benutzen einen (leicht angepassten ISC DHCP).
Avatar
Alexander Dupuy 20/05/2018 9:55 pm
Eigentlich, der rekursive Resolver-Dienst 1.1.1.1 verwendet den Opensource-Produkte Knot-Resolver.

Nur für den autoritativer DNS-Dienst Nameserver führt Cloudflare eine
eigene DNS-Implementierungen aus.
Avatar
Lutz Donnerhacke 23/04/2018 1:16 pm
Und geht wieder. Mozilla hat den Fehler berichtigen lassen, die Zone wurde neu signiert und verteilt. Alles wieder prima.
Avatar
Lutz Donnerhacke 20/04/2018 10:58 pm
Mozilla sucht den Fehler bereits:
https://bugzilla.mozilla.org/show_bug.cgi?id=1451364

Total 4 comments

Post a comment

Related content