bind, edns et taille udp

Le
Raphael Bauduin
--047d7bd74cf811e7f904e18c362d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'utilise Exim comme serveur smtp, avec vérification DKIM.
Les mail venant de gmail sont rejetés parce que la résolution du =
record TXT
20120113._domainkey.gmail.com ne se fait pas.

Cela semble etre dû au fait que la taille de la réponse udp est t=
rop grande.
La réponse udp est en effet marquée comme tronquée.

Tentant la résolution avec dig, il veut passer en tcp:

~$ dig 20120113._domainkey.gmail.com txt
;; Truncated, retrying in TCP mode.

Avec dig, il est possible de lui dire d'accepter des taille plus
importantes, et dans ce ca la résolution a lieu:
~$ dig +bufsize=1024 20120113._domainkey.gmail.com txt
<reponse>

Le serveur dns a le edns désactivé:
server 0.0.0.0/0 {
edns no;
};

Le probleme n'est pas dû à un firewall, car les résultat son=
t identiques
quand ces commandes sont lancée sur le serveur dns lui-même. La r=
ésolution
par un serveur externe interrogé par dig depuis le serveur dns fonctio=
nne:
dig @8.8.8.8 20120113._domainkey.gmail.com txt
<reponse>


De plus, j'ai effectué le test indiqué à
https://www.dns-oarc.net/oarc/services/replysizetest
permettant de voir quelles tailles de réponses sont acceptées par=
le
serveur dns. Ces résultats sont:

dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"W.X.Y.Z sent EDNS buffer size 4096"
"W.X.Y.Z DNS reply size limit is at least 3843"

où W.X.Y.Z est l'ip publique du serveur dns local.



Cela m'amềne à poser plusieurs questions:
- il me semble que le probleme se situe entre les clients interne et le
serveur dns local. Correct?
- le serveur dns ne supporte pas edns, mais malgré tout, le test
dns-oarc.net parle d'une taille de buffer de 4096 communiquée OÃ=
¹ est
l'erreur?
- +bufsize de dig est aussi un parametre edns. Le serveur local
supporterait-il donc edns, malgré la directive ci-dessus?
- j'ai essayé d'activer edns, mais sans changement. Rate-je quelque ch=
ose
dans la configuration de bind?

Merci d'avance pour vos suggestions!

Raphaël

--047d7bd74cf811e7f904e18c362d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr">Bonjour,<br><br>J&#39;utilise Exim comme serveur smtp, ave=
c vérification DKIM.<br>Les mail venant de gmail sont rejetés par=
ce que la résolution du record TXT 20120113._<a href="http://domaink=
ey.gmail.com">domainkey.gmail.com</a> ne se fait pas.<br>
<br>Cela semble etre dû au fait que la taille de la réponse udp e=
st trop grande.<br>La réponse udp est en effet marquée comme tron=
quée.<br><br>Tentant la résolution avec dig, il veut passer en tc=
p:<br><br>  ~$ dig  20120113._<a href="http://domainkey.gmail.c=
om">domainkey.gmail.com</a> txt<br>
  ;; Truncated, retrying in TCP mode.<br><br>Avec dig, il est possible=
de lui dire d&#39;accepter des taille plus importantes, et dans ce ca la r=
ésolution a lieu:<br>  ~$ dig +bufsize=1024 20120113._<a href=
="http://domainkey.gmail.com">domainkey.gmail.com</a> txt<br>
     &lt;reponse&gt;<br><br>Le serveur dns a le edns d=
ésactivé:<br>  server <a href="http://0.0.0.0/0">0.0.0.0/0=
</a> {<br>         edns no;<br>  };<br><=
br>Le probleme n&#39;est pas dû à un firewall, car les résul=
tat sont identiques quand ces commandes sont lancée sur le serveur dns=
lui-même. La résolution par un serveur externe interrogé pa=
r dig depuis le serveur dns fonctionne:<br>
   dig @<a href="http://8.8.8.8">8.8.8.8</a> 20120113._<a href=
="http://domainkey.gmail.com">domainkey.gmail.com</a> txt<br>  =
   &lt;reponse&gt;<br><br><br>De plus, j&#39;ai effectué le =
test indiqué à <a href="https://www.dns-oarc.net/oarc/services/=
replysizetest">https://www.dns-oarc.net/oarc/services/replysizetest</a> <br=
>
permettant de voir quelles tailles de réponses sont acceptées par=
le serveur dns. Ces résultats sont:<br><br><pre><code>dig +short <a h=
ref="http://rs.dns-oarc.net">rs.dns-oarc.net</a> txt<br> <a href="ht=
tp://rst.x3827.rs.dns-oarc.net">rst.x3827.rs.dns-oarc.net</a>.<br>
<a href="http://rst.x3837.x3827.rs.dns-oarc.net">rst.x3837.x3827.rs.d=
ns-oarc.net</a>.<br> <a href="http://rst.x3843.x3837.x3827.rs.dns-oarc=
.net">rst.x3843.x3837.x3827.rs.dns-oarc.net</a>.<br> &quot;W.X.Y.Z sent =
EDNS buffer size 4096&quot; <br>
&quot;W.X.Y.Z DNS reply size limit is at least 3843&quot; </code></pre>=
où W.X.Y.Z est l&#39;ip publique du serveur dns local.<br><br><br><br>=
Cela m&#39;amềne à poser plusieurs questions:<br>- il me sembl=
e que le probleme se situe entre les clients interne et le serveur dns loca=
l. Correct?<br>
- le serveur dns ne supporte pas edns, mais malgré tout, le test <a hr=
ef="http://dns-oarc.net">dns-oarc.net</a> parle d&#39;une taille de buffe=
r de 4096 communiquée Où est l&#39;erreur?<br>- +bufsize de di=
g est aussi un parametre edns. Le serveur local supporterait-il donc edns, =
malgré la directive ci-dessus?<br>
- j&#39;ai essayé d&#39;activer edns, mais sans changement. Rate-je qu=
elque chose dans la configuration de bind?<br><br>Merci d&#39;avance pour v=
os suggestions!<br><br>Raphaël<br></div>

