DNSsec-Validierung von "www.glasfaserforum.de" zeigt Probleme!

  • Lazze : Mit dem DNSsec-Validator (https://dnsviz.net/d/www.glasfaserforum.de/dnssec/) wird mir aktuell folgendes Problem angezeigt:

    Mit einem Mouseover auf NSEC3 bekommt man sinngemäß die Diagnose:

    "NSEC3 record(s) proving non-existence (NODATA) of glasfaserforum.de/DS"

    Es liegt vermutlich daran, dass "glasfaserforum.de" an meinem Windows-PC mit dem dort verwendeten DNSsec-validierenden Resolver unbound zeitweise nicht auflösbar ist (ich muss den unbound-Dienst dann immer stoppen und neu starten :().

  • Hi ::1 - unser Hosting-Dienstleister erlaubt uns leider nicht direkt die DNSSEC Einstellungen anzupassen. Ich habe hierzu mal den Hoster kontaktiert. Ich rechne allerdings erst mit einer Antwort ab Beginn der kommenden Woche. Haben weitere User ähnliche Probleme?

  • Das Problem tritt bei mir erst seit einigen Tagen und nur sporadisch an jenen meiner PC auf, auf denen ich den validierenden Resolver unbound verwende. Und es hilft dann immer ein Neustart des unbound-Dienstes, vermutlich weil dadurch dessen Resolver-Cache geleert wird, der zuvor vermutlich einen Sperreintrag (does not exist) für "glasfaserforum.de" enthielt.

    Ich würde vermuten, dass das Problem mit jedem validierenden Resolver auftreten könnte, und das sollten heutzutage eigentlich alle Resolver sein, die von Internet-Providern zur Nutzung durch deren Kunden bzw. von den big Playern wie Google u.s.w. für die allgemeine Verwendung bereitgestellt werden.

    Ich stecke jetzt fachlich nicht so tief im DNSsec, aber ich deute die Situation so, dass die NSEC3-Einträge in der de-Domain die Nicht-Existenz der Child-Domain "glasfaserforum.de" behaupten. Andererseits nutzt "glasfaserforum.de" selbst kein DNSsec (vielleicht einführen?). Wie da genau die Regeln der Delegierung von signierten Parent- (de) zu nicht-signierten Child-Zonen (glasfaserforum.de) aussehen müssen, damit validierende Resolver bzw. deren Nutzer keine Probleme bekommen (sprich ein NXDOMAIN zurückgeben bzw. erhalten), vermag ich an dieser Stelle auch nicht zu sagen.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Ich habe die Ursache des Problems gefunden:

    Es hat nichts mit DNSsec zu tun, sondern mit einem Mismatch von "Glue-Records" für den Nameserver "ns3.nshost2.net" in der Parent-Zone "net." für die Delegierung der Zone "nshost2.net."

    Die korrekten IPv4/IPv6-Adressen von "ns3.nshost2.net" lauten:

    Code
    C:\>nslookup -q=A+AAAA ns3.nshost2.net.
    Server:  localhost
    Address:  ::1
    
    Nicht autorisierende Antwort:
    Name:    ns3.nshost2.net
    Addresses:  2a0a:4cc0:c1:660:880a:29ff:feb2:ada5
              152.53.140.148

    Frage ich nun aber einen DNS-Server (z.B. "g.gtld-servers.net."), der autoritativ für "net." ist, nach den IPv4/IPv6-Adressen von "ns3.nshost2.net", so erhalte ich falsche Glue-Werte (falsch: 2a01:50c0:1001:1::5:4 statt korrekt 2a0a:4cc0:c1:660:880a:29ff:feb2:ada5 bzw. falsch 89.107.184.91 statt korrekt 152.53.140.148) zurück:

    Warum ist das nun ein Problem?

    Die autoritativen Nameserver für die Zone "glasfaserforum.de." sind:

    Code
    C:\>nslookup -q=NS glasfaserforum.de.
    Server:  localhost
    Address:  ::1
    
    Nicht autorisierende Antwort:
    glasfaserforum.de       nameserver = ns5i.nshost2.net
    glasfaserforum.de       nameserver = ns4i.nshost2.de

    Um https://www.glasfaserforum.de auflösen zu können, muss der Resolver also zunächst die IPv4/IPv6-Adressen von ns4i.nshost2.de und/oder ns5i.nshost2.net ermitteln.

    Um ns5i.nshost2.net aufzulösen, muss er wiederum einen der autoritativen Nameserver von nshost2.net befragen. Das ist einer der folgenden Nameserver:

    Code
    C:\>nslookup -q=NS nshost2.net.
    Server:  localhost
    Address:  ::1
    
    Nicht autorisierende Antwort:
    nshost2.net     nameserver = ns1.nshost2.de
    nshost2.net     nameserver = ns2.nshost2.de
    nshost2.net     nameserver = ns3.nshost2.net

    Wählt mein Resolver dummerweise den ns3.nshost2.net zur Adressauflösung von ns5i.nshost2.net aus, so erhält er als dessen Adressen aus der Parent-Zone lediglich die falschen Glue-Werte 2a01:50c0:1001:1::5:4 und 89.107.184.91 - von diesen Adressen kommen aber keine DNS-Antworten.

    Nach etwa 1 Minute versucht es mein Resolver dann endlich mit einem der beiden anderen Nameserver ns1.nshost2.de bzw. ns2.nshost2.de. Hierfür erhält er von einem autoritativen Nameserver der übergeordneten "de."-Zone (z.B. "f.nic.de") folgende Delegierungsinformationen:

    Hier stimmen zumindest die Glue-Werte für die IPv4-Adressen von "ns1.nshost2.de" (89.107.184.116) und "ns2.nshost2.de" (89.107.185.20) mit den tatsächlichen Adressen dieser beiden Nameserver überein:

    In den Delegierungsinformationen in der Zone "de." fehlen allerdings die IPv6-Adressen von "ns1.nshost2.de" und "ns2.nshost2.de".

    Aber immerhin kann mein Resolver über die IPv4-Adressen von "ns1.nshost2.de" und "ns2.nshost2.de" die IPv4/IPv6-Adressen von ns4i.nshost2.de und ns5i.nshost2.net ermitteln und schließlich über deren Adressen "https://www.glasfaserforum.de" auflösen.

    Lazze :

    Ich würde mich mal freundlich an den/die Admin(s) von "nshost2.net" und "nshost2.de" wenden, um

    • in der Parent-Zone "net." die Glue-Records für ns3.nshost2.net. korrigieren zu lassen.
    • in der Parent-Zone "de." Glue-Records für die IPv6-Adressen (AAAA) von ns1.nshost2.de und ns2.nshost2.de ergänzen zu lassen.
  • Die Website https://wintelguy.com/dns-report.pl bietet eine DNS-Analyse und bestätigt meine Findings:

    DNS-Zone nshost2.net:

    Das Bild zeigt im oberen Teil die Delegierungs-Informationen der Parent-Zone "net." (ermittelt über deren autoritativen Nameserver "g.gltd-servers.net.") für die Child-Zone "nshost2.net."

    Im unteren Teil werden die autoritativen Nameserver der Child-Zone "nshost2.net." gelistet.

    Während die unteren A-RR und AAAA-RR für den Nameserver "ns3.nshost2.net." korrekt sind (aus autoritativer Quelle ermittelt), weist die Parent-Zone "net." falsche Glue-Records für "ns3.nshost2.net." auf.

    Die korrekten Adressen von "ns3.nshost2.net." kann ein Resolver hier nur dank der Nameserver "ns1.nshost2.de." bzw. "ns2.nshost2.de." ermitteln, da diese ebenfalls autoritativ für die Child-Zone "nshost2.net." sind.


    DNS-Zone nshost2.de:

    Das Bild zeigt im oberen Teil die Delegierungs-Informationen der Parent-Zone "de." (ermittelt über deren autoritativen Nameserver "n.de.net.") für die Child-Zone "nshost2.de."

    Im unteren Teil werden die autoritativen Nameserver der Child-Zone "nshost2.de." gelistet.

    Während die Glue-Records (A-RR) für beide Nameserver "ns1.nshost2.de." und "ns2.nshost2.de." korrekt in der Parent-Zone "de." vorhanden sind, fehlen dort hingegen die Glue-Records für deren IPv6-Adressen (AAAA-RR). Das ist derzeit zwar nur "unschön", solange fragende DNS-Resolver IPv4 und IPv6 sprechen können. Für einen IPv6-only DNS-Resolver wäre das allerdings fatal.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Ein Teilerfolg:

    Das erste Problem (net. --- AAAA glue mismatch ---> nshost2.net.) wurde nun offenbar behoben - Applaus! :


    Für die noch ausstehende Beseitigung des 2. Problems (de. --- missing AAAA glue ---> nshost2.de.) gäbe es noch einen Extra-Applaus:


    Zur Erinnerung:

    "ns1.nshost2.de", "ns2.nshost2.de" und "ns3.nshost2.net" sind autoritativ für die DNS-Zonen "nshost2.de" und "nshost2.net" und werden benötigt, um die IPv4/IPv6-Adressen der beiden Nameserver "ns4i.nshost2.de" und "ns5i.nshost2.net" zu ermitteln, die ihrerseits autoritativ für die DNS-Zone "glasfaserforum.de" sind.