Subject: [lamps] DNS DNAME pain.

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Nov 2017 11:06:34 -0500

I am trying to work out whether the restrictions in RFC6672 make use
of prefix records impossible.

Specifically, a DNAME is not allowed to have any records below it and
worse, section 2.4 states:

   "A server MAY refuse to load a zone that has data at a
   subdomain of a domain name owning a DNAME RR.  If the server does
   load the zone, those names below the DNAME RR will be occluded as
   described in RFC 2136 [RFC2136], Section 7.18."

This is called making things hard.

DNAME was originally developed to help manage reverse DNS during IP
address space renumbering, a problem we solved by abandoning the
reverse DNS. It is really not suited for the task it is used for (as
we have discovered when trying to use it for forward DNS,

What this means is that we can't have RRs like the following:

example.net DNAME example.com
_prefix.example.net CAA foo

It is not clear to me how the following is required to be interpreted:

example.net DNAME example.com
example.net CAA foo

The situation is of course very different depending on what forms of
DNS zone validation are performed in deployed systems and indeed
whether the restrictions on DNAME mean that it is either not used at
all or if the existing uses already violate parts of RFC6672.

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. That is currently a possibility because use of DNSSEC is
mostly limited to signing. The only folk verifying are folk who either
really know what they are doing or whose systems are always breaking
anyway. That window is likely to close at some point.

---

From: "John Levine" <[email-masked]>
Date: 9 Nov 2017 16:29:41 -0000

>we have discovered when trying to use it for forward DNS,

No argument there.

>_prefix.example.net CAA foo

Right.

>example.net DNAME example.com

DNAME only maps names below it, so the CAA is fine.

>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?

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Nov 2017 11:47:59 -0500

> 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.

> 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.

---

From: "John R Levine" <[email-masked]>
Date: 9 Nov 2017 11:53:40 -0500

> otherwise. I would like to check that the old behavior of not matching

It hasn't changed.  For a long time the .CAT domain made a poor attempt to 
map ASCII and accented versions of names using DNAME, and I found out all 
about DNAME+other stuff.

> tracking them directly. They seem to always be about to happen in a

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.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Nov 2017 12:49:31 -0500

On Thu, Nov 9, 2017 at 11:53 AM, John R Levine <[email-masked]> 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 is something I have been building for my own use. When a Docker
container pops up, it should register itself in the DNS as one of the
handlers for that service. When it dies, it should be unregistered.

---

From: "John R Levine" <[email-masked]>
Date: 9 Nov 2017 13:18:42 -0500

> 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.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Nov 2017 13:46:36 -0500

On Thu, Nov 9, 2017 at 1:18 PM, John R Levine <[email-masked]> wrote:
>>> to
>>> more
> 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.