Subject: [DNSOP] Minimum viable ANAME

From: Tony Finch <[email-masked]>
Date: Wed, 19 Sep 2018 14:55:45 +0100

I think there's still a need to standardize ANAME, to provide at least
some level of zone file portability between the various existing
proprietary versions of this feature. And to provide something usable
by zone publisters on a much shorter timescale than a nsa SRV-alike.

So here's a sketch of a reduced ANAME:

Primary servers / zone provisioning
-----------------------------------

For each ANAME record, poll the target address records periodically
(according to the relevant TTLs). When the target addresses don't
match the owner's addresses, UPDATE the zone so they match.

Authoritative servers / zone transfers
--------------------------------------

No special new behaviour.

Additional section processing
-----------------------------

This applies to auth and rec servers. In response to an A / AAAA /
ANAME query, include any sibling A / AAAA / ANAME records, and any
ANAME target A / AAAA records. When DO=1, include DNSSEC proofs of
nonexistence for missing RRsets.

As usual for additional section processing, you don't have to include
records that aren't available, so (for instance) auth servers don't
have to include out-of-zone data in the response.

Recursive servers
-----------------

When responding to a query with DO=0 or when the ANAME owner's zone is
unsigned, a recursive server can substitute the target addresses in
place of the owner's addresses.

Rationale
---------

The primary server behaviour is an "as if" description: that's what
it looks like for the purpose of interop with secondary servers and
zone files.

There doesn't seem to be any point in making secondary servers do
anything: their view of the target address records will be just as
wrong or right as the primary server's. Zone publishers that want
clever auth servers will use some kind of multi-headed CDN distributed
stunt DNS server, and we aren't going to standardize that.

Putting cleverness in resolvers compensates for the lack of cleverness
in secondary servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides: Cyclonic 5 to 7 becoming west or southwest 7 to severe gale 9. Rough
or very rough becoming very rough or high. Showers. Good, occasionally poor.

---

From: Anthony Eden <[email-masked]>
Date: Wed, 19 Sep 2018 10:02:07 -0400

