[email protected] wrote:
Fantec a été faire un tour dans le code de Qmail, et notre ami Bernstein
fait bien une requete MX pas ANY... La vérité est ailleurs.
int dns_cname(sa)
...
switch(resolve(sa,T_ANY))
Si j'ai bien compris le code, il fait une requete ANY pour voir s'il n'y
aurai pas un CNAME histoire de remplacer le domaine avant de faire sa
requete MX. Malheureusement, dans son code, il "oublie" l'information
que la réponse était tronquée et renvoie une erreur lorsqu'un
enregistrement est "erroné" (du fait de la troncature). Du coup, il y a
trois choses qui me genent : pourquoi oublier que l'enregistrement est
tronqué alors qu'il y a une valeur recherchée dans la liste qui _est_
incomplete ? Pourquoi faire une recherche T_ANY pour récuperer un seul
CNAME (là, je manque d'historique sur les requetes DNS) ? Et pourquoi
commencer par un CNAME au lieu d'un MX ? (j'aurais tendance à penser que
la plupart des domaines ont différentes entrées et qu'il leur faille
donc un MX alors que le CNAME empeche toute autre entrée dans les DNS)
Pour ce qui est des points :
----
Le problème est dû à la taille de la repose DNS de la zone "neuf.fr".
La réponse dépasse 512 bytes (583 bytes) et donc elle ne se fait pas
en UDP. Elle se fait en TCP. Or QMAIL, en respectant les RFC, ne gère
pas les requêtes DNS en TCP. Et donc il ne trouve pas les serveurs MX
de @neuf.
----
Non, les réponses peuvent se faire sur 512 octets en tronquant les
données. Là, cela devrait être clairement indésiré car il s'agit de
récuperer une entrée dans une liste. Rien n'oblige Qmail à implementer
les requetes TCP mais ce n'est pas pour autant que les entrées ne
doivent pas dépasser les 512 octets. Là, Qmail se tire dans le pied et
cela fait déjà quelques années que cela a été signalé. Sinon et depuis
presque 10 ans déjà, les requetes en UDP peuvent dépasser les 512 octets
(RFC 2671), il y a même un patch à qmail qui l'exploite...
----
D'après les auteurs de Qmail, une zone > à 512 ne respectent pas les
RFC et donc il n'y a pas de patchs ni de correctifs à appliquer sur le
Qmail puisque Qmail respectent les RFC.
----
Ben non. Sinon, la RFC 1035 n'aurait pas prévu le flag TC pour signaler
précisement que la réponse était tronquée.
----
Nous allons publier un patch pour QMAIL afin que nos clients puissent
résoudre ce problème
----
Il en existe déjà qui utilisent EDNS0 :
http://www.ckdhr.com/ckd/qmail-103.patch
----
Mais sachant qu'on a presque 50'000 serveurs dédiés
chez Ovh et QMAIL est installé sur plusieurs millions de serveurs dans
le monde, le plus simple serait de corriger la zone "neuf.fr" afin de
réduire la taille de la réponse et résoudre ce problème rapidement
et avec minimum de travail.
----
Et donc faire bosser un tiers pour contourner un bug dont il n'est pas
responsable.
François
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