--047d7bd74cf811e7f904e18c362d--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAONrwUEhtaHDcKP8R=vW9_sS+cfJz0=0ufD8hhZ3ceDTyFKsoQ@mail.gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bzzz
Le #25544272
On Mon, 15 Jul 2013 14:43:45 +0200
Raphael Bauduin
Cela semble etre dû au fait que la taille de la réponse udp est
trop grande. La réponse udp est en effet marquée comme tronqu ée.




C'est le comportement normal pour la réponse d'une requête en UDP
dont la réponse dépasse 512 byte.

Où est l'erreur?



Les requêtes d'une taille de réponse ≥ 512 byte doivent- être
ré-émises en TCP.

http://tools.ietf.org/html/rfc5966
"... it is also clear that some new DNS record types defined in the
future will contain information exceeding the 512 byte limit that
applies to UDP, and hence will require TCP. Thus, resolvers and
name servers should implement TCP services as a backup to UDP
today, with the knowledge that they will require the TCP service
in the future."

et si la Cde dig fonctionne et indique 462 byte reçus, la taille
du packet est cependant de 960 byte.

en conséquence, il faut trouver une primitive d'exim qui force la
consultation DNS en TCP.

--
<Emel> En 1911, Dracula s'alimentait grâce au sang des jeunes filles v ierges.
Il est mort de faim en 2012.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Stephane Bortzmeyer
Le #25553822
On Mon, Jul 15, 2013 at 03:03:08PM +0200,
Bzzz a message of 44 lines which said:

C'est le comportement normal pour la réponse d'une requête en UDP
dont la réponse dépasse 512 byte.



Euh, cette limite de 512 octets a été abandonnée en 1999...

Les requêtes d'une taille de réponse ≥ 512 byte doivent-être
ré-émises en TCP.



Certainement pas.

en conséquence, il faut trouver une primitive d'exim qui force la
consultation DNS en TCP.



Pas d'accord.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Stephane Bortzmeyer
Le #25553832
On Mon, Jul 15, 2013 at 02:43:45PM +0200,
Raphael Bauduin a message of 136 lines which said:

Cela semble etre dû au fait que la taille de la réponse udp est trop
grande. La réponse udp est en effet marquée comme tronquée.



En 2013, ce genre de problèmes (limitation à 512 octets, supprimée il
y a quinze ans) devrait être du passé très lointain. Il est temps de
le résoudre.

Le serveur dns a le edns désactivé:



Très mauvaise idée.

- le serveur dns ne supporte pas edns, mais malgré tout, le test
dns-oarc.net parle d'une taille de buffer de 4096 communiquée... Où est
l'erreur?
- +bufsize de dig est aussi un parametre edns. Le serveur local
supporterait-il donc edns, malgré la directive ci-dessus?



Oui, c'est bizarre. Comme vous n'avez pas mis un résultat de dig
complet (notamment les trois dernières lignes), je me demande si vous
parlez bien à ce serveur. Vérifiez le /etc/resolv.conf. Globalement,
les tests indiqués sont incohérents donc il doit y avoir un loup
quelque part.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Stephane Bortzmeyer
Le #25553872
On Mon, Jul 15, 2013 at 02:43:45PM +0200,
Raphael Bauduin a message of 136 lines which said:

Tentant la résolution avec dig, il veut passer en tcp:

~$ dig 20120113._domainkey.gmail.com txt
;; Truncated, retrying in TCP mode.



Autrefois, dig ne faisait pas d'EDNS par défaut, contrairement à ce
que fait le résolveur de la GNU libc. Il me semble que ce comportement
de dig a changé récemment (difficile à dire quand car j'ai un
"+" dans mon ~/.digrc depuis longtemps, pour que son
comportement soit plus proche de celui du résolveur).

Sinon, la lecture de la doc d'Exim indique :

dns_use_edns0 Use: main Type: integer Default: -1
If this option is set to a non-negative number then Exim will initialise the DNS resolver library to either use or not use EDNS0 extensions, overriding the system default. A value of 0 coerces EDNS0 off, a value of 1 coerces EDNS0 on.

If the resolver library does not support EDNS0 then this option has no
effect.

Il faudrait donc essayer en le mettant à 1. Mauvaise idée de la part
d'Exim de ne pas le faire par défaut.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme