Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

From: Willem Toorop <[email-masked]>
Date: Tue, 18 Jul 2017 15:19:44 +0200

I support trying to come up with a standards solution for alias names at
the apex.  But....

The dependency on online signing is a little more then just a technical
issue.

Currently the zone owner, the holder of the domain name, is the one
having control over the zone content and as such also the one deciding
who may sign her zone.  She may choose to delegate this to a DNS
operator, or she may decide to sign the zone herself and let the DNS
operator serve the signed zone.

Currently all DNS Resource Records support the "offline" domain-name
holder signed zones mode of DNSSEC.  There is another provisioning
oriented resource record: DNAME.  For DNAME, it is described how
validators can verify that the followed referral matches. The same thing
should be done for ANAME.

It would be a new DNSSEC feature that need to be supported by the DNSSEC
validators.  There has been an earlier instance of the introduction of a
new DNSSEC feature: NSEC3.  The introduction of a DNSSEC compatible
ANAME should be done the same way as how NSEC3 was introduced: introduce
new algorithm numbers that indicate ANAME support.

We currently have 12 DNSSEC algorithms.  The introduction of a new
feature could list these same algorithm from number 17 up to 29, with
the indication that it supports the new DNSSEC features,  ANAME would be
one of them.  NSEC5 another maybe?

Op 27-05-17 om 23:36 schreef [email-masked]:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>         Title           : Address-specific DNS Name Redirection (ANAME)
>         Authors         : Evan Hunt
>                           Peter van Dijk
>                           Anthony Eden
> 	Filename        : draft-ietf-dnsop-aname-00.txt
> 	Pages           : 10
> 	Date            : 2017-05-27
> 
> Abstract:
>    This document defines the "ANAME" DNS RR type, to provide similar
>    functionality to CNAME, but only redirects type A and AAAA queries.
>    Unlike CNAME, an ANAME can coexist with other record types.  The
>    ANAME RR allows zone owners to redirect queries for apex domain names
>    in a standards compliant manner.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-aname-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Jul 2017 10:13:25 -0400

Dear colleagues,

I managed to delete instead of sending my note on this topic earlier
today, and my brain is sufficiently soft that I couldn't just re-type
it out.  Nevertheless,

> I support trying to come up with a standards solution for alias names at

I agree with this, and

> The dependency on online signing is a little more then just a technical

also this.  

> should be done for ANAME.

The problem is that DNAME has another feature that ANAME (and other
things like BNAME) can't: RFC 6672 gives the reasons why all
validators must also be able to cope with DNAME.  This was a fact (or
maybe accident) of history.  It is just not true of ANAME, and that
means that much of section 3 of the I-D is far too weak.  It needs to
say that, if you can't sign online, then you will break DNSSEC.

It is very strange for us to suggest this, but I think there are only
two options: either DNSSEC means we can never do any more aliasing, or
else we have to accept that some kinds of innovation in the DNS is
going to break DNSSEC sometimes, and allow zone operators to decide
whether they want to break validation (and therefore lose the
connections) or whether they want to serve everyone.

Alternatively, of course, we can follow the multiple-algorithm
approach that others have suggested.  This has the disadvantage of
bloating the DNSKEY RRset for anyone who wants to use these features,
of course, so it is also not free.

I'm also slightly concerned about this at the end of 3.3:

   The type bit map SHOULD only include address types which are known
   to exist at the <target>

Is the advice really to ask for both and then incorporate what is
known?  That seems maybe safer advice.

I also wonder whether the document would be easier to understand if it
were broken up into smaller chunks dealing separately with the
authorities, intermediates, and stubs.  It could be that nobody else
find these items too tangled in the current I-D, but if others do I
can propose text.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Jul 2017 17:09:00 +0100

> The dependency on online signing is a little more then just a technical

I need to review the draft properly, but I do not think ANAME should
require any online signing.

In my view an authoritative server which does online signing and on-demand
record synthesis is a master server. You can make all your public
authoritative servers into masters if you like, but it must not be
required.

If (like me) you have a more traditional setup then ANAME is an
instruction to the master server about zone maintenance, saying that it
needs to periodically update the sibling A and AAAA records, similar to
periodic re-signing, or as if some script were periodically `nsupdate`ing
the records. The secondary servers can continue to work the same as they
do now, but they'll work better if they know about some helpful additional
section rules for ANAME.

(That is basically how my bodged-up ANAME implementation works, in my
zone provisioning scripts.)

The other kind of DNS server that might be able to do something useful
with ANAME is a recursive server, so it could co-operate nicely with
authoritative servers that are playing clever tricks. But the rDNS will
have to be careful about not breaking downstream validators.

