Vor einigen Tagen habe ich meinen Web-Server im lokalen LAN aufgeräumt und viele Services, welche über eine DynDNS-Adresse gegen das Internet zugänglich waren, deaktiviert. Ab sofort können diese Web-Services nur noch mit einer privaten FQDN à la service.server.location.domain.local aus dem LAN angesprochen werden.

Diese Anpassung führte dazu, dass mein Bluetooth-Scanner, welchen ich auf meinem Raspberry Pi betreibe, seine Scan-Resultate nicht mehr an den Web-Server übermitteln konnte. Ein Python-Script führt auf dem RPi alle 5 Minuten einen Bluetooth-Scan durch, übersetzt die Resultate ins JSON-Format und versendet die Daten dann mit requests3 per HTTP an den Web-Server.

Die Fehlermeldung, die das Script ab der Umstellung ausspuckte, lautete folgendermassen:

$ /usr/bin/python /usr/local/bin/bluelog/bluetooth-scan.py --output api
Traceback (most recent call last):
  File "/usr/local/bin/bluelog/bluetooth-scan.py", line 424, in <module>
    response = requests.post(url, json=macs, auth=HTTPDigestAuth('user','password'))
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 110, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 487, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='service.server.location.domain.local', port=80): Max retries exceeded with url: /index.php (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x75e41b10>: Failed to establish a new connection: [Errno -2] Name or service not known',))

Auf dem RPi eingeloggt funktionierte die Namensauflösung mit dem host-Kommando aber problemlos:

$ host service.server.location.domain.local
service.server.location.domain.local has address 10.1.2.3

Doch als ich die Verbindung zum Web-Server mit wget überprüfen wollte schlug auch das fehl:

$ wget http://service.server.location.domain.local/index.php
--2019-02-02 15:56:22--  http://service.server.location.domain.local/index.php
Resolving service.server.location.domain.local (service.server.location.domain.local)... failed: Name or service not known.
wget: unable to resolve host address "service.server.location.domain.local"

Herumgooglen brachte nicht die gewünschte Lösung. Deshalb griff ich zur nächstbesten Lösung und rief wget mit strace auf. Im Trace dann der entscheidende Hinweis:

$ strace wget http://service.server.location.domain.local/index.php
...
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/avahi-daemon/socket"}, 110) = 0
fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
write(3, "RESOLVE-HOSTNAME-IPV4 service.serv."..., 55) = 55
read(3, "-15 Timeout reached\n", 4096)  = 20
close(3)                                = 0
...

Was zum Teufel hat der Avahi-Daemon mit /var/run/avahi-daemon/socket im strace zu suchen? Jetzt hatte ich ausreichend Infos, um Google noch einmal zu befragen. Und siehe da:

Is Avahi running or installed? Avahi uses .local domain for its usage and puts its config in /etc/nsswitch.conf. My experience with it, using a .local domain name for my internal use is that it can be a little flaky (for lack of a better technical term), and would show behavior similar to what you are seeing.

Quelle: [SOLVED] resolver weirdness – avahi and .local

Die Lösung war im selben Beitrag gepostet:

/etc/nsswitch.conf

Aus …

...
hosts:      files mdns4_minimal [NOTFOUND=return] dns
...

… wird folgender Eintrag:

...
hosts:          files dns mdns4_minimal
...

Und seither lösen sich auch die .local-Adressen reibungslos auf.