FWIW, there's still always
https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/  (also
available at https://github.com/aeden/alias-rr-type) which can be revived
if there is interest.

Sincerely,
Anthony Eden

On Wed, Sep 19, 2018 at 9:56 AM Tony Finch <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Sep 2018 15:25:45 +0100

Anthony Eden <anthony.eden=[email-masked]> wrote:

> https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/

I get the impression that a lot of the objection to the current ANAME
draft is that it specifies that auth servers do ANAME target lookups and
record substitution; your draft says the same thing. I think those
objections are reasonable, but I don't think the problem lookups are
particularly important (or even helpful).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest Fitzroy: Southwesterly 5 to 7, occasionally gale 8 in far northwest.
Moderate or rough, occasionally very rough in far northwest. Rain. Good,
occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2018 07:41:38 -0700

Tony Finch wrote:
> Anthony Eden<anthony.eden=[email-masked]>  wrote:
>

+1.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Sep 2018 07:41:38 -0700

+1.

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Sep 2018 12:38:08 -0400 (EDT)

>>  particularly important (or even helpful).

4.  Security Considerations

    To function properly with DNSSEC-aware resolvers, authoritative name
    servers MUST sign the materialized records produced by the ALIAS
    resolution.

    Implementors MAY either materialize A and AAAA records offline and
    sign the resulting records at that time, or sign the resulting
    materialized records at request time.

This is not a proper Security Consideration section. Please see https://tools.ietf.org/html/rfc3552
What is described here is a fundamental flaw in this proposal.

That fact is even more clear by the MAY in that section, which basically
says "you can address this security issue or not, whatever"

A mechanism could be designed that is more generally usable.

Forcing a authoritative servers to do DNS lookups is asking for trouble.
Some deployments combine auth+recursive and such a server now needs a
working resolv.conf, and one that cannot point to itself. Clearly this
is going to break stuff. We have known for decades that combining
authoritative plus recursive was a bad idea, yet here it is again
glueing these two parts together so the auth server needs resolving
code. The place to do anything is on the resolver, the authoritative
server should just serve blobs.

Synthesizing (here called "materialising" ?) records is awful. It does
not work with offline DNSSEC signers, and if we want to solve this
properly, we can do so easilly with a solution that does not have
this limitation.

The design goals of a solution in this space should be:

- Fully supports DNSSEC
- Does not require AUTH server changes other then supporting a new
   RRTYPE presentation / wire format and/or serving a new RRTYPE as
   Additional Data.
- All optimization work is done on the resolver. If this includes
   'rewriting' A/AAAA records, DNSSEC proofs MUST be included for
   stub clients doing validation.

for example, why not serve an ALIAS record as additional data to A/AAAA
queries? Then resolvers that dont support this are as bad of as now.
Resolvers supporting this, will pick up the ALIAS, resolve it, put those
A/AAAA records in cache, and serve any clients asking for these A/AAAA
with the A/AAAA, ALIAS and target A/AAAA records.

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Sep 2018 17:51:49 +0100

>   stub clients doing validation.

My suggestion does all of that.
https://www.ietf.org/mail-archive/web/dnsop/current/msg24206.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger, Fisher: Southwest 6 to gale 8, occasionally severe gale 9 at
first, decreasing 4 or 5 later. Rough or very rough, becoming high for a time
in northwest Fisher, becoming slight or moderate in Tyne and Dogger. Rain or
showers. Good, occasionally poor.

---

From: "John Levine" <[email-masked]>
Date: 19 Sep 2018 16:14:01 -0400

>Authoritative servers / zone transfers

If I look up foo and it has an ANAME to bar, which of these do I get
back?

foo. ANAME bar.
foo. A 1.2.3.4

foo. ANAME bar.
bar. A 1.2.3.4

The second is a lot more like what CNAME does, and also avoids having
to sign on the fly.  There is of course the question of whether caches
and stubs will treat them like cname results or like cache poisoning.

R's,
John

PS: I still think fixing apex CNAME is a better way to go.

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Sep 2018 22:08:45 +0100

> On 19 Sep 2018, at 21:14, John Levine <[email-masked]> wrote:

> If I look up foo and it has an ANAME to bar, which of these do I get

; ANSWER SECTION
foo. A 1.2.3.4

; ADDITIONAL SECTION
foo. ANAME bar.
bar. A 1.2.3.4

The model is that this is a replacement for manually copying address records, with added hints to resolvers that they might want to re-do the copying in order to get geo-optimized answers or other complicated tricks.

> to sign on the fly.

With this model, signing only happens where it currently happens. 

> PS: I still think fixing apex CNAME is a better way to go.

There are still DNS servers out there running on 1990s semantics, so I don’t think CNAME can be fixed any time soon - much of my practical annoyance comes from people asking for CNAME and MX and this combination is doom on a stick because it involves crazy MTA DNS message handlers, not just DNS servers. My guess at deployment timelines is:

* minimal ANAME can be deployed unilaterally on the provisioning side 20 years ago and similar features are widely available (you are ahead of me on this one, John!); if resolvers implement it there will be useful amounts of deployed support within a few years

* browser-friendly SRV replacement: two years to standardization; another two years watching caniuse before we can maybe think about not copying A records around; even more years before it becomes as portable on the provisioning side as ANAME is now

* fix CNAME, at least 10 years

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Sep 2018 19:27:33 -0400 (EDT)

> The model is that this is a replacement for manually copying address records, with added hints to resolvers that they might want to re-do the copying in order to get geo-optimized answers or other…

Exactly. And some dns server addonn can go look through the zone files
and find ANAME records, and do the query/updating via a cron job and
reload or something.

This is a simle solution that works.

> With this model, signing only happens where it currently happens.

Good. Although if you want to return bar's IP if it is different from
foo's IP and for resolvers that don't understand ANAME, you have to
synthesize these, but at least then it is nor worse then DNS64 with
respect to DNSSEC.

> There are still DNS servers out there running on 1990s semantics, so I don’t think CNAME can be fixed any time soon - much of my practical annoyance comes from people asking for CNAME and MX and th…

I agree, CNAME is tainted.

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 20 Sep 2018 11:43:43 +0530

Hi Tony

On Wed, Sep 19, 2018 at 10:08:45PM +0100, Tony Finch wrote:
> * minimal ANAME can be deployed unilaterally on the provisioning side
> * 20 years ago and similar features are widely available (you are
> * ahead of me on this one, John!); if resolvers implement it there
> * will be useful amounts of deployed support within a few years
> 
> * browser-friendly SRV replacement: two years to standardization;
> * another two years watching caniuse before we can maybe think about
> * not copying A records around; even more years before it becomes as
> * portable on the provisioning side as ANAME is now
> 

All these have similar adoption rate risks. Mark has a point that it's
more difficult to check for the last one.

There are orders of magnitude fewer resolver instances to upgrade than
HTTP user agents (popular web browsers aren't the only HTTP clients).

I don't follow how ANAME, if resolvers have to implement it, can be
deployed within a few years, and fixing CNAME takes at least 10 years.
They both involve resolver changes.

SRV is most elegant. IMO we should push the resolver-side CNAME handling
change through so one day in the future it is available widely.

		Mukund

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Sep 2018 10:16:12 +0100

> On 20 Sep 2018, at 07:13, Mukund Sivaraman <[email-masked]> wrote:
> 
> deployed within a few years, 

Resolvers don’t “have to”  implement it: resolver support is just an optimisation that helps when the target is on a CDN. ANAME is mostly just a provisioning side hack to automatically keep address records up-to-date, so it can be deployed unilaterally and it will “just work” with existing software.

The other options we have been discussing require a forklift upgrade before they can be relied on, and until that is complete they offer no advantage to zone publishers.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Sep 2018 14:08:19 +0100

> synthesize these, but at least then it is nor worse then DNS64 with

Who is "you" in this sentence?

If you are a secondary authoritative server, then you're almost certainly
oblivious to the target address records, but even if you do know them, you
aren't able to substitute them because the ANAME's zone is probably signed
and you don't have the keys.

If you are a recursive server, you can substitute if DO=0 or if the
ANAME's zone is unsigned. It would be nice if clients that make DO=1
queries also know about ANAME so they can substitute if required, but that
isn't necessary for correctness.

ANAME is much less bad than DNS64 because DNS64 requires knowledge about
the prefix used for tunneling, whereas ANAME substition doesn't need any
information beyond the additional section of the response you just got.
And ANAME substitution isn't necessary for in the way DNS64 is, i.e.
connectivity works if you don't substitute ANAME sibling address records,
but it doesn't if you lose DNS64 substitution.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
no one shall be enslaved by poverty, ignorance, or conformity

---

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Sep 2018 11:08:48 -0700

At Wed, 19 Sep 2018 14:55:45 +0100,

> Primary servers / zone provisioning

I'm not sure how we can expect this model to deploy in practice.  With
this model, the zone admin will need to develop an additional script
or something integrated into whatever the provisioning framework they
are using.  Is that the assumption?

Then I suspect none of existing users of proprietary and
non-standard-compliant "ALIAS" will switch to it simply because it's
standard compliant.  And that will be also the case for those who now
want to start "aliasing at a zone apex".

Perhaps primary server implementations may eventually have some level
of support that makes this provisioning much less painful (in a way
other than performing on-demand resolution).  If and when many popular
implementations do it in a convenient way (at least as convenient as
the proprietary alternatives), we may hope the new model with ANAME
optimization will start to deploy, eventually with wider deployment of
the optimization part as more resolvers support it.  Perhaps that's
the intended deployment plan?  If so, I see some possibility there,
but I have to say I'm pessimistic about its reality.

--
JINMEI, Tatuya

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Sep 2018 12:03:13 +0100

> are using.  Is that the assumption?

I would like it to be integrated into the DNS server, like automatic
DNSSEC signing. But you can implement it as a bag on the side and lots of
places have already done that. (I have a half-arsed implementation which I
desperately want to replace with something better.)

> the optimization part as more resolvers support it.

It doesn't have to be sequential like that: the additional section
processing on auth and rec servers, and resolver ANAME optimization won't
cause any interop problems, so they can be deployed whenever the code is
ready and they'll have a useful effect when they encounter an ANAME
record.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey: Northwest 5 to 7, occasionally gale 8 except
in Rockall, decreasing 4 later. Rough or very rough, becoming moderate or
rough except in Bailey. Showers. Moderate or good.

---

From: Dan York <[email-masked]>
Date: Fri, 21 Sep 2018 13:12:16 +0000

On Sep 20, 2018, at 2:13 AM, Mukund Sivaraman <[email-masked]<mailto:[email-masked]>> wrote:

+1

I do think this is a path we need to go.  We need *something* like CNAME at the apex.  Either CNAME itself or something that works in the same way but might have a different name.

Otherwise, those of us out there publishing sites using CDNs but wanting to use an apex domain name are stuck using whatever proprietary options DNS operator X is offering us… which will be different from DNS operators Y and Z.  This locks us in to a specific DNS operator.  (Who may or may not also be the CDN operator.)

Given the long deployment timeline, I do think we need to start on this sooner.  I’m glad to help.

My 2 cents,
Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 21 Sep 2018 10:55:01 -0400

On 21 September 2018 at 09:12, Dan York <[email-masked]> wrote:

>
> I do think this is a path we need to go.  We need *something* like CNAME
> at the apex.  Either CNAME itself or something that works in the same way
> but might have a different name.
>

I would still like to see something SRV-like for HTTP, but I realize that's
going to be a long slog .. getting the HTTP folks on board, and getting it
defined and deployed.  I don't see any value in pursuing re-defining CNAME,
because the install-base prevents that from being useful to anyone until a
significant number of recursive resolvers are updated. So.. I think ANAME
is the short term solution we need.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 21 Sep 2018 09:52:48 -0700

At Fri, 21 Sep 2018 12:03:13 +0100,

> ready and they'll have a useful effect when they encounter an ANAME

It's true that "they (= additional section processing) can be deployed
whenever the code is ready".  But if I were a primary side admin who
wants to use an ALIAS-like feature, that wouldn't mean much
unless/until
A. the provisioning support in the primary server implementation is
   really convenient in terms of my operational costs, or
B. a significantly large number of resolvers support the additional
   section processing for ANAME

In my understanding of the discussion we all agree that it will take a
very long time until we have B.  So, in the end, the deployability
seems to depend on how soon we can have situation A and how convenient
the implementations are.  It may actually come quite soon and may
really become very popular.  I don't deny that possibility; I'm just
not personally so optimistic about it.

--
JINMEI, Tatuya

---

From: JW <[email-masked]>
Date: Fri, 21 Sep 2018 14:11:35 -0400

-------- Original message --------From: 神明達哉 <[email-masked]>
> In my understanding of the discussion we all agree that it will take a> very long time until we have B.  So, in the end, the deployability
> seems to depend on how soon we can have situation A and how convenient> the implementations are.  It may actually come quite soon and may
I also feel from this discussion, we are all roughly on the same page.  We want SRV as the long term solution and something else CNAME-like for short term.
What are the next steps? 
Should we better define what we are solving and develop a problem-statement document?  This may help narrow down the scope of the short term and allow for the long term to be formalized.
/John

---

From: Ray Bellis <[email-masked]>
Date: Sun, 23 Sep 2018 15:40:54 +0100

On 21/09/2018 19:11, JW wrote:

> I also feel from this discussion, we are all roughly on the same page. 
> We want SRV as the long term solution ...

except that we heard at the side meeting in Montreal (albeit from
browser people rather than content people) that they *don't* want SRV,
because it has fields that are not compatible with the web security model.

I still want to define a new RR that does have mutually agreed semantics
that's specifically for use by HTTP(s), but so far no takers.

Ray

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 27 Sep 2018 11:28:00 +0200 (CEST)

>> If I look up foo and it has an ANAME to bar, which of these do I get

Who provides the DNSSEC proof for this record?  AIUI, there is no
A 1.2.3.4 in the "foo." zone originally, but there is an ANAME.
How, then, does this avoid DNSSEC-signing-on-the-fly (which may
be impossible)?

> bar. A 1.2.3.4

These two can of course easily be DNSSEC-signed, using the
traditional model, as all this data would be "where it belongs".

Regards,

- Håvard

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Sep 2018 11:34:20 +0100

Havard Eidnes <[email-masked]> wrote:

> Who provides the DNSSEC proof for this record?

The zone of the owner of the ANAME: the ANAME sibling address records are
inserted into the zone as if by an UPDATE.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: West veering northwest, 5 to 7, occasionally gale 8 in
Fisher. Moderate or rough, occasionally very rough in Fisher. Drizzle, then
showers. Good, occasionally moderate.

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 27 Sep 2018 13:27:26 +0200 (CEST)

>> I also feel from this discussion, we are all roughly on the same
>> page.  We want SRV as the long term solution ...
>
> browser people rather than content people) that they *don't* want
> SRV, because it has fields that are not compatible with the web
> security model.

Can you summarize the particulars of the web security model (I'm not
sufficiently well versed in that area to immediately key off that
phrase) which makes use of SRV non-attractive?  Is the aspect that a
URL can contain a port number part of the problem, or is it
something (a lot?) more involved?

When defining the use of SRV for the web protocols (something which
remains to be done), one could of course standardize "ignore the
port number in the SRV record, use the port number from the URL, or
whatever http and https defaults to", especially if that makes the
problem go away.

> I still want to define a new RR that does have mutually agreed
> semantics that's specifically for use by HTTP(s), but so far no
> takers.

SRV is widely supported today in provisioning frontends, name
servers and resolvers.  Defining a new RR which is SRV-like is going
to seriously prolong the "time to useful deployment".

Regards,

- Håvard