Arbeitsgruppe Software DNS
Achtung dies ist ein WoW (Maintainer: Markus Kitttenberger)
Immer wieder tauchen Beschwerden über DNs probleme im Funkfuer Netz auf,..
Dieses WoW versucht nun rauszufinden/klären woran das liegt, und wie man dies beheben könnte
Inhaltsverzeichnis
DNS Protokoll
Ist udp basiert, fehlerkorrektur muss dns also selber machen,.. Hierbei gibt es gleich etliche unterschiede zwischen den Betriebsystemem
Nur ein DNS Server?
Trägt man mehrere DNS Server in seinem Betreibsystem ein, verwendet es automatisch die anderen wenn der erste nicht oder verzöget antwortet,.
als Nebeneffekt werden dadruch auch mehr DNS requests versendet als wenn man nur einen eingetragen hat,..
also besser mehr als einen eintragen, je nach Betreibssystem werden meist aber nicht mehr als 3 "gleichzeitig" verwendet
DNS Lookups in Linux (Ubuntu)
Standardmässig sendet Linux alle 4 (bei 3+ DNS Servern) bzw. 5 Sekunden einen Request,.. (d.h. wenns das erste paket verloren geht, dauerts mindestens 5 Skunden )-;)
Maximal 4 mal pro DNS Server
und es werden nur maximal 3 verschiedene Srever verwendet,..
bei nur 1 DNS Server kommts somit nach 20 Sekunden zum timeout (d.h. unresolveable), bei 2 nach 40 Sekunden, und bei 3+ Servern nach 55 Sekunden
DNS Lookup in Windows
In Windows kann ein DNS Lookup standardmässig nur 15 Sekunden dauern (was desweilen zu kurz ist)
Immerhin sendet Windows aber wenn der erste Lookup fehlschlägt/auf sich warten lässt nach 1,2,4 und 8 Sekunden weitere lookups, (also ach dem ersten evt. verlorengeangenen vergleichsweise recht rasch zusätzlcihe DNS requests, d.h. subjektiv resolved windows bei nicht allzulossy links recht zügig)
danach wird noch 7 Sekunden auf etvaige Antworten gewartet, und wenn nix kommt ist die unresoveable
d.h. ein 8 Sekündliches komplett funkloch (oder ein "üblicher" transienter olsr rooting loop) reicht völlig aus um nen Lookup in Windows zum scheitern zu bringen)
Die lookups nach 4 und 8 Sekunden gehen an ALLE eingetragenen DNS Server, die ersten nur an den geraden aktiven primary DNS Server (d.h. mit vielen DNS Servern sendet Windows sehr viele Lookups, die chancen bei hohen packetloss trotzdem ne Antwort zu kriegen steigen also linear mit der Anzahlder eingetragenen Server (getestet mit bis zu 7 Servern))
Allerdings ist Windows in der Lage selbst den Fakt das es KEINE Antwort bekommen hat in seinen eigenen Cache aufzunehmen,.. (Was extrem fragwürdig ist!!!)
und somit wird es nach einem erfolglosen Versuch für weitere 15 Minuten garkein weiteres Mal nen DNS Request für diese Domain senden, sondern sofort unresolveable zurückmelden,..
Nützlich ist da kurzfristig mal ipconfig /flushdns (und /displaydns für neugierige)
Mit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters MaxNegativeCacheTtl=0 kann man wenigsten einstellen wielang ein negatives Lookup Ergebnis gecached werden soll,.. [1]
Dies betrifft zwar leider auch echte Antworten eins echten DNS Server das diese Domain wirklich nicht existiert (was wahrhaftig cachenswert wäre), aber verglichen damit glaub standardmässig 5 Minuten lang eine definitv exisiterende WEbseite nicht öffnen zu können, ist es wohl angebracht hier einen Wert < 10 Sekunden einzutragen,..
Eine klügere selektivere Lösung wäre aber vorteilhaft,.. Ideen?
DNSMASQ oder anderen DNS Forwarder so patchen das er innerhalb von 15 Sekunden eine Antwort zurückschickt, mit einem 0 Sekunden cachedauer,.. allerdings hat dies wohl recht negative Auswirkungen auf Linux Clients usw,..
Somit ists wohl am besten windows clients das cachen von negativen und keinen Antworten mit einem sehr kurzen MaxNegativeCacheTtl zu verübeln, aber einen lokalen DNS-Cache zu verwenden der sich dann wenigstens (nur) echte negative Antworten merkt,..
ein Möglichkeit dafür, ist dnsmasq am funkfeuer router laufen zu haben,..
DNS Lookups in Openwrt (DNSMASQ)
wie brauchbar diese wirklich ist, ist noch genauer auszutesten,.. (Allerdings war er bei manchen tests auf lossy links scheinbar schneller als erwartet) evt. sendet er also nicht erst nach 4-5 Sekunden den zweiten request,..
Standardmässig cached er nur 150 Einträge,.. dies und vieles andere lässt sich aber inder dnsmasq.conf bzw. /etc/local.dnsmasq.conf ändern
TCP DNS
DNS selbst verwendet für grössere requests (z.B. zone transfers) TCP anstatt UDP, und es ist RFC konform dies auch bei kleinen anfragen zu machen,..
Allerdings kenn ich keine Clients die das machen würden,..
aber es gibt z.B.: [2] udp2tcp welches man als DNS Forwarder einsetzen kann
Aber wird es dadurch wirklich besser?
Nachteile:
TCP braucht mehr ressourcen, und ist etwas langsamer als UDP, (d.h. bei exterm guter anbindung eher nicht)
Weiters ist bei extrem hohen packet loss (selbst bei kleinen Paketen) es meist kaum noch möglich einen TCP Verbindung aufzubuaen, hier funktineort DNS over TCP also auch nciht mehr (auf derart schlechten links geht aber auch kein anderer tcp-traffic mehr (also soweiso keine webseiten/downloads etc.))
Bei mässigen packet loss, und vorallem bei klar definierten kurzen komplettausfällen (z.b.: 2 oder 3 Sekunden), ist DNS over TCP jedoch weitaus agiler als UDP
udp2tcp ist leider ziemlich minimalistisch, recycelt tcp connections nicht, und schliesst sie auch nicht, und berbraucht somit vielzuviel ressourcen (vorallem RAM) am router,..
Was wäre IDEAL?
Gute Frage (-;
evt. ein hybrides DNSMASQ welches zuerst UDP versucht, dann es auch per TCP versucht, und wenn das auch nix hilft, mit (brute force) mit vielen UDP Paketen, und welches adaptiv, je nach Lookup loss zu den einzelnen servern deren reihenfolge intelligent verwaltet, auch proaktiv Server paralell zum ersten primary dns lookup mittestet, um schon vorher zu wissen was die zweitbeste Wahl ist,..
ca. so: (evt. ein bißchen übertrieben)
Zeit in Sekunden
0 Primary DNS UDP (evt paraleller lookup zu nem auszutestenden secondary DNS (bei jedem 10.ten Lookup))
0.4 Secondary DNS UDP
0.7 3rd DNS UDP
1.0 TCP DNS to Primary
2.0 UDP DNS to another DNS (4+)
3.0 TCP DNS to 2nd
4.0..9.0 UDP Request to all DNS in 0.5 Second Intervals
5.0 TCP DNS to 3rd
10.0 TCP DNS to primary
9.0..19 UDP Request to all DNs in 1.0 Second Intervals
20.0 TCp DNS to 2nd
20..50 UDP Request in 3 Second Intervals
30.0 TCP DNS to 3rd
40.0 TCP DNS to primary
60 Timeout
