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?
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.
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.
Nur für den autoritativer DNS-Dienst Nameserver führt Cloudflare eine
eigene DNS-Implementierungen aus.
https://bugzilla.mozilla.org/show_bug.cgi?id=1451364
4 Kommentare