[Fli4l_dev] DNS_ZONE_DELEGATIO?==?utf-8?Q?N delegiert zu viele reverse?==?utf-8?Q? lookups

Mi Mai 14 02:18:21 CEST 2014

Hallo,

wie in einem anderen Thread erwähnt, habe ich heute Tarball 30870 auf
einem meiner Router installiert, musste aber kurz danach wieder auf
30811 zurückgehen.

Die Umgebung sieht folgendermaßen aus:

ein fli4l mit (halbwegs, siehe oben) aktuellem Tarball im Büro
ein fli4l mit (derzeit noch) 3.4.0 zuhause.

Im Büro gibt es drei (getrennte) Netze:
- 10.10.0.0/23
- 10.10.2.0/24
- 10.10.3.0/24
Ein viertes Netz 10.10.8.0/24 ist über einen internen Router
erreichbar, DNS-mäßig ist dafür auch der fli4l zuständig.

Zuhause gibt es nur ein Netz:
- 10.0.0.0/24

Die beiden Router sind quasi permanent über einen OpenVPN-Tunnel
verbunden, die jeweiligen tunN Devices haben die Adressen 192.168.220.1
(Büro) und 192.168.220.2 (zuhause).

Für die DNS-Auflösung habe ich bisher DNS_REDIRECT verwendet und tu
das auf dem heimischen fli4l nach wie vor. Im Tarball gibt es jetzt auch
die Möglichkeit einer zone delegation, ich hab daher folgendes
konfiguriert:
DNS_ZONE_DELEGATION_N='1'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_N='1'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_IP='10.0.0.254'
DNS_ZONE_DELEGATION_1_DOMAIN_N='1'
DNS_ZONE_DELEGATION_1_DOMAIN_1='meinedomain.lan'
DNS_ZONE_DELEGATION_1_NETWORK_N='1'
DNS_ZONE_DELEGATION_1_NETWORK_1='10.0.0.0/24'
DNS_REBINDOK_N='1'
DNS_REBINDOK_1_DOMAIN='meinedomain.lan'

Daraus generiert fli4l beim Start folgende
/etc/dnsmasq.d/dns_delegate.conf:
server=/meinedomain.lan/10.0.0.254
rebind-domain-ok=meinedomain.lan
server=/10.in-addr.arpa/10.0.0.254
rebind-domain-ok=meinedomain.lan
..
local=/.10.in-addr.arpa/
..

und zusätzlich noch eine /etc/dnsmasq.d/dns_delegate_ovpn.conf:
server=/meinedomain.lan/192.168.220.2
rebind-domain-ok=meinedomain.lan
server=/10.in-addr.arpa/192.168.220.2
(in meinen Augen eigentlich überflüssig, kommt möglicherweise von
OPENVPN_1_DOMAIN='meinedomain.lan' - kann ich vermutlich weglassen)

Wie man sieht, wird hier das komplette 10er-Netz für reverse lookups
einmal an 10.0.0.254 delegiert, scheint aber auch für lokale
Verarbeitung auf (einmal mit und einmal ohne einen "." vor der 10, aber
das nur am Rande).

Eigentlich sollten ja nur 0.0.10.in-adr-arpa Requests vom Büro an den
Server zuhause weitergeleitet werden, und der Büro-Router sollte sich
nur für 10.10.in-addr-arpa (und auch hier eigentlich nur für
10.10.0.0/20) zuständig fühlen.

Ein Blick in die dnsmasq manpage
(<http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html>) zeigt,
dass als Alternative zu server=... auch rev-server=... verwendet werden
kann, wo anstelle des in-addr.arpa Namens auch ein Netz mit
Subnetz-Spezifikation angegeben werden kann, also

rev-server=10.0.0.0/24,10.0.0.254
statt
server=/10.in-addr.arpa/10.0.0.254

Spricht was dagegen, diese Syntax in fli4l zu implementieren?

Warum ich das vorschlage:

mein Notebook (10.10.0.126) mit Windows 7 hat heute im Büro folgende
Anfragen an den fli4l geschickt (syslog prefix entfernt):