Say (for example) my zone has:

dotat.at.	ANAME	www.chiark.greenend.org.uk.
dotat.at.	RRSIG	ANAME
dotat.at.	A	212.13.197.229
dotat.at.	RRSIG	A
dotat.at.	AAAA	2001:ba8:1e3::
dotat.at.	RRSIG	AAAA

A client queries its resolver for dotat.at A, but chiark has renumbered,
so the client gets a response from the ANAME-aware resolver like below. A
validating ANAME-aware client can see it should use the additional address
212.13.197.231 in preference to the address in the answer.

; ANSWER
dotat.at.       A       212.13.197.229
dotat.at.	RRSIG	A

; ADDITIONAL
dotat.at.       AAAA    2001:ba8:1e3::
dotat.at.	RRSIG	AAAA
dotat.at.       ANAME   www.chiark.greenend.org.uk.
dotat.at.	RRSIG	ANAME
www.chiark.greenend.org.uk.	A	212.13.197.231
www.chiark.greenend.org.uk.	RRSIG	A
www.chiark.greenend.org.uk.	AAAA    2001:ba8:1e3::
www.chiark.greenend.org.uk.	RRSIG	AAAA

Note that neither the resolver nor the client needs any algorithm updates
to avoid being confused by this additional information; they just need a
code update so that they are able to make good use of it.

If the resolver knows the client is DNSSEC-oblivious then it can do the
substitution itself and return a simple answer like this:

dotat.at.	A	212.13.197.231

Validating but ANAME-oblivious resolvers won't get to enjoy clever
latency minimization tricks.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
East Sole, Lundy, Fastnet, Irish Sea: Easterly becoming cyclonic 4 or 5,
increasing 6 or 7 at times. Slight or moderate. Fair then thundery showers,
fog patches later. Moderate or good, occasionally very poor later.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Jul 2017 14:01:29 -0400

Hi,

> do now, but they'll work better if they know about some helpful additional

I think I (at least mostly) agree.  One possible way to sort out these
bits of potential confusion is to break the problem up into conceptual
parts, so that one can see the way that they work together.  One part
is, "How do you give this instruction to the master server(s)?"  It
covers representation in the master file format, what a master is
supposed to do on input, how to refresh the data, and so on.  A second
part is, "How do you give this instruction to a slave?".  This covers
transferring zones, the trade-offs in handing the slaves the ANAME vs
the "resolved" records, refresh timers and so on.  DNSSEC
considerations at least are split between these, which suggests to me
that these topics could be covered by one document in two parts; but
these are nevertheless separate and separable functional questions.

A third part has to do with downstream resolvers and caches and so on.
This is really a separate problem: how to handle ANAME-aware vs
ANAME-unaware systems, the consequences of an ANAME-unaware cache
ending up with an ANAME in the cache, the effects of having an A and
not AAAA in cache, &c &c.  A fourth part, which might be yet a
separate problem or might be the same document, is what this all looks
like from a stub and what happens when there are chains of forwarders
and caches and so on with a mix of ANAME-awareness and -obliviousness.

I still think that in addition a clear description of why this is hard
would be helpful.  The troublesome thing about Stupid DNS Tricks is
that they're always >80% there, and all the really hard parts are in
that last <20%, and the difficulties in those <20% cases are manifold
and completely unexpected when you think in the abstract cases.  The
people who worked through all the gnarly problems of caches and the
interaction with DNSSEC already went through this once (I came in at
the tail end and mercifully missed most of that), but we're about to
revisit those problems for a different set of questions.  I think we
need to understand why this is more complicated than it looks, and I
think any future implementer will need a clear guide to that also.

 ### WARNING: IETF ADMINISTRATIVE WRANGLING AHEAD ###

Since there's been talk about an interim, it strikes me that the
current issue is the sort of specific topic that deserves one.  But I
also wonder whether this isn't bumping up pretty hard against the
DNSOP charter, and whether this mightn't be a case where we put
together a tightly focussed statement of work that gets chartered as a
WG, with a plan never to meet (or to meet only as "part of" a DNSOP
meeting or something like that), if only to avoid pain and misery when
the documents describing all this go to IETF LC.  I am not interested
even a little bit in making more administrative overhead, but I'm very
much interested in avoiding a "this is off charter" discussion during
IETF LC should we get there.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Jul 2017 22:08:15 +0100

Andrew Sullivan <[email-masked]> wrote:
> supposed to do on input, how to refresh the data, and so on.

Yes.

