Large DNS packets patch for Qmail

General Discussion of atomic repo and development projects.

Ask for help here with anything else not covered by other forums.
manarak
Forum User
Forum User
Posts: 29
Joined: Sat Jul 02, 2005 6:04 am

Large DNS packets patch for Qmail

Unread post by manarak »

Hi, I got a problem sending Mail to AOL, Hotmail, and other big sites.

Now I found out this:
The "qmail.org" web site suggests that you may be able to get around
this problem somewhat by installing the "djbdns" package, and in
particular, "dnscache" from that package.

Installing "djbdns" is generally a good idea, but it does not
genuinely fix this problem.

The cause of this problem is as follows:

"qmail-remote" wants to perform "CNAME" lookups of the domain
names that mail is to be sent to. However, instead of doing a
"CNAME" DNS lookup directly, it performs an "ANY" DNS lookup
and scans the result for "CNAME" resource records. It does
this because of a bug in BIND version 4 that would be triggered
if it did "CNAME" lookups directly.

But "qmail" only employs a 512-byte buffer to receive the DNS
response. Unfortunately, an "ANY" lookup for several popular
domains (such as "aol.com.") now yields a response bigger than
512 bytes, and the DNS lookup fails because the response size
exceeds the size of the buffer that "qmail" has to hold it.
(An "ANY" response for "aol.com." was 543 bytes - and even that
was with the "glue" stripped - at the time of writing this
answer.)

Installing "dnscache" partially alleviates this problem because
"dnscache" provides smaller answers to "ANY" queries than other
proxy DNS server softwares, such as BIND, do. This happens to
defer the onset of this problem in most cases.

However, this is not a true solution. The problem can still occur
even if one employs "dnscache". The the maximum size that a DNS
response can be is 65536 bytes, and "qmail"'s DNS response buffer
should therefore be capable of holding responses up to this size.
The correct fix is to apply Christopher K. Davis' patch (hyperlink
given above) that increases "qmail"'s buffer to 65536 bytes.

Whilst you are about it, you also might consider applying the
patch (hyperlink given above) that makes "qmail" actually use
"CNAME" queries when it wants to look up "CNAME" resource
records.

