J'utilise Exim comme serveur smtp, avec v=C3=A9rification DKIM.
Les mail venant de gmail sont rejet=C3=A9s parce que la r=C3=A9solution du =
record TXT
20120113._domainkey.gmail.com ne se fait pas.
Cela semble etre d=C3=BB au fait que la taille de la r=C3=A9ponse udp est t=
rop grande.
La r=C3=A9ponse udp est en effet marqu=C3=A9e comme tronqu=C3=A9e.
Tentant la r=C3=A9solution 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=C3=A9solution a lieu:
~$ dig +bufsize=3D1024 20120113._domainkey.gmail.com txt
<reponse>
Le serveur dns a le edns d=C3=A9sactiv=C3=A9:
server 0.0.0.0/0 {
edns no;
};
Le probleme n'est pas d=C3=BB =C3=A0 un firewall, car les r=C3=A9sultat son=
t identiques
quand ces commandes sont lanc=C3=A9e sur le serveur dns lui-m=C3=AAme. La r=
=C3=A9solution
par un serveur externe interrog=C3=A9 par dig depuis le serveur dns fonctio=
nne:
dig @8.8.8.8 20120113._domainkey.gmail.com txt
<reponse>
De plus, j'ai effectu=C3=A9 le test indiqu=C3=A9 =C3=A0
https://www.dns-oarc.net/oarc/services/replysizetest
permettant de voir quelles tailles de r=C3=A9ponses sont accept=C3=A9es par=
le
serveur dns. Ces r=C3=A9sultats 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=C3=B9 W.X.Y.Z est l'ip publique du serveur dns local.
Cela m'am=E1=BB=81ne =C3=A0 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=C3=A9 tout, le test
dns-oarc.net parle d'une taille de buffer de 4096 communiqu=C3=A9e... O=C3=
=B9 est
l'erreur?
- +bufsize de dig est aussi un parametre edns. Le serveur local
supporterait-il donc edns, malgr=C3=A9 la directive ci-dessus?
- j'ai essay=C3=A9 d'activer edns, mais sans changement. Rate-je quelque ch=
ose
dans la configuration de bind?
<div dir=3D"ltr">Bonjour,<br><br>J'utilise Exim comme serveur smtp, ave=
c v=C3=A9rification DKIM.<br>Les mail venant de gmail sont rejet=C3=A9s par=
ce que la r=C3=A9solution du record TXT 20120113._<a href=3D"http://domaink=
ey.gmail.com">domainkey.gmail.com</a> ne se fait pas.<br>
<br>Cela semble etre d=C3=BB au fait que la taille de la r=C3=A9ponse udp e=
st trop grande.<br>La r=C3=A9ponse udp est en effet marqu=C3=A9e comme tron=
qu=C3=A9e.<br><br>Tentant la r=C3=A9solution avec dig, il veut passer en tc=
p:<br><br>=C2=A0 ~$ dig=C2=A0 20120113._<a href=3D"http://domainkey.gmail.c=
om">domainkey.gmail.com</a> txt<br>
=C2=A0 ;; Truncated, retrying in TCP mode.<br><br>Avec dig, il est possible=
de lui dire d'accepter des taille plus importantes, et dans ce ca la r=
=C3=A9solution a lieu:<br>=C2=A0 ~$ dig +bufsize=3D1024 20120113._<a href=
=3D"http://domainkey.gmail.com">domainkey.gmail.com</a> txt<br>
=C2=A0=C2=A0=C2=A0=C2=A0 <reponse><br><br>Le serveur dns a le edns d=
=C3=A9sactiv=C3=A9:<br>=C2=A0 server <a href=3D"http://0.0.0.0/0">0.0.0.0/0=
</a> {<br>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 edns no;<br>=C2=A0 };<br><=
br>Le probleme n'est pas d=C3=BB =C3=A0 un firewall, car les r=C3=A9sul=
tat sont identiques quand ces commandes sont lanc=C3=A9e sur le serveur dns=
lui-m=C3=AAme. La r=C3=A9solution par un serveur externe interrog=C3=A9 pa=
r dig depuis le serveur dns fonctionne:<br>
=C2=A0=C2=A0 dig @<a href=3D"http://8.8.8.8">8.8.8.8</a> 20120113._<a href=
=3D"http://domainkey.gmail.com">domainkey.gmail.com</a> txt<br>=C2=A0=C2=A0=
=C2=A0=C2=A0 <reponse><br><br><br>De plus, j'ai effectu=C3=A9 le =
test indiqu=C3=A9 =C3=A0 <a href=3D"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=C3=A9ponses sont accept=C3=A9es par=
le serveur dns. Ces r=C3=A9sultats sont:<br><br><pre><code>dig +short <a h=
ref=3D"http://rs.dns-oarc.net">rs.dns-oarc.net</a> txt<br> <a href=3D"ht=
tp://rst.x3827.rs.dns-oarc.net">rst.x3827.rs.dns-oarc.net</a>.<br>
<a href=3D"http://rst.x3837.x3827.rs.dns-oarc.net">rst.x3837.x3827.rs.d=
ns-oarc.net</a>.<br> <a href=3D"http://rst.x3843.x3837.x3827.rs.dns-oarc=
.net">rst.x3843.x3837.x3827.rs.dns-oarc.net</a>.<br> "W.X.Y.Z sent =
EDNS buffer size 4096" <br>
"W.X.Y.Z DNS reply size limit is at least 3843" </code></pre>=
o=C3=B9 W.X.Y.Z est l'ip publique du serveur dns local.<br><br><br><br>=
Cela m'am=E1=BB=81ne =C3=A0 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=C3=A9 tout, le test <a hr=
ef=3D"http://dns-oarc.net">dns-oarc.net</a> parle d'une taille de buffe=
r de 4096 communiqu=C3=A9e... O=C3=B9 est l'erreur?<br>- +bufsize de di=
g est aussi un parametre edns. Le serveur local supporterait-il donc edns, =
malgr=C3=A9 la directive ci-dessus?<br>
- j'ai essay=C3=A9 d'activer edns, mais sans changement. Rate-je qu=
elque chose dans la configuration de bind?<br><br>Merci d'avance pour v=
os suggestions!<br><br>Rapha=C3=ABl<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
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.
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.
--
<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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20130715150308.254cbff5@anubis.defcon1
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.
-- <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
On Mon, Jul 15, 2013 at 03:03:08PM +0200, Bzzz wrote 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/
On Mon, Jul 15, 2013 at 03:03:08PM +0200,
Bzzz <lazyvirus@gmx.com> wrote
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20130719211153.GB23631@sources.org
On Mon, Jul 15, 2013 at 03:03:08PM +0200, Bzzz wrote 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
On Mon, Jul 15, 2013 at 02:43:45PM +0200, Raphael Bauduin wrote 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/
On Mon, Jul 15, 2013 at 02:43:45PM +0200,
Raphael Bauduin <rblists@gmail.com> wrote
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20130719211003.GA23631@sources.org
On Mon, Jul 15, 2013 at 02:43:45PM +0200, Raphael Bauduin wrote 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
On Mon, Jul 15, 2013 at 02:43:45PM +0200, Raphael Bauduin wrote 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/
On Mon, Jul 15, 2013 at 02:43:45PM +0200,
Raphael Bauduin <rblists@gmail.com> wrote
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
"+bufsize@96" 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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20130719213041.GA9107@sources.org
On Mon, Jul 15, 2013 at 02:43:45PM +0200, Raphael Bauduin wrote 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/
