Re: [lamps] DNS DNAME pain.

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 09 November 2017 18:46 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5884412944B for <spasm@ietfa.amsl.com>; Thu, 9 Nov 2017 10:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wmmaw4Bh3yjw for <spasm@ietfa.amsl.com>; Thu, 9 Nov 2017 10:46:38 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF98F1294A4 for <spasm@ietf.org>; Thu, 9 Nov 2017 10:46:37 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id s88so6172884ota.4 for <spasm@ietf.org>; Thu, 09 Nov 2017 10:46:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yDrXETctKfYqvMvppLxFeBXrEIoYubqw/6ZaMjebS/E=; b=dESe/tOpt3U5Xua2b0uNp0OYI5vK6AcKoydIk6YYks08O7gDx/nASfHr+FfGwMU5VR Uo9bp0GwQ6gqPk/2/t7XT6d+DlkZx+Jaywb2NuqdRTmGOMHO4JU9/jXLwYkiPg+biOrl 9j6B7OnhoaS06UmiYhf3gPso+geR1VIk/altJu3tWbl3ImomdADxLN8hbHwYbAsaEY1t DPjoRvAtZr/72XeajI+EKKgCUG0bO1imi4clyRifkB9mpH2EmR6D1pWx5pacQbZyQaRH jUB7UdybaCcw5bK3piaE4JZIOw+4w5ezEMLkMKenrNgXHjUcZL6T2JI5sJoCLPtobs35 2ASQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yDrXETctKfYqvMvppLxFeBXrEIoYubqw/6ZaMjebS/E=; b=pmO/vMDL9MDYSz+FQZVvLYqous/Un5CANAiBoKBpDwJ1xf8UDIMgsmh2NeSASqMOEo 7262lMlsCjCosZTCTbNpCks/wkdzRKV/Bi608NpbLAZheoJa5xCmI4hl9PNwjT8A4bWd jYw7EgeGqQQ5YbNgS25lg1UqneYx7zT+8j5igUCDUp5JZ646JygjLtaCc6y39a3OJAeH v26n5DLH4iZrQzTue4sxHBEjcdN6crUvTK6fbYPJURj1AAxGdL1kifZlm4jdndGW753l QGeBPQjevtmYREhbGQy4H50U5j+Ky9r9G9u1GRzRE+OlZc+oe6kv96YdVSnSxJWhZRIO doTQ==
X-Gm-Message-State: AJaThX4EcVQwSHIs70gXb5tuXROIQitk5NBO/GpbaVBvcFNrOxsxLMxc SNPMHSct99q4u1lf4apZSJjYDAZkkncpQzABHfk=
X-Google-Smtp-Source: AGs4zMaSXtzSiHUssJT4gDOgVO25pM8FnVGulVCFuDFbCxN+Hw701JpZrVGTZ+bfl9/rrI41eLTj6ptDGhpDbPCt9P8=
X-Received: by 10.157.61.226 with SMTP id l89mr961978otc.269.1510253197140; Thu, 09 Nov 2017 10:46:37 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.42.230 with HTTP; Thu, 9 Nov 2017 10:46:36 -0800 (PST)
In-Reply-To: <alpine.OSX.2.21.1711091315590.3847@ary.qy>
References: <CAMm+LwgMkSq7xVhVe_tYs7t46qmB9iVs92_SM3MOMeFCqWinbA@mail.gmail.com> <20171109162941.3670.qmail@ary.lan> <CAMm+LwhVPymZ3-3fmMY1onOFykfcVfy8rGxSPGB0FAddt2WTiQ@mail.gmail.com> <alpine.OSX.2.21.1711091150580.3682@ary.qy> <CAMm+Lwg4_0TS4b9DNV1K6OM7+26mYNCx9f2F=cMcQTJ8Ag7MsA@mail.gmail.com> <alpine.OSX.2.21.1711091315590.3847@ary.qy>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 9 Nov 2017 13:46:36 -0500
X-Google-Sender-Auth: 6JZLmkcUslP_nCq_E3FxBVK3A58
Message-ID: <CAMm+LwguSmESTieBYDYc4jDhD7S11W5ip1WsQtuLesDdZDg+Sw@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Cc: SPASM <spasm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/VigT2cUaptQXrL9klxXjrH74tGA>
Subject: Re: [lamps] DNS DNAME pain.
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2017 18:46:39 -0000

On Thu, Nov 9, 2017 at 1:18 PM, John R Levine <johnl@taugh.com> wrote:
>>> BNAME is going nowhere because it doesn't solve the problem it's supposed
>>> to
>>> solve, mapping variant names together.  If you want, say, a pair of
>>> traditional and simplified Chinese names to act the same, you have far
>>> more
>>> work provisioning web and mail servers than the DNS.
>>
>>
>> Like many other DNS proposals, the only way that can work is if the
>> services are getting their configuration data from the same source of
>> truth as the authoritative DNS server
>
>
> That helps, but the meaning of "the same" when applied to web servers is
> pretty vague.  If you have names in different character sets or different
> languages, should the web content match the character set or language of the
> name you use?  It's a swamp.

That is not what I am talking about.

I am talking about the source of truth for the machine configuration
being something like this [Note this is nothing to do with DNS configs
or aliases]

Global service file:

MyCompany Domain
    Canonical canonicalsite.com
    Alias: mysite.com
    Alias: xn--anothersite.com


I start a mail server container and tell it to register to service
MyCompany. It connects to the provisioning service

Host:
    "I support SMTP, POP3 and IMAP for MyCompany "
Provisioning to Host:
    "Your names are  canonicalsite.com, mysite.com, xn--anothersite.com"
    "Your priority is 10, you are 1 of 1 services"
Host:
    "Service is online and waiting"
Provisioning to DNS:
    <set of RRs for the config>
Provisioning to Host:
    "You are online"
Host:
    "CPU at 90%"

At this point the provisioning service can bring up another host to
service that domain.

The Web/mail/whatever service knows exactly what is being said on its
behalf and can react accordingly


In this model, DNS administration is strictly an output of the
provisioning service. It is not a thing in its own right. DNS records
can now be produced for whatever information clients might require
BEFORE they connect to the service.

This is the only model in which I see features like DANE or encryption
of the initial TLS negotiation being practical because it is the only
model in which the DNS information is likely to be useful.

Any system that relies on Bob to configure two separate systems
without inconsistency is broken. Bob will get them in sync the first
time at best. Then a change to the config will be made to one and not
the other.