Version vom 7. August 2008, 22:58 Uhr

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

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 Sekudnen weitere, danach wartet es noch 7 Sekunden auf etcaige Antworten, .. (d.h. ein 8 Sekündliches komplett funkloch (ode rein transienter olsr rooting loop) reicht völlig aus um nen Lookup in Windows zum scheintern 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))

Weiters ist Windows in der Lage selbst den Fakt das es KEINE Antwort bekommen hat in seinen eigenen Cache aufzunehmen,.. (Was extrem fragwürdig ist!!!)

Nützlich ist da kurzfristig mal ipconfig /flushdns (und /displaydns für neugierige)

und somit wird es nach einem erfolglosen Versuch für weitere 5 Minuten garkein weiteres Mal nen DNS Request für diese Domain senden, sondern sofort unresolveable zurückmelden,..

Mit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters MaxNegativeCacheTtl=0 kann man wenigsten einstellen wielang ein negatives Lookup Ergebnis gecached werden soll

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,.. die 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.: [1] 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