> A second part is, "How do you give this instruction to a slave?".  This
> covers transferring zones, the trade-offs in handing the slaves the
> ANAME vs the "resolved" records, refresh timers and so on.

The only compatible option here is to transfer the signed resolved
records, and have the secondary behave the same as now, except for a small
amount of extra additional section processing. All dynamic behaviour has
to happen on a master.

If you think you have a secondary that's editing and/or resigning your
zone, what you actually have is a master which happens to use another DNS
server as its data source, rather than a zone file or database.

> ending up with an ANAME in the cache,

It should be just the same as any other new RR type.

> the effects of having an A and not AAAA in cache, &c &c.

It should be just the same as now.

> A fourth part, which might be yet a separate problem or might be the
> same document, is what this all looks like from a stub and what happens
> when there are chains of forwarders and caches and so on with a mix of
> ANAME-awareness and -obliviousness.

I think that if the transmission through the resolver forwarding chain is
done by putting extra records in the additional section, then it should be
self-healing. Downstream ANAME-aware resolvers can (if necessary) do extra
ANAME-related queries through an ANAME-oblivious upstream.

> would be helpful.

I think it can be made reasonably simple :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fisher, Northeast German Bight: Northwest veering east 4 or 5, decreasing 3
for a time. Slight or moderate. Fair. Moderate or good.

---

From: Willem Toorop <[email-masked]>
Date: Wed, 19 Jul 2017 11:49:35 +0200

> latency minimization tricks.

Yes!  This should be included in the aname draft.
Thanks,

-- Willem

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 19 Jul 2017 15:44:04 +0200

On Tue, Jul 18, 2017 at 05:09:00PM +0100,
 Tony Finch <[email-masked]> wrote 
 a message of 80 lines which said:

> A client queries its resolver for dotat.at A, but chiark has
> renumbered, so the client gets a response from the ANAME-aware
> resolver like below. A validating ANAME-aware client can see it
> should use the additional address 212.13.197.231 in preference to
> the address in the answer.

Cute trick. I love it. But it modifies the rules for response
credibility (the most credible response is in the additionnal section,
not in the answer section). Should we update RFC 2181, section 5.4.1?
I tend to think that the A record, in that example, should be treated
exactly like glue, by a ANAME-aware client.

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Jul 2017 15:41:27 +0100

Stephane Bortzmeyer <[email-masked]> wrote:
> Cute trick. I love it.

:-)

> But it modifies the rules for response credibility (the most credible
> response is in the additionnal section, not in the answer section).
> Should we update RFC 2181, section 5.4.1?> I tend to think that the A
> record, in that example, should be treated exactly like glue, by a
> ANAME-aware client.

Interesting point.

My understanding is that, in principle, DNSSEC makes it possible to trust
parts of answers that are (in current implementations) distrusted. For
example, out-of-zone data about CNAME or MX targets. There's a big
opportunity here to reduce latency by doing a bit more work to eagerly
validate and cache additional data.

(An aside: glue appears in multiple places in the RFC 2181 5.4.1 ranking,
depending on whether the server found it in an primary/secondary zone or
got it in a referral.)

Regarding my ANAME suggestion, the key paragraphs are shortly after the
trustworkthiness ranking:

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

The first word is the key word: "Unauthenticated" - the next paragraph says:

   When DNS security [RFC2065] is in use, and an authenticated reply has
   been received and verified, the data thus authenticated shall be
   considered more trustworthy than unauthenticated data of the same
   type.  Note that throughout this document, "authoritative" means a
   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
   records to determine the authenticity of data, the AA bit is almost
   irrelevant.  However DNSSEC aware servers must still correctly set
   the AA bit in responses to enable correct operation with servers that
   are not security aware (almost all currently).

With this context, I believe RFC 2181 says that if you have validated the
additional data from an answer like the one in my example
(https://mailarchive.ietf.org/arch/msg/dnsop/Zh7viwmrR7QcJSFQvqMsb7YSRU8)
you are allowed to return it as a direct answer to queries, and you don't
have to keep it in the additional section sin bin.

It's probably also sensible to retain its low trustworthiness ranking, so
that it can be replaced in the cache by a more trustworthy answer, to
reduce the risk of replay attacks that use old data that's still within
its RRSIG validity period.

On the other hand, it might be usefully simpler to make ANAME-specific
recommendations about how to handle the additional data. Dunno :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
East Sole, Lundy, Fastnet: Cyclonic 4 or 5, becoming northwesterly 5 to 7.
Moderate or rough. Showers, thundery at first, fog patches at first. Moderate
or very poor, becoming good.