07.12.2023, aktualisiert um 11:38:47 Uhr

1584

DNS-Auflösung per Pi-hole über Android mit deutlicher Verzögerung

Hallo zusammen,

Ich habe Zuhause u. a. diese Infrastruktur:

Mikrotik hAP AC als Router
Raspberry-Pi 4, auf dem per Docker Pi-hole läuft
Mehrere Adroid-Handies
Windows-10- und Linux-PCs

Seit einiger Zeit beobachte ich, dass Aufrufe von Webseiten über die Android Handies sekundenlang "hängen", bevor die Webseite in gewohnter Geschwindigkeit schlagartig komplett geladen wird. Daher hatte ich DNS in Verdacht. Bei allen anderen Geräten beobachte ich das nicht.

Alle Geräte sind über IPv4 und IPv6 angebunden. ping6 / ping -6 funktionieren jeweils. Eigentlich sollte aber alles aus meiner Sicht eindeutig über IPv4 laufen. Auszug Mikrotik (alle genannten Geräte sind in dem Netzwerk):

/ip dhcp-server network print
Flags: D - dynamic 
 #   ADDRESS            GATEWAY         DNS-SERVER                                                                                             WINS-SERVER     DOMAIN                                                                                      
 0   ;;; Heim-Netzwerk
     192.168.1.0/24     192.168.1.1     192.168.1.151                                                                                         

In Pi-hole, lokales DNS gibt es u. a. folgende Einträge:

192.168.1.151 für rpi.local
192.168.1.151 für eine Dyn-DNS-Adresse

Folgende Befehle unter Termux auf einem Android Handy geben mir einen reproduzierbaren Output:

~ $ time nslookup rpi.local rpi.local
Server:         rpi.local
Address:        192.168.1.151#53

Name:   rpi.local
Address: 192.168.1.151


real    0m2.128s
user    0m0.013s
sys     0m0.038s
~ $ time nslookup rpi.local 192.168.1.151
Server:         192.168.1.151
Address:        192.168.1.151#53

Name:   rpi.local
Address: 192.168.1.151


real    0m0.052s
user    0m0.003s
sys     0m0.021s

Das irritiert mich: Es wird ihm die IP des DNS-Servers genannt. Darüber kann ich rpi.local sofort auflösen. Wenn ich rpi.local als DNS-Server angebe (was dann ja einfach wieder aufgelöst werden müsste?!) dauert es zusätzliche 2 Sekunden. Da es meist ziemlich genau knapp über 2 Sekunden liegt, kommt mir etwas wie ein Timeout in den Sinn.

Die beiden Anfragen ergeben folgendes Logging in Pi-hole:

Dec  7 11:26:31: query[A] rpi.local from 192.168.1.17
Dec  7 11:26:31: /etc/pihole/custom.list rpi.local is 192.168.1.151
Dec  7 11:26:31: query[AAAA] rpi.local from 192.168.1.17
Dec  7 11:26:31: cached rpi.local is NODATA-IPv6

Dec  7 11:26:46: query[AAAA] rpi.local from 192.168.1.17
Dec  7 11:26:46: cached rpi.local is NODATA-IPv6
Dec  7 11:26:46: query[A] rpi.local from 192.168.1.17
Dec  7 11:26:46: /etc/pihole/custom.list rpi.local is 192.168.1.151
Dec  7 11:26:46: query[A] rpi.local from 192.168.1.17
Dec  7 11:26:46: /etc/pihole/custom.list rpi.local is 192.168.1.151
Dec  7 11:26:46: query[AAAA] rpi.local from 192.168.1.17
Dec  7 11:26:46: cached rpi.local is NODATA-IPv6

Folgendes Logging bekomme ich noch aus nslookup raus (mit spürbarem Delay nach der Zeile 5 "main parsing rpi.local")