[Edited to remove references to LWQ, which has been updated to
recommend
Davis' patch. -DS, 2004-03-02]
Question: does qmail provided by ART already include that patch?
breun
Long Time Forum Regular
Long Time Forum Regular
Posts: 2813
Joined: Sat Aug 20, 2005 9:30 am
Location: The Netherlands

Unread post by breun »

I'm running Plesk's qmail and I don't have any problems sending mail. Are you sure your server is not blacklisted? What is the problem exactly? Do you get an error message?
Lemonbit Internet Dedicated Server Management
breun
Long Time Forum Regular
Long Time Forum Regular
Posts: 2813
Joined: Sat Aug 20, 2005 9:30 am
Location: The Netherlands

Unread post by breun »

See the following KB articles for Plesk's qmail patch sets:

Plesk 7.5.4: http://kb.swsoft.com/article_22_1088_en.html
Plesk 8: http://kb.swsoft.com/article_22_1161_en.html

Both sets contain a file called patch-big-dns.
Lemonbit Internet Dedicated Server Management
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Unread post by scott »

I have a sort of lighter weight version of that patch in the qmail rpm. patch-big-dns is a better implementation, although its unlikely that you'll ever need it on my qmail, since its for Project Gamera, a largely inbound-only MTA design. You'd likely never run into that problem, since it uses a completely different mechanism to send mail to your real server, smtproutes, which doesn't use DNS.
manarak
Forum User
Forum User
Posts: 29
Joined: Sat Jul 02, 2005 6:04 am

Unread post by manarak »

Hi all, my server isn't blacklisted.

I do not get any error message by email, but in the log, the following is written:

Delivery 32080: deferral: Sorry,_I_couldn't_find_any_host_by_that_name._(#4.1.2)/

it happens for example with emails on the domain jasminprinting.com
or yahoo.com or rocketmail.com or ocweddinginfo.com

is there a tool to check for the size of DNS records?
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Unread post by scott »

nslookup and host come to mind
manarak
Forum User
Forum User
Posts: 29
Joined: Sat Jul 02, 2005 6:04 am

Unread post by manarak »

ok, I get SERVFAIL for any query.

the messages log says "can't get client address, connection reset by peer"

here is my named.conf - I can't spot the problem

Code: Select all

options {
	directory "/var";
	auth-nxdomain no;
	pid-file "/var/run/named/named.pid";
	allow-recursion { 127.0.0.1; IP1; IP2; };
		
// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
//      forward only;

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
	forwarders {
		127.0.0.1;
	};
*/
	/*
	 * If there is a firewall between you and nameservers you want
	 * to talk to, you might need to uncomment the query-source
	 * directive below.  Previous versions of BIND always asked
	 * questions using port 53, but BIND 8.1 uses an unprivileged
	 * port by default.
	 */
	// query-source address * port 53;
version "named";
	/*
	 * If running in a sandbox, you may have to specify a different
	 * location for the dumpfile.
	 */
	// dump-file "s/named_dump.db";
};

//Use with the following in named.conf, adjusting the allow list as needed:

key "rndc-key" {
	algorithm hmac-md5;
	secret "CeMgS23y0oWE20nyv0x40Q==";
};

controls {
	inet 127.0.0.1 port 953
	allow { 127.0.0.1; } keys { "rndc-key"; };
};

// Note: the following will be supported in a future release.
/*
host { any; } {
	topology {
		127.0.0.0/8;
	};
};
*/

// Setting up secondaries is way easier and the rough picture for this
// is explained below.
//
// If you enable a local name server, don't forget to enter 127.0.0.1
// into your /etc/resolv.conf so this server will be queried first.
// Also, make sure to enable it in /etc/rc.conf.

zone "." {
	type hint;
	file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
	type master;
	file "localhost.rev";
};

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example secondary config entries.  It can be convenient to become
// a secondary at least for the zone where your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
// (This is the first bytes of the respective IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
// Before starting to setup a primary zone, better make sure you fully
// understand how DNS and BIND works, however.  There are sometimes
// unobvious pitfalls.  Setting up a secondary is comparably simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.
//
// NOTE!!! FreeBSD runs bind in a sandbox (see named_flags in rc.conf).
// The directory containing the secondary zones must be write accessible 
// to bind.  The following sequence is suggested:
//
//	mkdir /etc/namedb/s
//	chown bind.bind /etc/namedb/s
//	chmod 750 /etc/namedb

//      include /etc/psaptzone.files;


zone "0.168.192.in-addr.arpa" {
	type master;
	file "0.168.192.in-addr.arpa";
	allow-transfer {
		common-allow-transfer;
	};
};
zone "domain1" {
	type master;
	file "domain1";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain2" {
	type master;
	file "domain2";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain3" {
	type master;
	file "domain3";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain4" {
	type master;
	file "domain4";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain5" {
	type master;
	file "domain5";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain6" {
	type master;
	file "domain6";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain7" {
	type master;
	file "domain7";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain8" {
	type master;
	file "domain8";
	allow-transfer {
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain9" {
	type master;
	file "domain9";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain10" {
	type master;
	file "domain10";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain11" {
	type master;
	file "domain11";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain12" {
	type master;
	file "domain12";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain13" {
	type master;
	file "domain13";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};

zone "domain14" {
	type master;
	file "domain14";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain15" {
	type master;
	file "domain15";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain16" {
	type master;
	file "domain16";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "246.150.217.in-addr.arpa" {
	type master;
	file "246.150.217.in-addr.arpa";
	allow-transfer {
		common-allow-transfer;
	};
};
zone "domain17" {
	type master;
	file "domain17";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain18" {
	type master;
	file "domain18";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "domain19" {
	type master;
	file "domain19";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain20" {
	type master;
	file "domain20";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain21" {
	type master;
	file "domain21";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain22" {
	type master;
	file "domain22";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain23" {
	type master;
	file "domain23";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain24" {
	type master;
	file "domain24";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain25" {
	type master;
	file "domain25";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain26" {
	type master;
	file "domain26";
	allow-transfer {
		217.150.243.53;
		217.150.246.134;
		common-allow-transfer;
	};
};
zone "domain27" {
	type master;
	file "domain27";
	allow-transfer {
		217.150.243.53;
		common-allow-transfer;
	};
};
zone "243.150.217.in-addr.arpa" {
	type master;
	file "243.150.217.in-addr.arpa";
	allow-transfer {
		common-allow-transfer;
	};
};
acl common-allow-transfer {
	none;
};
manarak
Forum User
Forum User
Posts: 29
Joined: Sat Jul 02, 2005 6:04 am

Unread post by manarak »

I just noticed that my box queries a wrong server about the domains. Where can I change the server that is being queried?
manarak
Forum User
Forum User
Posts: 29
Joined: Sat Jul 02, 2005 6:04 am

Unread post by manarak »

OK resolv.conf

corrected address.

nslookup now works.

testing...
manarak
Forum User
Forum User
Posts: 29
Joined: Sat Jul 02, 2005 6:04 am

Unread post by manarak »

solved.
it wasn't a large dns packets problem after all, but a misconfigured resolv.conf

amazing though that only a handful of domains was affected, the other mails were delivered fine.
Post Reply