DANE - TLSA-Records werden nicht gefunden

  • Moin zusammen,


    ich setze seit rund anderthalb Jahren DANE ein, was bislang auch recht problemlos funktioniert hat. Die Zertifikate liefert letsencrypt, und sobald ein neues Zertifikat erstellt wurde, rotiert ein Skript die TLSA-Records in den betroffenen Zonefiles meiner beiden Domains. So weit, so gut.


    Seit Sonntag funktioniert das aber nur noch bei einer Domain, bei der anderen werden die TLSa-Records nicht mehr gefunden:


    $ dig _443._tcp.syncookie.de IN TLSA @ormanns.net +short:

    3 1 1 4F5FF30E3A1B43A88224689922E95B42305F422DBC7E42FE53B36CEE 8D1E9EC1


    "$ dig _443._tcp.ormanns.net IN TLSA @ormanns.net +short" liefert hingegen nichts, und lasse ich "+short" weg, sehe ich, dass die Ausgabe ein NXDOMAIN ausspuckt.


    Also schaue ich ins Zonefile. Dieses enthält u.a. folgende Records

    Sieht für mich soweit erstmal okay aus, aber vielleicht hat das Zonefile ja einen anderen Fehler?


    # named-checkzone ormanns.net /var/cache/bind/ormanns.net.zone

    zone ormanns.net/IN: loaded serial 2018101744

    OK

    Das Zonefile scheint also auch zu passen. Mir gehen gerade ein bisschen die Ideen aus, wo ich noch ansetzen könnte - ich wäre daher für Input dankbar.


    Beste Grüße,

    Aleph


    Nachtrag: bei mir läuft bind-9.14.8

  • Wurde andersherum getestet, dass für beide Domänen die richtigen/selben DNS-Server zuständig sind? Ist das Problem reproduzierbar, wenn die Abfrage direkt an die IP-Adresse desjenigen DNS-Servers gerichtet wird, dessen Zonefile oben auszugsweise angegeben wurde (um jegliche Verwechslung auszuschließen, vom selben Host via 127.0.0.1 und danach von einem anderen aus)?

  • Wurde andersherum getestet, dass für beide Domänen die richtigen/selben DNS-Server zuständig sind? Ist das Problem reproduzierbar, wenn die Abfrage direkt an die IP-Adresse desjenigen DNS-Servers gerichtet wird, dessen Zonefile oben auszugsweise angegeben wurde (um jegliche Verwechslung auszuschließen, vom selben Host via 127.0.0.1 und danach von einem anderen aus)?

    Ja, wenn ich den Master unter 127.0.0.1 abfrage, wird ebenfalls ein NXDOMAIN ausgegeben.


    ein Tipp: lasse den private Key unverändert, dann bleiben auch die TLSA-Records die selben

    Ja, auf die Möglichkeit bin ich kürzlich auch gestoßen, die kam, nachdem ich mir mein Skript gebaut hatte. Und da es bislang anderthalb Jahre lang lief, habe ich es nicht mehr angefasst.

    Nichtsdestotrotz interessiert mich natürlich, warum nun auf einmal dieser Fehler auftritt.

  • Nichtsdestotrotz interessiert mich natürlich, warum nun auf einmal dieser Fehler auftritt.

    den Hinweis des Problems hast Dir bereits selbst mit dem DNS-Request vom Master unter 127.0.0.1 gegeben;

    dort musst ansetzen;

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

  • Ich konnte das Problem lösen. Laut https://dnsviz.net/d/ormanns.net/dnssec/ war mein dritter Nameserver nicht mehr per IPv6 erreichbar. Nachdem ich das gefixt hatte, konnte ich auch wieder die TLSA-Records auflösen. Die Nameserver für ormanns.net sind in IPv4 als auch in IPv6 hinterlegt, wohingegen die Nameserver für syncookie.de nur in IPv4 eingetragen sind - daher rührte dann wohl das Phänomen, dass die Auflösung der TLSA-Records bei einer Domäne funktionierte und bei der anderen nicht...