Qmail can't deliver to DNSSEC protected domains. (Repost from edri.org-ML) Reason: - qmail send an "ANY IN edri.org" query in order to deliver mail. * Due to DNSSEC, there are a some signatures catched by ANY so the response packet size is 605 bytes. - qmail does not support EDNS extensions for larger UDP packets. * The response is truncated to 512 bytes and marked "truncated". - qmail does not support the very old TCP fallback requirement for DNS. - qmail refuses to deliver the mail and logs "CNAME_lookup_failed_temporarily." Overview of packet sizes question | answer size -----------------------|-------------- ANY edri.org | 605 byte MX edri.org | 237 byte A edri.org | 213 byte -----------------------|-------------- ANY edri.org +dnssec | 1331 byte MX edri.org +dnssec | 923 byte A edri.org +dnssec | 731 byte
dns-wg-admin@ripe.net wrote on 17-02-2006 12:11:00:
Qmail can't deliver to DNSSEC protected domains. (Repost from edri.org-ML)
Reason: - qmail send an "ANY IN edri.org" query in order to deliver mail. * Due to DNSSEC, there are a some signatures catched by ANY so the response packet size is 605 bytes. - qmail does not support EDNS extensions for larger UDP packets. * The response is truncated to 512 bytes and marked "truncated". - qmail does not support the very old TCP fallback requirement for DNS. - qmail refuses to deliver the mail and logs "CNAME_lookup_failed_temporarily."
I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content. I am not sure what CNAME has to do with this. I have seen patches for qmail that make it handle larger udp packet sizes. Which service marks a DNS message 'truncated' in your example ? Roy
On Feb 17, 2006, at 11:11, Lutz Donnerhacke wrote:
Qmail can't deliver to DNSSEC protected domains. (Repost from edri.org-ML)
Reason: - qmail send an "ANY IN edri.org" query in order to deliver mail. * Due to DNSSEC, there are a some signatures catched by ANY so the response packet size is 605 bytes. - qmail does not support EDNS extensions for larger UDP packets. * The response is truncated to 512 bytes and marked "truncated". - qmail does not support the very old TCP fallback requirement for DNS. - qmail refuses to deliver the mail and logs "CNAME_lookup_failed_temporarily."
Hmmm. Even though DJB's enthusiasm for DNSSEC is well known, I'm not sure it's fair to be blaming qmail. Well this time at least... This looks to be a local name server misconfiguration. Or perhaps a bug. qmail won't be asking for DNSSEC RR types. That's for sure. And it won't be setting the DO bit either because DJB is no fan of EDNS0. So qmail's lookups should not be getting RRSIGs and suchlike, which would hopefully mean it won't get truncated responses. RFC3225 says don't send DNSSEC RRtypes unless the client has set the DO bit to indicate they understand DNSSEC. So your local name server shouldn't be handing out these RRtypes to qmail's ANY QTYPE queries unless qmail set the D0 bit. Or have I missed something?
* Jim Reid wrote:
qmail won't be asking for DNSSEC RR types. That's for sure. And it won't be setting the DO bit either because DJB is no fan of EDNS0.
Qmail asks for "ANY" and this includes "NSEC" and "RRSIG", too. Qmail does not support EDNS and therefore get an truncated response as RfC 1035 requires. Qmail does not support the TCP fallback requirement and got struck.
So qmail's lookups should not be getting RRSIGs
If qmail would ask for "MX" and "A", there would be no problem at all. But qmail ask for "ANY".
So your local name server shouldn't be handing out these RRtypes to qmail's ANY QTYPE queries unless qmail set the D0 bit.
"NSEC" and "RRSIG" are covered by "ANY".
* Lutz Donnerhacke wrote:
Qmail does not support EDNS and therefore get an truncated response as RfC 1035 requires.
It's even worse. qmail uses the libc resolver. If it's a bind resolver, qmail provides 512 bytes buffer, so bind can only fill in truncated data. If it's djbdns, the buffer will contain no data at all. Both resolvers provide approbiate return codes which qmail ignores.
Qmail can't deliver to DNSSEC protected domains. (Repost from edri.org-ML)
Reason: - qmail send an "ANY IN edri.org" query in order to deliver mail. * Due to DNSSEC, there are a some signatures catched by ANY so the response packet size is 605 bytes. - qmail does not support EDNS extensions for larger UDP packets. * The response is truncated to 512 bytes and marked "truncated". - qmail does not support the very old TCP fallback requirement for DNS. - qmail refuses to deliver the mail and logs "CNAME_lookup_failed_temporarily."
I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content. I am not sure what CNAME has to do with this. I have seen patches for qmail that make it handle larger udp packet sizes. Which service marks a DNS message 'truncated' in your example ? Roy
* Roy Arends wrote:
I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content.
Of course. The ANY request for "bofh." does exceed 512 bytes, too. In this case it's caused by the large number of NS records. DNSSEC "guarantees" exceeding this limit.
I am not sure what CNAME has to do with this.
djb might notify this only the case of CNAMEs, because the additional section becomes be quite long.
I have seen patches for qmail that make it handle larger udp packet sizes.
You have to install them in order to send mail to DNSSEC domains.
Which service marks a DNS message 'truncated' in your example ?
The questioned nameserver. Setting the TC bit is a requirement from RfC 1035.
* Roy Arends wrote:
I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content.
Of course. The ANY request for "bofh." does exceed 512 bytes, too. In this case it's caused by the large number of NS records. DNSSEC "guarantees" exceeding this limit.
Which service marks a DNS message 'truncated' in your example ?
The questioned nameserver. Setting the TC bit is a requirement from RfC
Does it ? I can think of dnssec responses that are smaller than 512 octets. 1035. The questioned nameserver has the luxury of constructing a response so that it _at_least_ satisfies the request. There is for instance no need for authority and additional section information to be send to the stub. I have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or DNSKEYs to a stub if the DO bit was not set. ANY only covers those if DO=1. I suspect that the questioned nameserver is broken. Roy
* Roy Arends wrote:
I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content.
Of course. The ANY request for "bofh." does exceed 512 bytes, too. In this case it's caused by the large number of NS records. DNSSEC "guarantees" exceeding this limit.
Which service marks a DNS message 'truncated' in your example ?
The questioned nameserver. Setting the TC bit is a requirement from RfC
Does it ? I can think of dnssec responses that are smaller than 512 octets. 1035. The questioned nameserver has the luxury of constructing a response so that it _at_least_ satisfies the request. There is for instance no need for authority and additional section information to be send to the stub. I have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or DNSKEYs to a stub if the DO bit was not set. ANY only covers those if DO=1. I suspect that the questioned nameserver is broken. Roy
On Fri, Feb 17, 2006 at 02:39:02PM +0100, Roy Arends wrote:
for authority and additional section information to be send to the stub. I have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or DNSKEYs to a stub if the DO bit was not set. ANY only covers those if DO=1. [...]
section 3 of RFC 4035 (top of page 9) says: A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below. "treat ... as it would any other RRset" would support ANY covering those, which is consistent with RFC 3225. -Peter
On Fri, Feb 17, 2006 at 02:39:02PM +0100, Roy Arends wrote:
for authority and additional section information to be send to the stub. I have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or DNSKEYs to a stub if the DO bit was not set. ANY only covers those if DO=1. [...]
section 3 of RFC 4035 (top of page 9) says:
A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below.
"treat ... as it would any other RRset" would support ANY covering
dns-wg-admin@ripe.net wrote on 17-02-2006 14:49:16: those,
which is consistent with RFC 3225.
-Peter
Maybe this helps: 3.2. Recursive Name Servers 3.2.1. The DO Bit The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested. The important part is the last full sentence. Roy
On Fri, Feb 17, 2006 at 11:11:00AM +0000, Lutz Donnerhacke wrote:
- qmail send an "ANY IN edri.org" query in order to deliver mail.
MX has been around for quite a while.
* Due to DNSSEC, there are a some signatures catched by ANY so the response packet size is 605 bytes.
Qmail has already had problems in the past with domain names where an ANY response exceeds 512 octets. It happens with large NS RRsets, RFC1101 PTRs or large TXT RR(Set)s which seem not so uncommon these days (although that's a mistake). There was a patch at <http://www.ckdhr.com/ckd/qmail-103.patch>, but i have no idea whether that can be applied today.
- qmail does not support EDNS extensions for larger UDP packets.
That's probably not the application's problem, but the resolver's.
* The response is truncated to 512 bytes and marked "truncated". - qmail does not support the very old TCP fallback requirement for DNS.
If that's the case, see above.
MX edri.org | 237 byte A edri.org | 213 byte
These are fine.
ANY edri.org +dnssec | 1331 byte MX edri.org +dnssec | 923 byte A edri.org +dnssec | 731 byte
These are also fine, since per RFC 3226 the resolver asking for DNSSEC must support at least 1220 octets payload. The interesting question here is whether there are other applications that issue ANY queries (most likely for the zone apex) and their resolvers _do_ fall back to TCP. -Peter
* Peter Koch <pk@DENIC.DE> [2006-02-17 12:49]:
- qmail does not support EDNS extensions for larger UDP packets. That's probably not the application's problem, but the resolver's.
no, since qmail reimplements the resolver parts (don't make me comment on that)
* The response is truncated to 512 bytes and marked "truncated". - qmail does not support the very old TCP fallback requirement for DNS. If that's the case, see above.
see above - it IS qmail's fault. there's plenty of patches around to make it at leats re-query over TCP for those whi want to work around that bug. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
* Henning Brauer wrote:
no, since qmail reimplements the resolver parts (don't make me comment on that)
Even worse. The native qmail does use the resolver vom the libc, but only provides a buffer of 512 bytes. After the request qmail ignores the API result code and parses the buffer. If qmail runs in a bind enviroment, it finds some usable records and continues. If qmail runs with djbdns, the resolver does not fills the buffer at all (correct, too). Qmail does not find any record in the response and concludes, that it must be a temporary cname problem. You refer to a version with an applied patch: Partial reimplemenation od tinydns into qmail. There seems to be another patch out there, which allows TCP for DNS.
* Peter Koch wrote:
The interesting question here is whether there are other applications that issue ANY queries (most likely for the zone apex) and their resolvers _do_ fall back to TCP.
We notify a similar problem with sendmail. The interal resolver for DNS-mapping rules does not fall back to TCP. It does not cause any trouble here, because it supports EDNS and our zones are small enough. We notice the problem only, because some spammers resolve their temporary domains to an MX with 254 A records (a whole /24).
On Fri, 17 Feb 2006, Roy Arends wrote:
Qmail can't deliver to DNSSEC protected domains. (Repost from edri.org-ML)
Reason: - qmail does not support the very old TCP fallback requirement for DNS. - qmail refuses to deliver the mail and logs "CNAME_lookup_failed_temporarily."
I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content. I am not sure what CNAME has to do with this.
The logic leading to that log message is 'I did not receive a valid A or MX record result, so I must have been looking up a CNAME and the remote DNS server failed to give a response'. Qmail should (according to qmail FAQ 2.5) retry the message later, however it will most probably get the same result as the remote zone will not have changed. On Fri, 17 Feb 2006, Peter Koch wrote:
Qmail has already had problems in the past with domain names where an ANY response exceeds 512 octets. It happens with large NS RRsets, RFC1101 PTRs or large TXT RR(Set)s which seem not so uncommon these days (although that's a mistake). There was a patch at <http://www.ckdhr.com/ckd/qmail-103.patch>, but i have no idea whether that can be applied today.
No new releases of qmail by the author have been made since that patch was created; it should still apply.
- qmail does not support EDNS extensions for larger UDP packets.
That's probably not the application's problem, but the resolver's.
Qmail runs its own resolver, which is where the problem arises. -- Bruce Campbell
participants (7)
-
Bruce Campbell -
Henning Brauer -
Jim Reid -
Lutz Donnerhacke -
Peter Koch -
Roy Arends -
Roy.Arends＠nominet.org.uk