Loopback address Was: merkwürdiges ssh Verbindungsproblem

[Florian Lohoff]

Hola,

On Mon, Jan 20, 2025 at 07:44:51PM +0100, Sascha Effert wrote:
> Hi,
> 
> Und warum möchte ivh einen systemd-resolved wenn ich einen lokalen DNS
> Server laufen habe? Damit /etc/hosts und co noch ausgewertet werden?

Aeh - /etc/hosts hat mit systemd-resolved erstmal nichts zu tun. /etc/hosts
wird direkt aus der libc gelesen und dort ausgewertet (bzw libnss-files).
resolved cached das zwar - aber im default setup macht das schon die
glibc.  Wenn du natürlich eine applikation hast die _zwingend_ einen DNS
Server (Und NUR einen DNS Server) kann dann kannst du den via
systemd-resolved dazu bringen trotzdem die /etc/hosts einträge zu
fressen.

Man muss dafür erstmal verstehen das das DNS interface auf 127.0.0.53
nur ein "legacy compatibility interface" ist. Damit stellt
systemd-resolved auch noch eine möglichkeit für applikationen die z.b.
libadns benutzen, oder irgendwas handgeklöppeltest haben für DNS
resolutions zur Verfügung.

Das eigentliche systemd-resolved interface steckt in DBUS und
der libnss-resolve.

Dafür muss man in das NSS (Name Service Switch) interface der glibc
tauchen. Das ist am ende eine modulare möglichkeit jegliche
namensauflösung (nicht nur DNS sondern auch user, groups etc) zu
betreiben. Die config dafür um einzustellen in welcher reihenfolge
welche module z.b. für die DNS Namensauflösung benutzt werden steckt in
/etc/nsswitch.conf

Bei mir:

flo at p5:~$ grep hosts /etc/nsswitch.conf 
hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname mymachines

Hier steht die reihenfolge für DNS Namensauflösungen:

1. files also /etc/hosts (Kann resolved auch)
2. mdns4 - bonjour/zeroconf/avahi für die DNS TLD .local (Kann resolved mittlerweile auch)
   -> Wenn NOTFOUND (was nur bei .local passieren kann) dann aufhören
3. resolve - systemd-resolved via libnss-resolve

Die ersten beiden könnte ich bei mir eliminieren - ist nur noch
historie.

Damit fragt deine glibc direkt in den lokalen DNS cache ohne das via DNS Pakete
an den DNS Cache deines Providers zu machen.

Dazu kann die DBUS API an den systemd-resolved auch zurückliefern 
ob und was an dem DNS Request kaputt gegangen ist - z.b. DNSSEC
Validierungsfehler. Von einem "normalen" recursor würdest du sonst
nur antworten bekommen die deine applikation nicht von "existiert nicht"
unterscheiden kann.

Dazu kommen halt tonnen von "convenience" wie fallback/failover state 
von mehreren nameservern in /etc/resolv.conf (Was der glibc resolver
nicht macht) etc etc.

Dann cached der systemd-resolved ja die /etc/hosts so das nicht jeder
gethostnamename nachsehen muss ob sich die datei nicht vielleicht
geeändert hat weil du das netz gewechselt hat.

Insgesamt sollte ein lokales systemd-resolved die DNS resolution
signifikant beschleunigen.

Flo
-- 
Florian Lohoff                                                     f at zz.de
  Any sufficiently advanced technology is indistinguishable from magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20250120/05cc8528/attachment.sig>