CNAME lookup failure started

[Mark Johnson]

However, I use a patched version of djbdns allowing 'big' UDP packets
(common these days). I suggest to enhance the value of 'udpbuf' in
int dns_transmit_get(struct dns_transmit *d,const iopause_fd *x,const
struct taia *when)
{
char udpbuf[1200];
unsigned char ch;
int r;
int fd;
Remember: The original maximum size for UDP packets was due to the IPv4
MTU constraints, roughly about 500 byte. Current networks -- able to
transmit IPv6 packets -- need to support a minimum MTU of 1280 byte.
Change that value and recompile. This changed value will now be the
standard maximum size of all djbdns traffic.
regards.
--eh.
--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de

FYI, I merged a similar fix (patch from Matthew Dempsky) into zinq-djbdns a
while back:

http://zinq.svn.sourceforge.net/viewvc/zinq/dns/trunk/dns_transmit.c?r1=51&r2=66
http://marc.info/?l=djbdns&m=122368590802063&w=2

[Vahid Moghaddasi]

Post by Mark Johnson

However, I use a patched version of djbdns allowing 'big' UDP packets
(common these days). I suggest to enhance the value of 'udpbuf' in
int dns_transmit_get(struct dns_transmit *d,const iopause_fd *x,const
struct taia *when)
{
char udpbuf[1200];
unsigned char ch;
int r;
int fd;
Remember: The original maximum size for UDP packets was due to the IPv4
MTU constraints, roughly about 500 byte. Current networks -- able to
transmit IPv6 packets -- need to support a minimum MTU of 1280 byte.
Change that value and recompile. This changed value will now be the
standard maximum size of all djbdns traffic.
regards.
--eh.
--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de

FYI, I merged a similar fix (patch from Matthew Dempsky) into zinq-djbdns a
http://zinq.svn.sourceforge.net/viewvc/zinq/dns/trunk/dns_transmit.c?r1=51&r2=66
http://marc.info/?l=djbdns&m=122368590802063&w=2

I have all the necessary patches for oversised UDP packets but what I am not
clear is why everyone is thinking this is a DJBdns problem?
I tried this on any machine and get the same result, regardless of the DNS
server.
dig -t any IX.NETCOM.COM will hang but when you do dig -t mx
IX.NETCOM.COMeverything is ok a while and dig -t any
IX.NETCOM.COM will no longer hangs for a few hours.

[David I. Bell]

Hi All,

Post by Vahid Moghaddasi
I have all the necessary patches for oversised UDP packets but what I am not
clear is why everyone is thinking this is a DJBdns problem?
I tried this on any machine and get the same result, regardless of the DNS
server.
dig -t any IX.NETCOM.COM will hang but when you do dig -t mx IX.NETCOM.COM
everything is ok a while and dig -t any IX.NETCOM.COM will no longer hangs
for a few hours.

I have noticed the same CNAME deferral problem crop up for
ix.netcom.com (and a few other domains) lately. I already have the
buffer size patch installed and that's not the source of the problem.
The problem appears to have something to do with the DNS servers for
the domains causing problems. The qmail dns.c code uses T_ANY in the
dns_cname() function. Change that to a T_CNAME and life gets better.
I presume there was a good reason for using type T_ANY in the
dns_cname() function instead of T_CNAME. Can someone explain?

- David

[Vahid Moghaddasi]

Post by David I. Bell
I have noticed the same CNAME deferral problem crop up for
ix.netcom.com (and a few other domains) lately. I already have the
buffer size patch installed and that's not the source of the problem.
The problem appears to have something to do with the DNS servers for
the domains causing problems. The qmail dns.c code uses T_ANY in the
dns_cname() function. Change that to a T_CNAME and life gets better.
I presume there was a good reason for using type T_ANY in the
dns_cname() function instead of T_CNAME. Can someone explain?
- David

I only see one place in dns.c with T_ANY (line 214) and one T_CNAME (line
220), changing T_ANY would not break any part of qmail? I guess you have it
that way for a while?