Opened by mixxer at 2017-05-17 01:16
User since
2016-04-01
25 Artikel
BenutzerIn
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2016-04-01
25 Artikel
BenutzerIn
Bisherige Erkenntnisse:
1) Die verwendete Liste der zu prüfenden DNS-Server ist augenscheinlich ungeeingnet. Schnelle Server produzieren zu viele FAILS oder sporadisch lange Antwortzeiten. Langsame Server mit relativ hoher Availibility sind viel zu langsam ( hier orientiere ich mich am 8.8.8.8 als Vergleich ).
2) Wirklich praxistauglich ist das Abfragen von rigendwelchen hochfrequentierten Ddomains auch nicht.
3) Die Auswahl des "richtigen" DNS-Servers muss wirklich auch auf meine im Netzwerk benötigten Anfragen abgestimmt sein.
Wirklich aufmerksam machte mich heute folgendes log des lokalen dnsmasq cache-name-servers:
Ich habe zur Zeit vier Forwarder eingesetzt; zwei experimentell und zwei als "Sicherheit".
In regelmäßigen Abständen checkt dnsmasqu offensichtlich die Availibility und priorisiert seine Forwards nach einer internen Tabelle. Da muss ich mich also garnicht drumm kümmern ;)
173.245.58.124 ist an meinem Standort per dig schneller als 74.82.42.42. Insofern ist es auch nicht möglich, einfach mal so einen anderen meiner Meinung nach "besseren" Nameserver als Nr.1 zu priorisieren...
Was mich insgesamt an einen anderen Ansatz denken lässt:
a) Ich lasse dnsmasq die Auswahl selber erledigen.
b) dnsmasq wird aus drei Pools gefüttert:
c) Minütlich wird die Erreichbarkeit von Pool 3 geprüft.
d) Erkennen von Situationen in denen in den "Notbetrieb" umgestellt wird: Availibility vor Schnelligkeit.
e) In längeren Perioden werden neue DNS-Server im Betrieb getestet und entweder gekickt oder in Pool 3 eingeordnet.
... Soweit zur Theorie - muss mal in den Keller zum basteln
1) Die verwendete Liste der zu prüfenden DNS-Server ist augenscheinlich ungeeingnet. Schnelle Server produzieren zu viele FAILS oder sporadisch lange Antwortzeiten. Langsame Server mit relativ hoher Availibility sind viel zu langsam ( hier orientiere ich mich am 8.8.8.8 als Vergleich ).
2) Wirklich praxistauglich ist das Abfragen von rigendwelchen hochfrequentierten Ddomains auch nicht.
3) Die Auswahl des "richtigen" DNS-Servers muss wirklich auch auf meine im Netzwerk benötigten Anfragen abgestimmt sein.
Wirklich aufmerksam machte mich heute folgendes log des lokalen dnsmasq cache-name-servers:
Code: (dl
)
1
2
3
4
5
6
7
Jun 3 13:44:59 raspberrypi dnsmasq[5709]: cache size 150, 1081/7379 cache insertions re-used unexpired cache entries.
Jun 3 13:44:59 raspberrypi dnsmasq[5709]: queries forwarded 3069, queries answered locally 872
Jun 3 13:44:59 raspberrypi dnsmasq[5709]: queries for authoritative zones 0
Jun 3 13:44:59 raspberrypi dnsmasq[5709]: server 173.245.58.124#53: queries sent 930, retried or failed 8
Jun 3 13:44:59 raspberrypi dnsmasq[5709]: server 74.82.42.42#53: queries sent 3043, retried or failed 0
Jun 3 13:44:59 raspberrypi dnsmasq[5709]: server 8.8.8.8#53: queries sent 920, retried or failed 0
Jun 3 13:44:59 raspberrypi dnsmasq[5709]: server 8.8.4.4#53: queries sent 935, retried or failed 0
Ich habe zur Zeit vier Forwarder eingesetzt; zwei experimentell und zwei als "Sicherheit".
In regelmäßigen Abständen checkt dnsmasqu offensichtlich die Availibility und priorisiert seine Forwards nach einer internen Tabelle. Da muss ich mich also garnicht drumm kümmern ;)
173.245.58.124 ist an meinem Standort per dig schneller als 74.82.42.42. Insofern ist es auch nicht möglich, einfach mal so einen anderen meiner Meinung nach "besseren" Nameserver als Nr.1 zu priorisieren...
Was mich insgesamt an einen anderen Ansatz denken lässt:
a) Ich lasse dnsmasq die Auswahl selber erledigen.
b) dnsmasq wird aus drei Pools gefüttert:
- 1.Pool -> DNS-Server mit hoher Availibility als "Backup"
- 2.Pool -> DNS-Server die getestet werden
- 3.Pool -> DNS-Server, die aktuell die "besten" sind
c) Minütlich wird die Erreichbarkeit von Pool 3 geprüft.
d) Erkennen von Situationen in denen in den "Notbetrieb" umgestellt wird: Availibility vor Schnelligkeit.
e) In längeren Perioden werden neue DNS-Server im Betrieb getestet und entweder gekickt oder in Pool 3 eingeordnet.
... Soweit zur Theorie - muss mal in den Keller zum basteln