Re: [lamps] DNS DNAME pain.

Phillip Hallam-Baker <> Thu, 09 November 2017 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DA99124C27 for <>; Thu, 9 Nov 2017 08:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n5LXrI_mXgr6 for <>; Thu, 9 Nov 2017 08:48:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E4FB12025C for <>; Thu, 9 Nov 2017 08:48:01 -0800 (PST)
Received: by with SMTP id b49so2488705otj.5 for <>; Thu, 09 Nov 2017 08:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WJsRP3tJeSALwM8T60lBEdmSI12Ww6Fp7Kj6tASv6Ro=; b=cezx0ejS7TjgrpYtkAlTtHke9GONjKGWdvWUgU1/XHCzVZSBMCFuRFQgPwdSo7ND4q 3CfvOR8mcbD1bUxJPE2JQZgs1+x4GGC5IDjG6g1Vbh1yJQIlzqIjPZ912PdMzL9bKhR3 W0x0Dyzdcl9B6ag+CpTPYD7aSrG00AjG03WIp17Gl4YlFMVMzg2EhcUYZtwf9C/LhgG6 4+nG6rPPnLRGDGeUV/fE45Bh+OZq+C4MurhWW9CCp64I4FkbNgTOPXgdlY4UDGsgo63C e0THp8kcwE53Mbvg3dV4UEfbbmBQN6J0NaOaQ3PfwYOebtthQrZ9Vg2TdkL6Rq6Np2Bo askQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WJsRP3tJeSALwM8T60lBEdmSI12Ww6Fp7Kj6tASv6Ro=; b=c0zQ2bsIaq54Hv46ozW0oOSXb/IsLFY74TDXx6HH67SAulf8b6qJjSitjtR4U0vSop 2XcU8QjYeyHQojFnhwln+wu8gkPpVpnaOnG4Y6I2pzcfHG0D5Zp9jx56UZNC5hL4cxZg ts6R+dnriVrwefk1+NZJ+19nt2F3euWw8OD/ZESdqMBDRlHPKCdjwWCkwxap6zeWvKiK WVsUMtHYCL+yQCKP9ePSOJ95rN2xB6PA3Jht7xccUDyLSuXu2sYBYQy7gweyevTJwS6H 7yBx48oGTyuqLc2buOVbI8xUr/VSa8zOHKgSR031F5dOtoswrb8pOAZapgWBLOPBx/sQ +31w==
X-Gm-Message-State: AJaThX49THruoQCthXUl6idRWGitP7nSE/uHHABhwC74vM9LVBRtIen0 Z7mM5Tx2R0zuj6UOar+c7/XDqXVutDV0V7gMiEo=
X-Google-Smtp-Source: AGs4zMbtrulnUtJ4Uyg6sH1xIvOcGjo23X8FYtsX/6L7nFcbUwT33Tuzt9og992QeB3eC/e94ricjwTbkRvOstDbw6s=
X-Received: by with SMTP id y32mr672354ota.373.1510246080414; Thu, 09 Nov 2017 08:48:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Nov 2017 08:47:59 -0800 (PST)
In-Reply-To: <20171109162941.3670.qmail@ary.lan>
References: <> <20171109162941.3670.qmail@ary.lan>
From: Phillip Hallam-Baker <>
Date: Thu, 9 Nov 2017 11:47:59 -0500
X-Google-Sender-Auth: NqSypONTGVv0ajdHn1fcLLbRT9s
Message-ID: <>
To: John Levine <>
Cc: SPASM <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [lamps] DNS DNAME pain.
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Nov 2017 16:48:07 -0000

On Thu, Nov 9, 2017 at 11:29 AM, John Levine <> wrote:
> In article <> you write:

>>It is not clear to me how the following is required to be interpreted:
>> CAA foo
> DNAME only maps names below it, so the CAA is fine.

That is my understanding from the text, the example suggests
otherwise. I would like to check that the old behavior of not matching
the root is still valid.

>>It might well be that the way to solve the DNAME problem is to specify
>>a new zone mapping record that does the job in a way that meets DNS
>>admins needs. ...
> There's a BNAME proposal kicking around that is sort of a combined
> CNAME and DNAME, mapping everything at and below the name.  Or do you
> mean something else like a translucent DNAME that only maps if there's
> nothing at the actual name?

I am aware that there have been proposals circulating, I have not been
tracking them directly. They seem to always be about to happen in a
year or two.

For anything of this sort, I would like the approach to be
'aggressively seek out all the requirements and solve them'.
Requirement discovery through deployment is a bad approach. We should
address requirements discovered through deployment but we should not
make that the only way of discovering them.

We don't have to do that here.