Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Qmail: users

netqmail-1.06 and DNS patch

 

 

Qmail users RSS feed   Index | Next | Previous | View Threaded


vahid.moghaddasi at gmail

Oct 23, 2008, 8:23 AM

Post #1 of 16 (7155 views)
Permalink
netqmail-1.06 and DNS patch

Hi all,
After so many years of faithful delivery, we have just noticed that
all the mails to *.ibm.com fails with
CNAME_lookup_failed_temporarily._(#4.4.3)/ and after queuelifetime it
bounces back to user.

I upgraded a few servers from netqmail-1.05 to 1.06 which I assume has
the DNS patch already in it but I still see the following errors.

2008-10-23 10:51:33.529146500 starting delivery 41344: msg 39032 to
remote someuser [at] us
2008-10-23 10:51:53.540680500 delivery 41344: deferral:
CNAME_lookup_failed_temporarily._(#4.4.3)/
.....
2008-10-23 10:51:58.549636500 starting delivery 41345: msg 38922 to
remote someuser [at] in
2008-10-23 10:52:18.561078500 delivery 41345: deferral:
CNAME_lookup_failed_temporarily._(#4.4.3)/

Do I need to apply the patches (DNS and other) or it is already
applied with 1.06?

Thank you,


qmail-07 at jeremykister

Oct 23, 2008, 8:46 AM

Post #2 of 16 (6927 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

On 10/23/2008 11:23 AM, Vahid Moghaddasi wrote:
> Do I need to apply the patches (DNS and other) or it is already
> applied with 1.06?

you'll still need to apply the oversize dns patch.

using dnscache as your resolver will greatly reduce the chances that you
would need to install the dns patch, but it's still necessary.

--

Jeremy Kister
http://jeremy.kister.net./


vahid.moghaddasi at gmail

Oct 23, 2008, 9:15 AM

Post #3 of 16 (6932 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

On Thu, Oct 23, 2008 at 11:46 AM, Jeremy Kister
<qmail-07 [at] jeremykister> wrote:
>
> you'll still need to apply the oversize dns patch.
>
> using dnscache as your resolver will greatly reduce the chances that you
> would need to install the dns patch, but it's still necessary.
>
Thanks for your response. I always use dnscache on all of our qmail
servers but still see this problem.
I was under the impression that the oversize dns patch is already
included in netqmail-1.06.

Is this the dns patch: http://www.ckdhr.com/ckd/qmail-103.patch
Thanks,



--
This e-mail address is not monitored so please do not send me anything
important here. Thanks.


kyle-qmail at memoryhole

Oct 23, 2008, 9:34 AM

Post #4 of 16 (6942 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday, October 23 at 11:23 AM, quoth Vahid Moghaddasi:
> After so many years of faithful delivery, we have just noticed that
> all the mails to *.ibm.com fails with
> CNAME_lookup_failed_temporarily._(#4.4.3)/ and after queuelifetime it
> bounces back to user.

It would appear that IBM is violating the DNS spec, and sending
responses that are 716 bytes long.

> I upgraded a few servers from netqmail-1.05 to 1.06 which I assume
> has the DNS patch already in it

Why would you assume that?

Netqmail's website describes its patches as "the barest minimum number
of changes", fixing "only those things which are out-and-out wrong".
This DNS issue is NOT something that is out-and-out wrong on qmail's
part. On the contrary, IBM is wrong. The DNS standard (RFC 1035,
section 4.2.1) specifies that the maximum legal DNS response size is
512 bytes:

Messages carried by UDP are restricted to 512 bytes (not counting
the IP or UDP headers). Longer messages are truncated and the TC
bit is set in the header.

Qmail is obeying the DNS standard, and truncating messages that are
longer than 512 bytes. If people obey the DNS standard, qmail works
just fine. It is only when people violate that standard that qmail
stops being able to resolve their host names.

Thinking reasonably, any requirement that we impose in the DNS spec
will eventually be violated by someone. You could argue that qmail
should be able to handle any DNS response that can fit into a single
UDP packet (which has a maximum payload of 65,527 bytes). But what if
the server sends response packets in the wrong format? Why should the
internal format of the response specified by the DNS protocol be
treated as any more sacred than the "only 512 bytes" requirement? They
are equally arbitrary. At some point you have to say "no, that is
wrong, if you send invalid DNS packets, I won't understand them." As a
matter of policy, there is a balancing act to be done here: do you
change your software to attempt to compensate for protocol violations
(thereby encouraging a de-facto rewriting of the DNS spec), or do you
obey the DNS protocol? How much of a protocol violation should your
server be willing to tolerate? The netqmail folks (and I consider
myself as one of them) have chosen to balance this question by
strongly encouraging people to abide by the specifications of the
protocols. There's nothing stopping you from using the DNS patch, of
course. But fundamentally, IBM is sending invalid responses, and they
need to fix that. Other large companies (such as AOL) have, for some
short periods of time, also violated the DNS spec in this and similar
ways, but with prodding, they have all corrected their software to
conform to the standard.

> Do I need to apply the patches (DNS and other) or it is already
> applied with 1.06?

You'll need to apply the DNS patch yourself, yes.

~Kyle
- --
I am not myself apt to be alarmed at innovations recommended by
reason. That dread belongs to those whose interests or prejudices
shrink from the advance of truth and science.
-- Thomas Jefferson to John Manners, 1814
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkkAp4AACgkQBkIOoMqOI14ZfgCeNVonpqkQxxsg/9IYlKbbR6w4
CN8AoLEyYX+xLr83rsjgyJhNbUt+SbKV
=8bGv
-----END PGP SIGNATURE-----


vahid.moghaddasi at gmail

Oct 23, 2008, 12:09 PM

Post #5 of 16 (6928 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

On Thu, Oct 23, 2008 at 12:34 PM, Kyle Wheeler
<kyle-qmail [at] memoryhole> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday, October 23 at 11:23 AM, quoth Vahid Moghaddasi:
>> After so many years of faithful delivery, we have just noticed that
>> all the mails to *.ibm.com fails with
>> CNAME_lookup_failed_temporarily._(#4.4.3)/ and after queuelifetime it
>> bounces back to user.
>
> It would appear that IBM is violating the DNS spec, and sending
> responses that are 716 bytes long.
>
Thank you very much Kyle for your thorough response.
I will apply Chris Davis' patch and recompile.
Just to make my job a little easier, can I just deploy qmail-remote
Vahid.


matthew at dempsky

Oct 24, 2008, 1:02 PM

Post #6 of 16 (6905 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

On Thu, Oct 23, 2008 at 9:34 AM, Kyle Wheeler <kyle-qmail [at] memoryhole> wrote:
> It would appear that IBM is violating the DNS spec, and sending
> responses that are 716 bytes long.

As far as I can tell, they're sending DNS responses over UDP properly
truncated to <= 512 bytes and then sending a 700+ response over TCP.
If you run "dnsq any in.ibm.com ns.almaden.ibm.com" using dnsq from an
unpatched djbdns-1.05 install, the fact that it prints anything out
confirms this, because the djbdns dns_transmit library rejects UDP
packets over 512 bytes. You can also run
ktrace/strace/dtrace/whatever to confirm that recvfrom is only
returning <= 512 bytes.


kyle-qmail at memoryhole

Oct 24, 2008, 1:57 PM

Post #7 of 16 (6912 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday, October 24 at 01:02 PM, quoth Matthew Dempsky:
> On Thu, Oct 23, 2008 at 9:34 AM, Kyle Wheeler <kyle-qmail [at] memoryhole> wrote:
>> It would appear that IBM is violating the DNS spec, and sending
>> responses that are 716 bytes long.
>
> As far as I can tell, they're sending DNS responses over UDP properly
> truncated to <= 512 bytes and then sending a 700+ response over TCP.

Huh, interesting. You're quite right. I was using 'dig' to check, but
I forgot to turn on the +notcp +ignore options. With those options,
dig reveals that IBM's UDP responses are a mere 499 bytes.

Hmmmm.... I'm not sure what the right thing here is; does that mean
it's reasonable to expect the res_query() to return a result bigger
than PACKETSZ? It *may* be that qmail's wrong, and Christopher's patch
is the correct fix. Does anyone have any particular insight here?

~Kyle
- --
Never worry about theory as long as the machinery does what it's
supposed to do.
-- Robert A. Heinlein
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkkCNrIACgkQBkIOoMqOI17qtACg0ZUNigDWeYzNogsjMMfMe67i
oGQAn0M1FQG7Jp7hPvk8T5kAzbJxGhf/
=HUh8
-----END PGP SIGNATURE-----


johnl at iecc

Oct 25, 2008, 7:23 AM

Post #8 of 16 (6904 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

>Netqmail's website describes its patches as "the barest minimum number
>of changes", fixing "only those things which are out-and-out wrong".
>This DNS issue is NOT something that is out-and-out wrong on qmail's
>part. On the contrary, IBM is wrong.

Actually, in this case IBM is right, leaving out enough of the
optional additional records in UDP responses to keep them under 512
bytes, while returning them all if there's a TCP request. I don't
entirely understand how the extra records get returned in normal
operation, since their UDP responses don't have the truncated bit set,
but that hardly matters here.

In 1998, qmail had to run on machines with 16 bit address spaces, and
it was important to keep buffer sizes as small as possible. These
days people routinely link in megabytes of unused library code because
it's not worth the effort to prune it out. On today's net, there's no
reason not to make all the DNS buffers 64K and be done with it. I'll
suggest that for the next version of netqmail.

R's,
John


amb-1166294724 at bradfords

Oct 25, 2008, 9:47 AM

Post #9 of 16 (6915 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

Thus said Jeremy Kister on Thu, 23 Oct 2008 11:46:59 EDT:

> using dnscache as your resolver will greatly reduce the chances that
> you would need to install the dns patch, but it's still necessary.

In all the years of running qmail with dnscache I have never needed the
patch.

Andyk
--
[-----------[system uptime]--------------------------------------------]
10:47am up 10 min, 1 user, load average: 1.14, 1.15, 0.68


IFoutch at parusinteractive

Oct 25, 2008, 8:09 PM

Post #10 of 16 (6899 views)
Permalink
RE: netqmail-1.06 and DNS patch [In reply to]

This is timely since I am currently troubleshooting CNAME lookup
failures for a couple domains and have been trying to determine how to
best replicate what qmail is doing. Would a `dig example.com ANY +notcp
+ignore' be similar enough or is there a better way to do this?

It is my understanding that qmail does an "ANY" lookup and parses the
output first looking for an MX and if no MX is found then an A record.
Either of these is then checked to make sure it isn't a CNAME before
being used.

--Ian

-----Original Message-----
From: Kyle Wheeler [mailto:kyle-qmail [at] memoryhole]
Sent: Friday, October 24, 2008 3:57 PM
To: qmail [at] list
Subject: Re: netqmail-1.06 and DNS patch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday, October 24 at 01:02 PM, quoth Matthew Dempsky:
> On Thu, Oct 23, 2008 at 9:34 AM, Kyle Wheeler
<kyle-qmail [at] memoryhole> wrote:
>> It would appear that IBM is violating the DNS spec, and sending
>> responses that are 716 bytes long.
>
> As far as I can tell, they're sending DNS responses over UDP properly
> truncated to <= 512 bytes and then sending a 700+ response over TCP.

Huh, interesting. You're quite right. I was using 'dig' to check, but
I forgot to turn on the +notcp +ignore options. With those options,
dig reveals that IBM's UDP responses are a mere 499 bytes.

Hmmmm.... I'm not sure what the right thing here is; does that mean
it's reasonable to expect the res_query() to return a result bigger
than PACKETSZ? It *may* be that qmail's wrong, and Christopher's patch
is the correct fix. Does anyone have any particular insight here?

~Kyle
- --
Never worry about theory as long as the machinery does what it's
supposed to do.
-- Robert A. Heinlein
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkkCNrIACgkQBkIOoMqOI17qtACg0ZUNigDWeYzNogsjMMfMe67i
oGQAn0M1FQG7Jp7hPvk8T5kAzbJxGhf/
=HUh8
-----END PGP SIGNATURE-----


kyle-qmail at memoryhole

Oct 26, 2008, 9:29 AM

Post #11 of 16 (6883 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday, October 25 at 10:09 PM, quoth Ian Foutch:
> This is timely since I am currently troubleshooting CNAME lookup
> failures for a couple domains and have been trying to determine how
> to best replicate what qmail is doing. Would a `dig example.com ANY
> +notcp +ignore' be similar enough or is there a better way to do
> this?

Far as I know - but I'm not a DNS expert; there may be a better way.

> It is my understanding that qmail does an "ANY" lookup and parses
> the output first looking for an MX and if no MX is found then an A
> record. Either of these is then checked to make sure it isn't a
> CNAME before being used

Not quite. Qmail is required to find out if the domain is a CNAME
first, THEN do an MX lookup. It uses an ANY query instead of a CNAME
query because of an old bug in Bind 4 that didn't give correct answers
to CNAME queries (I don't know the details).

Domains that are CNAMEs aren't allowed to have MX records. MX records
aren't supposed to point to a name that is a CNAME.

~Kyle
- --
What has destroyed liberty and the rights of man in every government
which has ever existed under the sun? The generalizing and
concentrating all cares and powers into one body, no matter whether of
the autocrats of Russia or France, or of the aristocrats of a Venetian
Senate.
-- Thomas Jefferson
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkkEmv0ACgkQBkIOoMqOI15NjgCfWvuTYTcN8Rc2Yk7CUcfGvtDh
ElIAoIyWGnvVi8eb1H9OSr2TMyML8OPk
=XVPh
-----END PGP SIGNATURE-----


vahid.moghaddasi at gmail

Oct 29, 2008, 7:10 PM

Post #12 of 16 (6869 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

On Sat, Oct 25, 2008 at 12:47 PM, Andy Bradford
<amb-1166294724 [at] bradfords> wrote:
> Thus said Jeremy Kister on Thu, 23 Oct 2008 11:46:59 EDT:
>
>> using dnscache as your resolver will greatly reduce the chances that
>> you would need to install the dns patch, but it's still necessary.
>
> In all the years of running qmail with dnscache I have never needed the
> patch.
>
I am running qmail without DNS patch and with or without dnscache for
many years without any problem. *.ibm.com is the ONLY domain we are
having problem with, everyone else is just fine.
I added Christopher's DNS patch and things seem to be OK now. From
time to time I still see a few in.ibm.com mail in the queue for a long
time but it eventualy delivers.
The patch fixed it the problem that we were having only with the
*.ibm.com domains.
Thanks.


mhutchinson at manux

Nov 2, 2008, 3:29 PM

Post #13 of 16 (6820 views)
Permalink
RE: netqmail-1.06 and DNS patch [In reply to]

> -----Original Message-----
> From: Vahid Moghaddasi [mailto:vahid.moghaddasi [at] gmail]
> Sent: 24 October 2008 4:23 a.m.
> To: qmail [at] list
> Subject: netqmail-1.06 and DNS patch
>
> Hi all,
> After so many years of faithful delivery, we have just noticed that
> all the mails to *.ibm.com fails with
> CNAME_lookup_failed_temporarily._(#4.4.3)/ and after queuelifetime it
> bounces back to user.
>
> I upgraded a few servers from netqmail-1.05 to 1.06 which I assume has
> the DNS patch already in it but I still see the following errors.
>
> 2008-10-23 10:51:33.529146500 starting delivery 41344: msg 39032 to
> remote someuser [at] us
> 2008-10-23 10:51:53.540680500 delivery 41344: deferral:
> CNAME_lookup_failed_temporarily._(#4.4.3)/
> .....
> 2008-10-23 10:51:58.549636500 starting delivery 41345: msg 38922 to
> remote someuser [at] in
> 2008-10-23 10:52:18.561078500 delivery 41345: deferral:
> CNAME_lookup_failed_temporarily._(#4.4.3)/
>
> Do I need to apply the patches (DNS and other) or it is already
> applied with 1.06?
>
> Thank you,


Hello,

I don't know if this is going Off Topic, but I've had these CNAME lookup
failures before with Qmail.

We didn't bother trying to recompile Qmail or NetQmail, to fix DNS
responses, as we were able to solve delivery problem by populating
/var/control/qmail/smtproutes with the domain name and mail server
address. As this only affects a few domains we handle, this is not a
problem to maintain.

This may not be optimal for anyone else, but works really well for us.
The only thing we have to watch for is if said domain changes it's MX
IP.

AFAIK CName lookups are done by Qmail to avoid other lookup issues, so
weren't interested in changing the order of lookup types by Qmail,
either. (A rec, MX rec etc...).

HTH,
Mike
Manux Solutions Limited.


vahid.moghaddasi at gmail

Nov 13, 2009, 8:51 AM

Post #14 of 16 (5374 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

Wow, it has been just about a year that we have gone without a problem.
I found (surprisingly) another domain that gives us the CNAME error, that
is:
'alum dot mit dot edu', and we have many clients using that domain. Last
year we had problem wit 'us dot ibm dot com'. I must mention that the size
of the dns query changes from time to time but most of the time is over 512.
My qmail has the oversize DNS patched and I am also using dnscache in my
external qmail servers but I still see the error in the logs and e-mails
bounce back.
I just tried changing the DNS server to corporate bind server and the mail
is delivering fine.
My question is, even I have my qmail patched, do I still need to patch my
dnscache? What is the best practice, patch both qmail and dnscache?
Which DNS patch is 'approved' for dnscache if I need to patch it?
Thank you all.

On Sun, Oct 26, 2008 at 11:29 AM, Kyle Wheeler <kyle-qmail [at] memoryhole>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday, October 25 at 10:09 PM, quoth Ian Foutch:
> > This is timely since I am currently troubleshooting CNAME lookup
> > failures for a couple domains and have been trying to determine how
> > to best replicate what qmail is doing. Would a `dig example.com ANY
> > +notcp +ignore' be similar enough or is there a better way to do
> > this?
>
> Far as I know - but I'm not a DNS expert; there may be a better way.
>
> > It is my understanding that qmail does an "ANY" lookup and parses
> > the output first looking for an MX and if no MX is found then an A
> > record. Either of these is then checked to make sure it isn't a
> > CNAME before being used
>
> Not quite. Qmail is required to find out if the domain is a CNAME
> first, THEN do an MX lookup. It uses an ANY query instead of a CNAME
> query because of an old bug in Bind 4 that didn't give correct answers
> to CNAME queries (I don't know the details).
>
> Domains that are CNAMEs aren't allowed to have MX records. MX records
> aren't supposed to point to a name that is a CNAME.
>
> ~Kyle
> - --
> What has destroyed liberty and the rights of man in every government
> which has ever existed under the sun? The generalizing and
> concentrating all cares and powers into one body, no matter whether of
> the autocrats of Russia or France, or of the aristocrats of a Venetian
> Senate.
> -- Thomas Jefferson
> -----BEGIN PGP SIGNATURE-----
> Comment: Thank you for using encryption!
>
> iEYEARECAAYFAkkEmv0ACgkQBkIOoMqOI15NjgCfWvuTYTcN8Rc2Yk7CUcfGvtDh
> ElIAoIyWGnvVi8eb1H9OSr2TMyML8OPk
> =XVPh
> -----END PGP SIGNATURE-----
>



--
This e-mail address is not monitored so please do not send me anything
important here. Thanks.


kyle-qmail at memoryhole

Nov 13, 2009, 1:21 PM

Post #15 of 16 (5356 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Friday, November 13 at 11:51 AM, quoth Vahid Moghaddasi:
> Wow, it has been just about a year that we have gone without a problem.
> I found (surprisingly) another domain that gives us the CNAME error, that
> is:
> 'alum dot mit dot edu', and we have many clients using that domain. Last
> year we had problem wit 'us dot ibm dot com'. I must mention that the size
> of the dns query changes from time to time but most of the time is over 512.

Really? When I run `dig -t MX @strawb.mit.edu alum.mit.edu`, I get a
response back that is exactly 499 bytes. I get the exact same response
if I try MIT's other DNS servers (bitsy and w20ns). What query are you
doing that returns more than 512 bytes?

> My qmail has the oversize DNS patched and I am also using dnscache in my
> external qmail servers but I still see the error in the logs and
> e-mails bounce back.

Weird.

> My question is, even I have my qmail patched, do I still need to
> patch my dnscache?

You shouldn't need to, no. But you may have something else weird going
on. I can't imagine why your DNS responses are so large.

~Kyle
- --
There in America we are descended in blood and in spirit from
revolutionist and rebel men and women who dare to dissent from
accepted doctrine. As their heirs, may we never confuse honest dissent
with disloyal subversion.
-- Dwight D. Eisenhower
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJK/c3DAAoJECuveozR/AWeAfMP/RDuvEauU9jlVx9Xf71+YRiw
QnkypYL9O4yFvOGTMpW9sK7gipZSHI3NH3egYY5wMfw0ryNK1UQoRR2mSERDLDlo
H7XT2SXIzR8T/Xwx7Yp8jbkp+lFN9KoAyBQBZs/YrIq71KV5lmag7fDRMo2tIl5d
prmUNGq0i4mnh7s36rHQpIK9jcuz7V5vYtP3ZI6aY+blHqa9m4+/F0rNMiIyW67g
TiMY0oTq+xwHVKW+lobWVBpvP7E17RQIyUHM+nnaaePtveU7HG2Z0l8HdC12xVGh
DronZcFMZ1P0QxeGcLcvGtcq/c7+QQyeGHSNRxDf9tpA4Z6ImjvJ6sMQcBQAUMlt
souSZ2vSMprjDv4qF7aEMrMdKE7s7o/7xa7CzS19rQXCNR3lAwoMcC3SpbFwa0sO
QX8OlPvpr+vGaaK7OYRho0dedMXnH9AtNkPheUkfEy42tw886kSle8NKUSzM1H/N
gWbaFar8OiUN0zUZrcu/R/3TtOziOGQJ3Lxi+NxMQRL5I36wlMfYU1j4a5+KfPqP
c4on59IkNQmZ8Vx3lrySglZzb9ygNJqDZFLvsi/Y5KDL+CoT0EFi0ehcv45smGwD
Ys4zJWUN9aoZGpfIBCmrQwWJvsE5tp/blmbL3R2Gk4+EPFfdp1mwCg3qsOcaYaDj
qS/2Qfe+d+s3Fhmatcxn
=Gbgo
-----END PGP SIGNATURE-----


vahid.moghaddasi at gmail

Nov 14, 2009, 7:26 AM

Post #16 of 16 (5340 views)
Permalink
Re: netqmail-1.06 and DNS patch [In reply to]

On Fri, Nov 13, 2009 at 4:21 PM, Kyle Wheeler <kyle-qmail [at] memoryhole>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Friday, November 13 at 11:51 AM, quoth Vahid Moghaddasi:
> > Wow, it has been just about a year that we have gone without a problem.
> > I found (surprisingly) another domain that gives us the CNAME error, that
> > is:
> > 'alum dot mit dot edu', and we have many clients using that domain. Last
> > year we had problem wit 'us dot ibm dot com'. I must mention that the
> size
> > of the dns query changes from time to time but most of the time is over
> 512.
>
> Really? When I run `dig -t MX @strawb.mit.edu alum.mit.edu`, I get a
> response back that is exactly 499 bytes. I get the exact same response
> if I try MIT's other DNS servers (bitsy and w20ns). What query are you
> doing that returns more than 512 bytes?
>
> > My qmail has the oversize DNS patched and I am also using dnscache in my
> > external qmail servers but I still see the error in the logs and
> > e-mails bounce back.
>
> Weird.
>
> > My question is, even I have my qmail patched, do I still need to
> > patch my dnscache?
>
> You shouldn't need to, no. But you may have something else weird going
> on. I can't imagine why your DNS responses are so large.
>
> Thanks Kyle for your reply.
I did 'dnsqr any alum.mit.edu' and i get:
255 alum.mit.edu:
501 bytes, 1+10+0+2 records, response, noerror
query: 255 alum.mit.edu
answer: alum.mit.edu 60 16 bv=spf1\040ip4:18.7.7.0/24\040ip4:18.7.21.0/24
\040\040ip4:18.72.0.0/16\040ip4:18.92.0.171/32\040ip4:18.7.68.0/24\040~all
answer: alum.mit.edu 120 A 18.92.0.171
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-8.mit.edu
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-1.mit.edu
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-2.mit.edu
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-3.mit.edu
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-4.mit.edu
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-5.mit.edu
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-6.mit.edu
answer: alum.mit.edu 120 MX 100 alum-mailsec-scanner-7.mit.edu
additional: alum-mailsec-scanner-4.mit.edu 13198 A 18.7.68.15
additional: alum-mailsec-scanner-5.mit.edu 11877 A 18.7.68.17
Today, the size is not over 512 bytes.
Is there a way that I can check my dnscache to see if it is handling large
UDP size?
I am certain that if I change the dns server to dnscache, I will have
trouble sending mail to mit, I could not believe it myself.
Thanks again.

Qmail users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.