[dns-operations] DNSSEC misconfiguration

[Michael Sinatra]

On 07/31/10 00:21, George Barwood wrote:
>
> ----- Original Message -----
> From: "Tony Finch"<dot at dotat.at>
> To: "Carlos Vicente"<cvicente at network-services.uoregon.edu>
> Cc:<dns-operations at dns-oarc.net>
> Sent: Friday, July 30, 2010 11:34 PM
> Subject: Re: [dns-operations] DNSSEC misconfiguration
>
>
>> What has caused problems that users notice is qmail's DNS resolution bugs which make it unable to cope with our signed zone.
>
> This is due to the unfortunate standards decision to make ANY insensitive to the DO flag.

Actually, it's caused by the hideously broken behavior of qmail, where 
it rejects a DNS response longer than 512 bytes, regardless of whether 
TCP was used.  The consequences of this behavior came up long before 
DNSSEC, with email domains with large numbers of MX records (e.g. AOL 
several years ago).

> Can you give more details on the scale of the qmail problem? Currently it's hard to know
> how serious the problem is likely to be. Maybe the major qmail users have now applied the relevant patch.
>
> I am using my own software (GbDns) which doesn't send DNSSEC records in response to
> an ANY query unless DO=1 ( not standards compliant, but this doesn't cause any problems ).
>
> Maybe other suppliers of DNSSEC software could also support this to allow DNSSEC to be deployed
> in corporate environments ( where chasing up email that cannot be delivered is not a realistic option ).

I am not opposed to implementations doing this (although I could see why 
implementers might be), but I don't see this as a standards problem. 
It's a problem with a broken email implementation (one that has always 
been broken, at least with respect to this behavior).  There are patches 
to fix it.  In 8 months of signing, I have received exactly 3 complaints 
about it.  There are probably more issues out there (especially if they 
can't email me about it!), but this is not a problem that demands a 
standards response (and keep in mind this is coming from an ops guy).

michael