Ich habe mir einen kleinen Resolver (Ubuntu 22.0.4) für Server (Debian 11) im Cloud vLAN auf Basis von Unbound aufgesetzt. Auf zwei älteren Servern (S1, S2), die durch Upgrades auf Debian 11 gebracht wurden, ist sysmd-resolved nicht aktiv und die Nameserver (Resolver) werden direkt in der /etc/resolv.conf festgelegt. Ich trage da die vLAN-IP (v4 und v6) des eigenen Resolvers ein. Zusätzlich noch einen der Resolver von Google oder Cloudflare für den Fall, dass mein Resolver mal down ist. Das klappt prima, die benutzen seit mehreren Tagen ununterbrochen den ersten Nameserver aus der /etc/resolv.conf, die IPv4 meines Resolvers. Also wie geplant.
Jetzt zum Problem: Die beiden anderen Server benutzen systemd-resolved. Hier habe ich den Stub-Resolver erst mal aktiv gelassen und in der /etc/systemd/resolved.conf die selben Nameserver in der selben Reihenfolge eingetragen. Auch das funktioniert dann einige Stunden oder einen halben Tag lang einwandfrei. Auch diese Server schicken ihre DNS Queries per IPv4 über das Cloud vLAN an meinen Resolver. Irgendwann löst dann z.B. Postfix eine Query für den PTR eines Möchtegern-Spammers aus und Unbound stellt fest, dass die Daten nicht valide sind und gibt den Status SERVFAIL zurück. Passiert das öfter (und Spammer haben die unangenehme Eigenschaft, nicht so schnell aufzugeben. In diesem Fall vielleicht sogar gezielt, um den unangenehmen Resolver loszuwerden), dann wird der Resolver gewechselt, irgendwann lande ich dann unweigerlich bei Google/Cloudflare. Das möchte ich möglichst vermeiden, außer es geht eben wirklich nicht anders.
Würde es helfen, den Stub-Resolver abzuschalten in der /etc/systemd/resolved.conf und den Symlink /etc/resolv.conf entsprechend umzustellen oder deaktiviert man besser gleich den systemd-resolved komplett? Ich stelle immer mehr fest, dass ich noch zu wenig darüber weiss und das Internet auch nicht viel schlauer ist als ich. Zwei Quellen ergeben drei unterschiedliche empfohlene Vorgehensweisen. Oder ist es besser, den Unbound so einzustellen, dass er bei nicht validierenden RRs niemals SERVFAIL zurückgibt, die Bogusdaten an den Client schickt und nur da ad-Flag nicht setzt? Das ist natürlich ein Risiko, wenn der Client die invaliden Daten benutzt. Dass systemd-resolved da empfindlich reagiert und von eingeschränkten Fähigkeiten des Resolvers ausgeht, ist bekannt, es gibt diverse Issues dazu auf Github, manche davon nach vielen Jahren immer noch offen.