reducing the advertised EDNS UDP packet size to 512 octets
Peter Mairhofer
Seit dem Umstieg auf Debian lenny ist mein syslog ist voll von Einträgen
wie:
named[314]: too many timeouts resolving
'88.247.99.62.blackholes.mail-abuse.org/A' (in
'blackholes.mail-abuse.org'?): disabling EDNS
named[314]: too many timeouts resolving '170.102.83.93.bl.spamcop.net/A'
(in 'bl.spamcop.net'?): reducing
the advertised EDNS UDP packet size to 512 octets
oder auch
named[314]: network unreachable resolving 'cn99.com/MX/IN':
2001:503:a83e::2:30#53
Ich hab an meiner Konfiguration nichts verändert. Ich habe bereits im
Internet gesucht aber keine Lösung gefunden. Am besten waren noch die
Threads die mitten bei der Lösung aufgehört haben mit "Deine Firewall
ist schuld" wie [1].
Woran liegt das Problem jetzt nun? Ich nehme an dass die neue Version
EDNS verwendet (UDP Size > 512) und manche Firewalls nur 512 Byte Pakete
durchlassen [2]. Demzufolge sind alle Router bei denen das geschieht kaputt.
Nur: Als Router verwende ich (abgesehen von der Blackbox der Telekom)
einen WRT54GL mit OpenWRT. Dass dieser das Problem hat kann ich mir ja
nicht vorstellen.
Was ist die beste Lösung? Welches Problem beheben? EDNS abschalten? Wie?
Meldungen einfach ignorieren? Nicht sehr elegant, m.E..
lg,
Peter
[1]
http://groups.google.at/group/linux.debian.user.german/browse_thread/thread/3585e2c411e52269/ed153cc402191143?hl=de&ie=UTF-8&q=%22reducing+the+advertised+EDNS+UDP+packet+size+to+512+octets%22#ed153cc402191143
[2] http://de.wikipedia.org/wiki/EDNS
Holger Marzen
> Hi,
>
> Seit dem Umstieg auf Debian lenny ist mein syslog ist voll von Einträgen
> wie:
>
> named[314]: too many timeouts resolving
> '88.247.99.62.blackholes.mail-abuse.org/A' (in
> 'blackholes.mail-abuse.org'?): disabling EDNS
>
> named[314]: too many timeouts resolving '170.102.83.93.bl.spamcop.net/A'
> (in 'bl.spamcop.net'?): reducing
> the advertised EDNS UDP packet size to 512 octets
>
> oder auch
>
> named[314]: network unreachable resolving 'cn99.com/MX/IN':
> 2001:503:a83e::2:30#53
>
> Ich hab an meiner Konfiguration nichts verändert. Ich habe bereits im
> Internet gesucht aber keine Lösung gefunden. Am besten waren noch die
> Threads die mitten bei der Lösung aufgehört haben mit "Deine Firewall
> ist schuld" wie [1].
Auch schon erlebt. Die Superschlau-Funktion von älteren Checkpoints ist
zu dämlich für EDNS.
Florian Weimer
> Woran liegt das Problem jetzt nun? Ich nehme an dass die neue Version
> EDNS verwendet (UDP Size > 512) und manche Firewalls nur 512 Byte
> Pakete durchlassen [2]. Demzufolge sind alle Router bei denen das
> geschieht kaputt.
Nein, die neue Version hat bloß zusätzliche Logik eingebaut. Früher
wurde einfach EDNS komplett abgeschaltet (womit dann auch DNSSEC nicht
tat). Jetzt wird erst EDNS mit kleinen Paketen ausprobiert und
schließlich EDNS abgeschaltet -- und es gibt eine neue Log-Nachricht.
Andreas M. Kirchwitz
> Woran liegt das Problem jetzt nun? Ich nehme an dass die neue Version
> EDNS verwendet (UDP Size > 512) und manche Firewalls nur 512 Byte Pakete
> durchlassen [2]. Demzufolge sind alle Router bei denen das geschieht kaputt.
Die Ursache des Problem muss ja nicht notwendigerweise auf Deiner
Seite liegen, oder?
> Was ist die beste Lösung? Welches Problem beheben? EDNS abschalten? Wie?
> Meldungen einfach ignorieren? Nicht sehr elegant, m.E..
Die mehrheitliche Meinung laut Google-Suche scheint zu sein, bei sich
selbst dafür so sorgen, dass man nicht Ursache des Problems ist, und
mit "logging { category edns-disabled { null; }; };" für Ruhe zu sorgen.
Den Rest erledigt BIND/named für einen, so gut es geht.
Sollte das eine schlechte Taktik sein, schließe ich mich Deiner Frage
nach eine besseren Lösung an. ;-)
Grüße, Andreas
Peter Mairhofer
Ok. Aber jetzt krieg ich ständig logcheck-Mails die mir meinen
Posteingang zumüllen. Natürlich könnte ich einfach eine passende rule
erstellen, aber ich möchte das Problem - sofern es eins ist - beheben.
Also die empfohlene Lösung scheint zu sein mit bind das logging dazu
abzudrehen oder?
Wie kann ich sonst einfach testen ob das Problem an mir bzw. dem Router
liegt?
Zweitens: Ich sehe gerade dass ich meinen bind so konfiguriert habe dass
er die Anfragen an den DNS Server meines Providers weiterreicht...also
forwarders { ... }; Dementsprechend müssten doch alle Anfragen dorthin
oder? Wieso bekomme ich dann die Meldungen?
Und zu:
named[314]: network unreachable resolving 'cn99.com/MX/IN':
2001:503:a83e::2:30#53
Das hat glaub ich mit EDNS nix zu tun oder? Unabhängig davon, wieso will
der überhaupt dorthin verbinden wenn ich doch über forwarders {...};
über die DNS Server meines Providers gehe?
lg
Peter
Florian Weimer
> Wie kann ich sonst einfach testen ob das Problem an mir bzw. dem
> Router liegt?
"dig @a.ns.se se. DNSKEY +dnssec +norecurse" ausführen. Wenn das tut,
sollte Dein Ende in Ordnung sein, zumindest in erster Näherung.
> Und zu:
>
> named[314]: network unreachable resolving 'cn99.com/MX/IN':
> 2001:503:a83e::2:30#53
>
> Das hat glaub ich mit EDNS nix zu tun oder?
Richtig.
> Unabhängig davon, wieso
> will der überhaupt dorthin verbinden wenn ich doch über forwarders
> {...}; über die DNS Server meines Providers gehe?
Es gibt forward-first und forward-only. Eventuell ist das falsch
eingestellt?
Wenn Du kein IPv6 hast, solltest Du BIND auch mit "-4" starten.
Peter Mairhofer
> * Peter Mairhofer:
>> Unabhängig davon, wieso
>> will der überhaupt dorthin verbinden wenn ich doch über forwarders
>> {...}; über die DNS Server meines Providers gehe?
>
> Es gibt forward-first und forward-only. Eventuell ist das falsch
> eingestellt?
Es ist gar nichts eingestellt. Weisst du zufällig was von den beiden
Standard ist?
Und - ich rate mal:
forward-first: Leite zuerst an den Provider und mach dann selbst ein lookup
forward-only: Leite nur an Provider
> Wenn Du kein IPv6 hast, solltest Du BIND auch mit "-4" starten.
Hab ich schon, will ich für DNS wegen der Geschwindigkeit aber nicht
verwenden. Mit "-4" hab ich bereits gestartet, danke.
lg
Peter
Florian Weimer
>> Es gibt forward-first und forward-only. Eventuell ist das falsch
>> eingestellt?
>
> Es ist gar nichts eingestellt. Weisst du zufällig was von den beiden
> Standard ist?
| This option is only meaningful if the forwarders list is not
| empty. A value of first, the default, causes the server to query the
| forwarders first — and if that doesn't answer the question, the
| server will then look for the answer itself. If only is specified,
| the server will only query the forwarders.
Standard ist also "first", und es ist so, wie Du es beschrieben hast.
Peter Mairhofer
Hallo!
Ich hab jetzt mal versucht:
$ dig @a.ns.se se. DNSKEY +dnssec +norecurse
[...]
Scheint alles i.O. zu sein (viele Answers und NOERROR).
Aber ich habe auch das versucht was du oben geschrieben hast. In meiner
named.conf steht nun:
forward only;
forwarders {
// TA KMU Servers
213.33.99.70;
80.120.17.70;
};
Wenn ich das richtig verstanden habe, dürften jetzt DNS Anfragen never
ever mehr ausgeführt werden *ohne* über diese Server zu gehen. Die
verdammten blöden Meldungen kommen aber immer noch :-(
named[14342]: too many timeouts resolving 'savannahjohnson.com/MX' (in
'.'?): reducing the advertised EDNS UDP packet size to 512 octets
Wenn ichs richtig verstanden habe kann ich so prüfen ob die DNS Server
meines Providers EDNS unterstützen:
dig @213.33.99.70 se. DNSKEY +dnssec
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.5.1-P1 <<>> @213.33.99.70 se. DNSKEY +dnssec
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18716
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
[...]
Was hier schon auffällt: Malformed packets, retrying in TCP mode. Kann
es also sein dass überhaupt der DNS Server meines Providers gar kein
EDNS kann? Wäre wirklich äusserst mies für den Businness Zugang des
größten Providers...
Aber auf der anderen Seite versuche ich jetzt die Seite von oben wo der
Fehler auftrat manuell über meinen Provider aufzulösen. Wenn ich dig
dig-manpage richtig interpretiere, schalte ich mit "bufsize=B" EDNS ein
mit "advertised buffer size":
$ dig @213.33.99.70 savannahjohnson.com. -t MX +bufsize=16000
; <<>> DiG 9.5.1-P1 <<>> @213.33.99.70 savannahjohnson.com. -t MX
+bufsize=16000
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63294
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
[...]
Tja, es geht einfach! Die Query, die laut meinem Syslog nicht
funktioniert hat geht auf einmal manuell? Ausserdem widerspricht sich
das ja irgendwie mit dem Nicht-Funktionieren der DNSSEC Query oder?
lg
Peter
Florian Weimer
> Tja, es geht einfach! Die Query, die laut meinem Syslog nicht
> funktioniert hat geht auf einmal manuell?
Es könnte ein Loadbalancer vor dem Resolver sein (und einer der Knoten
verhält sich falsch). Oder das Verhalten hängt davon ab, ob die
Anfrage aus dem Cache beantwortet wird oder nicht.
Was TA da für Software einsetzt, entzieht sich meiner Kenntnis. Es ist
jedenfalls reichlich kaputt. Ich würde auf keinen Fall dahinter einen
Forwarder betreiben.