~ $ nslookup -query=A -d2  rpi.local rpi.local
main parsing rpi.local
addlookup()
make_empty_lookup()
looking up rpi.local
main parsing rpi.local
flush_server_list()
make_server(192.168.1.151)
lock_lookup dighost.c:4285
success
start_lookup()
setup_lookup(0xb4000074ca20e018)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(192.168.1.151)
using root origin
recursive query
add_question()
starting to render the message
done rendering
create query 0xb40000744a211418 linked to lookup 0xb4000074ca20e018
do_lookup(0xb4000074ca20e018)
send_udp(0xb40000744a211418)
bringup_timer(0xb40000744a211418)
have local timeout of 5
working on lookup 0xb4000074ca20e018, query 0xb40000744a211418
sockcount=1
recving with lookup=0xb4000074ca20e018, query=0xb40000744a211418, sock=0xb40000742a2144d0
recvcount=1
sending a request
unlock_lookup dighost.c:4287
lock_lookup dighost.c:2615
success
send_done(0xb40000744a211418)
sendcount=0
check_if_done()
list empty
unlock_lookup dighost.c:2646
recv_done(0xb40000744a211418)
lock_lookup dighost.c:3631
success
recvcount=0
before parse starts
after parse
printmessage()
Server:         rpi.local
Address:        192.168.1.151#53

printsection()
Name:   rpi.local
Address: 192.168.1.151
still pending.
cancel_lookup(0xb4000074ca20e018)
check_if_done()
list empty
clear_query(0xb40000744a211418)
sockcount=0
check_next_lookup(0xb4000074ca20e018)
try_clear_lookup(0xb4000074ca20e018)
destroy
freeing server 0xb40000747a20a198 belonging to 0xb4000074ca20e018
start_lookup()
check_if_done()
list empty
shutting down
dighost_shutdown()
unlock_lookup dighost.c:4179

done, and starting to shut down
cancel_all()
lock_lookup dighost.c:4301
success
unlock_lookup dighost.c:4340
destroy_libs()
freeing task
freeing taskmgr
lock_lookup dighost.c:4366
success
flush_server_list()
freeing socketmgr
freeing timermgr
destroy DST lib
unlock_lookup dighost.c:4408
Removing log context
Destroy memory

Die normal schnelle Abrage hat folgendes Logging und unterscheidet sich scheinbar nur in Adressen und Parameter:

~ $ nslookup -query=A -d2  rpi.local 192.168.1.151
main parsing rpi.local
addlookup()
make_empty_lookup()
looking up rpi.local
main parsing 192.168.1.151
flush_server_list()
make_server(192.168.1.151)
lock_lookup dighost.c:4285
success
start_lookup()
setup_lookup(0xb400007c2ed28be8)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(192.168.1.151)
using root origin
recursive query
add_question()
starting to render the message
done rendering
create query 0xb400007baed2f098 linked to lookup 0xb400007c2ed28be8
do_lookup(0xb400007c2ed28be8)
send_udp(0xb400007baed2f098)
bringup_timer(0xb400007baed2f098)
have local timeout of 5
working on lookup 0xb400007c2ed28be8, query 0xb400007baed2f098
sockcount=1
recving with lookup=0xb400007c2ed28be8, query=0xb400007baed2f098, sock=0xb400007b8ed30a50
recvcount=1
sending a request
unlock_lookup dighost.c:4287
lock_lookup dighost.c:2615
success
send_done(0xb400007baed2f098)
sendcount=0
check_if_done()
list empty
unlock_lookup dighost.c:2646
recv_done(0xb400007baed2f098)
lock_lookup dighost.c:3631
success
recvcount=0
before parse starts
after parse
printmessage()
Server:         192.168.1.151
Address:        192.168.1.151#53

printsection()
Name:   rpi.local
Address: 192.168.1.151
still pending.
cancel_lookup(0xb400007c2ed28be8)
check_if_done()
list empty
clear_query(0xb400007baed2f098)
sockcount=0
check_next_lookup(0xb400007c2ed28be8)
try_clear_lookup(0xb400007c2ed28be8)
destroy
freeing server 0xb400007bded35078 belonging to 0xb400007c2ed28be8
start_lookup()
check_if_done()
list empty
shutting down
dighost_shutdown()
unlock_lookup dighost.c:4179

