PowerDNS - Antworten sortieren

[Lord Gurke]

Hallo zusammen,

ich benutze PowerDNS mit MySQL-Backend für die DNS-Zonen meiner Domains. Die DNS-Antworten werden bei fast jeder Anfrage neu zusammengewürfelt ausgegeben, also z.B.:

;; ANSWER SECTION:
meinedomain.tld.         597     IN      MX      300 mx2.mailserver.tld.
meinedomain.tld.         597     IN      MX      100 mx0.mailserver.tld.
meinedomain.tld.         597     IN      MX      200 mx1.mailserver.tld.

Vom Prinzip her wäre mir das heiter bis wolkig - es gibt aber Softwareprodukte eines bekannten Redmonder Software-Herstellers denen offenbar die MX-Prioritäten ebenso egal sind und sich bei exakt dieser Ausgabe reproduzierbar falsch verhalten:
Denn offenbar werden die Mailserver in der Reihenfolge kontaktiert, in der sie vom DNS-Server zurückgeliefert werden und nicht nach der angegebenen Priorität. Das ist insofern doof, als dass mx2 auf eine IP verweist, hinter der kein Mailserver wartet und demzufolge Mails teilweise mehrere Stunden verspätet ankommen.

Laut der PowerDNS-Doku kann man die SQL-Befehle anpassen, also tat ich dies und hing ein "ORDER BY priority ASC" hinten dran. PowerDNS fragt auch laut Logfile mit meinem geänderten SQL-String ab, die Antwort ist aber dennoch so unsortiert wie vorher - kopiere ich den SQL-String in eine MySQL-Konsole bekomme ich exakt die Ausgabe, die ich erwartet habe.


Gibt es irgendeinen Trick, PowerDNS dazu zu bringen die Antworten mit irgendeiner Form von Sortierung zu schicken? Rechenleistung ist zumindest momentan noch relativ egal, da momentan auf den DNS-Servern (drei Stück) eh nur um die 100 Anfragen in der Minute aufschlagen.
Bis auf dieses "Problem" bin ich mit dem PDNS super-zufrieden und ich würde nur ungerne deshalb alles umbauen.

Viele Grüße aus dem Tal
Max

 

[Whistler]

Falls Du nicht wirklich 597 als TTL benutzt, siehst Du nicht die Ausgabe Deines authoritativen Nameservers, sondern die eines zwischengeschalteten cachenden Recursors, dessen TTL langsam abläuft.
Der kann dann bezüglich Reihenfolge ganz anders eingestellt sein (z.B. Round-Robin), ohne daß Du etwas dagegen tun kannst.
MX-Prioritäten gibt es ja gerade, weil die Reihenfolge der Antworten nicht garantiert werden kann.

Welches Ergebnis bringt denn dig meinedomain.tld mx @ns.meinedomain.tld?

 

[Lord Gurke]

Stimmt, die Ausgabe war irreführend
Bis auf die TTL stimmt sie aber mit dem überein was ich bekomme, wenn ich den Server direkt anfrage - nur dass alle paar Sekunden die Einträge anders sortiert werden.

 

[Joe User]

Die Ursache für Dein "Problem" liegt definitiv nicht in Redmond, sondern vor Deiner Tastatur. Im RFC heisst es, dass die MXe nach Priorität gewählt werden sollten, nicht müssen. Zudem kann weder Microsoft noch irgendein Postmaster etwas dafür, dass Du Deinen zweiten MX vom Netz nimmst und die DNS-Records nicht aktualisierst.

Sorry, aber unbegründet Richtung Microsoft zu schiessen, ist absolut unangemessen.

 

[Lord Gurke]

Die Ursache für Dein "Problem" liegt definitiv nicht in Redmond, sondern vor Deiner Tastatur. Im RFC heisst es, dass die MXe nach Priorität gewählt werden sollten, nicht müssen.

Keine Ahnung, wie mein Kugelschreiber in diese Sache involviert ist...
Im Ernst: Wieso keifst du mich direkt so an, weil ich mit einem halben Satz erwähnt habe, dass ich das Verhalten des Microsoft SMTP-Dienstes nicht in vollem Umfang toll finde?
Ein Request For Comment stellt keinen Standard dar an den sich alle halten müssen. Aus irgendwelchen Gründen tut es aber fast jeder. Deshalb, und weil das Prioritätenfeld im Zonefile ja irgendeinen Sinn haben muss, habe ich mich zum Gedanken hinreißen lassen, dass es sich um einen Quasi-Standard handelt, den jeder halbwegs gleich unterstützt.
Aber weil dies offenbar eben nicht der Fall ist, will ich die DNS-Antworten korrekt vorsortieren um garnicht in Kalamitäten zu geraten

