Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers

Viktor Dukhovni <> Thu, 21 November 2013 17:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A2F221AE21E for <>; Thu, 21 Nov 2013 09:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6pJsc5lgcEby for <>; Thu, 21 Nov 2013 09:29:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0E7C91AE21A for <>; Thu, 21 Nov 2013 09:29:41 -0800 (PST)
Received: by (Postfix, from userid 1034) id 4CCB02AB155; Thu, 21 Nov 2013 17:29:34 +0000 (UTC)
Date: Thu, 21 Nov 2013 17:29:34 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Nov 2013 17:29:43 -0000

On Thu, Nov 21, 2013 at 12:08:38PM -0500, James Cloos wrote:

> Given insecure a/aaaa results, it is reasonable to presume that tlsa
> resaults also will be insecure.

Thanks, this is on the list for inclusion in the OPS and SMTP drafts.

> Avoiding the tlsa lookup has the downside of serializing the requests,
> but that appears to be necessary in the face of b0rked auth servers.

Yes, though for Postfix the serialization is unavoidable, TLS policy
is loaded one MX destination at a time (in preparation for delivery
to that destination), after the network address is already in hand.

[ The network address is needed early for loop elimination.  Postfix
determines whether it is an MX host for the destination by comparing
network addresses, not hostnames.  Therefore the network addresses
of all equal-preference hosts need to be available, before delivery
to any host at that preference.  Hence the $proxy_interfaces
parameter for MX hosts behind a NAT. ]

Also Postfix + DANE requires a validating resolver on the loopback
interface, so latency is a bit less of a concern, at least for
high-volume destinations where the local cache amortises lookup