[dns-operations] DNSSEC and qmail

George Barwood george.barwood at blueyonder.co.uk
Thu Oct 8 18:37:20 UTC 2009


----- Original Message ----- 
From: "David Conrad" <drc at virtualized.org>
To: "George Barwood" <george.barwood at blueyonder.co.uk>
Cc: <dns-operations at mail.dns-oarc.net>
Sent: Thursday, October 08, 2009 6:52 PM
Subject: Re: [dns-operations] DNSSEC and qmail


> George,
> 
> On Oct 8, 2009, at 5:48 AM, George Barwood wrote:
>> Either the authors of RFC 3225 knew about the issue and did not  
>> document it in the security section
>> ( which would be reprehensible ), or more likely did not consider it  
>> - I have not found any discussion of the
>> issue at the time. So it goes.
> 
> I don't recall being aware of that particular brokenness of qmail.
> 
>> To some extent RFC 3225 contradicts itself,
> 
> In what way?

The whole intent and rationale of the draft, and statements such as 

"The DO bit cleared (set to zero) indicates the resolver
is unprepared to handle DNSSEC  security RRs and those RRs
MUST NOT be returned in the response (unless DNSSEC security
RRs are explicitly queried for)."
 
When I saw the ANY type listed, I initially thought oops,
it was maybe a clerical error, and thought that's inconsistent
with the whole purpose of the document.
 
I can understand that it's surprising that an application
would use ANY, so it probably wouldn't seem of much 
consequence without that knowledge, but in fact it now
makes it impossible for me to deploy DNSSEC without
risking bouncing email, which is quite unfortunate.

Even if qmail (and other applications using ANY) did handle
truncated responses perfectly, it would still seem odd and unfair
to penalize them with extra overhead for no good reason, when
other applications are protected.
 
Regards,
George

> Regards,
> -drc
> 
>


More information about the dns-operations mailing list