Zudem kann weder Microsoft noch irgendein Postmaster etwas dafür, dass Du Deinen zweiten MX vom Netz nimmst und die DNS-Records nicht aktualisierst.

Ich habe nie einen dritten MX gehabt (und ergo keinen vom Netz genommen) - es ist aber eine unwahrscheinlich wirkungsvolle Methode Spam fernzuhalten. Spammer bevorzugen den MX-Record mit der niedrigsten Priorität und haben i.d.R. keine Failover-Mechanismen. Das heißt: Ich locke die Spambots auf eine IP, an die kein Mailserver gebunden ist und sie lassen dafür die echten Systeme in Ruhe.
Siehe hier: http://wiki.apache.org/spamassassin/OtherTricks

 

[d4f]

Das heißt: Ich locke die Spambots auf eine IP, an die kein Mailserver gebunden ist und sie lassen dafür die echten Systeme in Ruhe.

Ist mit dem (teilweisen) Ausschließen von M$-Produkten nicht das Ziel erreicht?
(sry... could not resist)

Der Trick ist recht alt wenngleich noch halbwegs wirkungsvoll. Da du nicht garantieren kannst dass die Clients auch deiner Logik folgen solltest du diesen "MX-Trap" aus dem Repertoire nehmen.

Ein Request For Comment stellt keinen Standard dar [...] dass es sich um einen Quasi-Standard handelt, den jeder halbwegs gleich unterstützt.

Ohne jetzt den RFC gelesen zu haben behaupte ich mal dass Joe's "Im RFC heißt es, dass die MXe nach Priorität gewählt werden sollten, nicht müssen" die kleine aber feine Differenz zwischen SHOULD und MUST in der Beschreibung ist. Hier ist nach zu lesen wie diese Woerter zu interpretieren sind:
RFC 2119
Die Wahl von SHOULD hat einen Sinn, so waere zB denkbar dass ein sendender Server selbstständig die Last auf dem Zielserver verteilt wenn mehrere MX zur Verfügung stehen - und auch wenn diese verschiedene MX-Priorities haben.

 

[Joe User]

Ein Request For Comment stellt keinen Standard dar an den sich alle halten müssen. Aus irgendwelchen Gründen tut es aber fast jeder.

Könnte eventuell daran liegen: http://en.wikipedia.org/wiki/Internet_standard

Deshalb, und weil das Prioritätenfeld im Zonefile ja irgendeinen Sinn haben muss, habe ich mich zum Gedanken hinreißen lassen, dass es sich um einen Quasi-Standard handelt, den jeder halbwegs gleich unterstützt.

Es ist so gar ein offizieller Internet-Standard und Microsofts Implementierung ist vollkommen standardkonform.

Ich habe nie einen dritten MX gehabt (und ergo keinen vom Netz genommen) - es ist aber eine unwahrscheinlich wirkungsvolle Methode Spam fernzuhalten. Spammer bevorzugen den MX-Record mit der niedrigsten Priorität und haben i.d.R. keine Failover-Mechanismen. Das heißt: Ich locke die Spambots auf eine IP, an die kein Mailserver gebunden ist und sie lassen dafür die echten Systeme in Ruhe.
Siehe hier: http://wiki.apache.org/spamassassin/OtherTricks

Snake Oil.

 

[Lord Gurke]

Es ist so gar ein offizieller Internet-Standard und Microsofts Implementierung ist vollkommen standardkonform.

Es ist nicht schwer, sich an Standards zu halten, die abhängig von Wetterlage, Mondphase und Rübenernte ausgelegt werden können
http://en.wikipedia.org/wiki/MX_record#The_preference_debate

Egal - nach der Empfehlung von d4f nehme ich den "bösen" Eintrag erstmal raus und begucke die Reject- und Spam-Statistiken.

Nichtsdestotrotz würde ich liebend gerne nochmal zaghaft auf den Ausgangspunkt des Threads zurückkommen, bevor wir in wildes RFC-Bashing verfallen waren

 

[Joe User]

Da Du (abgesehen vom LAN) keinerlei Einfluss darauf hast von welchem Nameserver der Client die Records holt, ist es auch vollkommen Wurscht in welcher Reihenfolge Dein Nameserver die Records ausspuckt.

Unabhängig davon und damit Du endlich die passende Antwort bekommst: Du wirst den Source entsprechend patchen müssen.