query[PTR] b._dns-sd._udp.bitco.lan from 10.10.0.126                  
config b._dns-sd._udp.bitco.lan is NXDOMAIN                           
query[PTR] db._dns-sd._udp.bitco.lan from 10.10.0.126                 
config db._dns-sd._udp.bitco.lan is NXDOMAIN                          
query[PTR] r._dns-sd._udp.bitco.lan from 10.10.0.126                  
config r._dns-sd._udp.bitco.lan is NXDOMAIN                           
query[PTR] dr._dns-sd._udp.bitco.lan from 10.10.0.126                 
config dr._dns-sd._udp.bitco.lan is NXDOMAIN                          
query[PTR] lb._dns-sd._udp.bitco.lan from 10.10.0.126                 
config lb._dns-sd._udp.bitco.lan is NXDOMAIN

bis hierher noch ganz ok. Aber jetzt: obwohl die reverse lookups das
Netz im Büro betreffen (0.0.10.10.in-addr.arpa), werden sie an den
fli4l zuhause weitergeleitet:

query[PTR] b._dns-sd._udp.0.0.10.10.in-addr.arpa from 10.10.0.126     
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254         
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2
query[PTR] db._dns-sd._udp.0.0.10.10.in-addr.arpa from 10.10.0.126    
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254        
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2     
query[PTR] r._dns-sd._udp.0.0.10.10.in-addr.arpa from 10.10.0.126     
forwarded r._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254         
forwarded r._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2      
query[PTR] dr._dns-sd._udp.0.0.10.10.in-addr.arpa from 10.10.0.126
forwarded dr._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254    
forwarded dr._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2 
query[PTR] lb._dns-sd._udp.0.0.10.10.in-addr.arpa from 10.10.0.126 
forwarded lb._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254     
forwarded lb._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2

die doppelten Forwards kommen vermutlich wegen der Einträge in
dns_delegate und openvpn.

Der angefragte dnsmasq auf 10.0.0.254/192.168.220.2 (die LAN-Adresse
bzw. der OpenVPN-Endpunkt des Routers) fühlt sich natürlich für
0.0.10.10.in-addr.arpa nicht zuständig (nur für 0.0.0.10.in-addr.arpa)
und leitet die Anfragen wegen des DNS_REDIRECT prompt an den fli4l im
Büro zurück:

query[PTR] b._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.1 
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.10.0.254      
query[PTR] b._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.1 
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.10.0.254      
query[PTR] db._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.1
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.10.0.254     
query[PTR] db._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.1
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.10.0.254     
query[PTR] r._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.1 
forwarded r._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.10.0.254      
query[PTR] r._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.1 
forwarded r._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.10.0.254      

Alles doppelt, weil ja sowohl 10.0.0.254 als auch 192.168.220.2
angefragt werden.

Das ganze führt im Büro zu folgender Reaktion auf dem Büro-fli4l:
query[PTR] b._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.2 
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254       
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2    
query[PTR] b._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.2 
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254       
forwarded b._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2    
query[PTR] db._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.2
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254      
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2   
query[PTR] db._dns-sd._udp.0.0.10.10.in-addr.arpa from 192.168.220.2
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 10.0.0.254      
forwarded db._dns-sd._udp.0.0.10.10.in-addr.arpa to 192.168.220.2   

Die beiden spielen in der Folge Ping-Pong mit ca. 125 query requests und
250 forwards nach zuhause weiter - pro Sekunde, wohlgemerkt. Nach etwa
40 Minuten war im Büro mit einem ca. 100 MB großen /var/log/syslog.log
das tmpfs voll; der heimische Router hat weniger RAM und loggte nur 20
Minuten mit.

Hat sich von tarball 30811 auf 30870 in diesem Bereich irgendwas
geändert? Es war das erste Mal, dass mir so etwas passiert ist, und im
Büro laufen einige weitere Windows 7 PCs rund um die Uhr. Ich bin
jedenfalls nach diesem Vorfall wieder auf 30811 zurück und habe das
Verhalten nicht wieder gesehen.

Bitte baut jedenfalls die reverse-lookup Konfiguration so um, dass nur
die Anfragen weitergeleitet werden für die der angefragte DNS-Server
auch wirklich zuständig ist.

Vielen Dank + schöne Grüße,
Hans.