done, and starting to shut down
cancel_all()
lock_lookup dighost.c:4301
success
unlock_lookup dighost.c:4340
destroy_libs()
freeing task
freeing taskmgr
lock_lookup dighost.c:4366
success
flush_server_list()
freeing socketmgr
freeing timermgr
destroy DST lib
unlock_lookup dighost.c:4408
Removing log context
Destroy memory

Was kann ich tun? Wie das Problem eingrenzen / beheben?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 63603661683

Url: https://administrator.de/forum/dns-aufloesung-per-pi-hole-ueber-android-mit-deutlicher-verzoegerung-63603661683.html

Ausgedruckt am: 03.01.2025 um 00:01 Uhr

6 Kommentare

Neuester Kommentar

.local ist die reservierte TLD für mDNS.
Android versucht alle Namen unter .local standardmäßig per mDNS aufzulösen und fallt erst auf normales DNS zurück wenn per mDNS keine Antwort kommt.

Hinweise zur Verwendung der Domäne .local in DNS und mDNS
Lesen und verstehen...

Eigentlich sollte aber alles aus meiner Sicht eindeutig über IPv4 laufen.

Das ist so nicht richtig, denn wenn du, wie du oben selber schreibst, überall mit einem Dual Stack fährst wird bekanntlich IPv6 immer bevorzugt.
https://danrl.com/ipv6/

Zitat von @LordGurke:

.local ist die reservierte TLD für mDNS.
Android versucht alle Namen unter .local standardmäßig per mDNS aufzulösen und fallt erst auf normales DNS zurück wenn per mDNS keine Antwort kommt.

Das passt dann entsprechend gut zu meiner Annahme, dass es ein Timeout ist. Tauchte halt gerne in Anleitungen auf.

Zitat von @aqui:

Hinweise zur Verwendung der Domäne .local in DNS und mDNS
Lesen und verstehen...

Erledigt. Gültige Alternativen wären .lan, .home, .intranet oder laufe ich da in die nächsten Probleme?

Zitat von @aqui:

Eigentlich sollte aber alles aus meiner Sicht eindeutig über IPv4 laufen.

Das ist so nicht richtig, denn wenn du, wie du oben selber schreibst, überall mit einem Dual Stack fährst wird bekanntlich IPv6 immer bevorzugt.
https://danrl.com/ipv6/

Unter dem Link finde ich:

Anwendungen können explizit eines der Protokolle für eine aufzubauende Verbindung bevorzugen oder die Wahl des günstigsten Protokolls dem Betriebssystem überlassen.

Meine Hoffnung war ja, dass wenn ich dem System explizit nur einen IPv4-DNS-Server nenne, dieser bevorzugt wird.

Ich kann mit der Link-lokalen IPv6 per nslookup ein Ergebnis bekommen.

Entsprechend muss ich im Router die IPv6 irgendwie ausgeben? Ich habe dort einen DHCP-Client Richtung Modem, der den Prefix in einen Pool einliest. (Wie) kann ich dort die DNS-IPv6 an die Clients weiterreichen, ohne einen IPv6-DHCP-Server zu starten?

Einfach "Advertise DNS" anhaken!

Guckst du hier:
IPv6 mittels Prefix Delegation bei PPPoE (Mikrotik)

Gültige Alternativen wären .lan, .home, .intranet oder laufe ich da in die nächsten Probleme?

Erstmal nicht. Lesenswert dazu:
https://www.heise.de/select/ct/2017/26/1513540412603853
Wenn du Standard konform und wirklich auf Nummer sicher gehen willst dann hälst du dich an den RFC 8375.

Perfekt, danke dir! Ich habe gestern Abend schon die Link-lokale Adresse des RPi unter /ip dns eingetragen und advertise-dns unter /ip nd aktiviert. Den IPv6-Server unter Android auszugeben ist mir nicht gelungen, aber mein Problem scheint behoben zu sein.