Subject: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

From: Evan Hunt <[email-masked]>
Date: Fri, 7 Apr 2017 18:11:39 +0000

Greetings,

Here's the new ANAME draft I mentioned last week.

This is similar to existing non-standard approaches (ALIAS records,
CNAME-flattening, etc) but also sends the ANAME record to the resolver so
that, if the resolver understands the ANAME type, it can re-query for the
answer just as it would with a CNAME.

Please have at it.

----- Forwarded message from [email-masked] -----

From: [email-masked]
To: Evan Hunt <[email-masked]>, Peter van Dijk <[email-masked]>,
	Anthony Eden <[email-masked]>
Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt
Date: Fri, 07 Apr 2017 11:04:39 -0700

A new version of I-D, draft-hunt-dnsop-aname-00.txt
has been successfully submitted by Evan Hunt and posted to the
IETF repository.

Name:		draft-hunt-dnsop-aname
Revision:	00
Title:		Address-specific DNS Name Redirection (ANAME)
Document date:	2017-04-07
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-hunt-dnsop-aname-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/
Htmlized:       https://tools.ietf.org/html/draft-hunt-dnsop-aname-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hunt-dnsop-aname-00

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.

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.

The IETF Secretariat

----- End forwarded message -----

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Job Snijders <[email-masked]>
Date: Fri, 7 Apr 2017 20:24:19 +0200

Dear Evan & Authors,

Can you add a RFC 7942 section to this document?

Pending an IANA Early Allocation, I expect these implementations to be
residing in private / beta branches until a DNS RR data type value has
been assigned.

I think it will be beneficial for the working group dialogue to have an
overview of running code.

Kind regards,

Job

On Fri, Apr 07, 2017 at 06:11:39PM +0000, Evan Hunt wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 07 Apr 2017 20:54:29 +0200

Hi Job,

> Can you add a RFC 7942 section to this document?

Absolutely, we’ll do that in -01.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Apr 2017 17:16:14 -0400 (EDT)

> Here's the new ANAME draft I mentioned last week.

I like this one a little better, but :)

    When an ANAME record is present at a DNS node and a query is received
    by an authoritative server for type A or AAAA, the authoritative
    server returns the ANAME RR in the answer section.

This is good, then it goes on with:

    Because not all querying resolvers understand ANAME, the
    authoritative server MUST also return address records, as described
    below.

    [...]

    Authoritative servers implementing ANAME MUST be equipped to resolve
    the ANAME <target> on the querying resolver's behalf, either by
    sending queries to an external recursive resolver or by implementing
    recursive resolution logic internally, so that address records can be
    expanded when the ANAME <target> is in a separate zone from <owner>.

I guess I'm still not a fan of the AUTH server doing this. Moreover:

    When a recursive resolver sends a query of type A or AAAA and
    receives a response with an ANAME RRset in the answer section, it
    MUST re-query for the ANAME <target>.  This is necessary because, in
    some cases, the address received will be dependent on network
    topology and other considerations, and the resolver may find a
    different answer than the authoritative server did.

That opens up a whole can of worms :P We start with the problem of
"we need addresses at the APEX be non-static, but then you add logic
to support that and then it is not good enough for the job. AUTH servers
already know how to return split view answers with various
implementations based on geolocation, edns-subnet or what not.

Also, a resolver support ANAME sending a query to a forwarding resolver
might only receive the ANAME record back without anything else, and then
has to do all the ANAME chasing itself anyway. So why not just always
do that behaviour? So why not happy eyeball ANAME along with A/AAAA
queries. Old stuff gets somewhat risky and possibly outdated A/AAAA
records, and newer clients get the proper redirection.

But really, what it comes down to for me is that if you are adding logic
to the AUTH nameservers to synthesize ANAME into A/AAAA records, why bother
ever sending ANAME over the wire? Just let clients send A/AAAA and never
ask for ANAME. And have the AUTH server code that sees an ANAME in the
zone at the place of the QNAME for A/AAAA synthesize by doing the
queries.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Fri, 7 Apr 2017 22:47:16 +0000

Hi Paul,

> implementations based on geolocation, edns-subnet or what not.

The hope here is that, in the long run, ANAME resolution would be the job
of the resolver, which in in a position to get the best answer for its
clients, given geolocation and topology considerations.

Expansion of ANAME on the authoritative end is a workaround for the
fact that we can't go back in time and put ANAME support into all
the resolvers.

> ask for ANAME.

Resolvers don't ask for ANAME. They ask for A/AAAA, and get an A/AAAA
answer, along with an ANAME record so they can go directly to the source
and get a better answer if they support that.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 8 Apr 2017 18:32:12 -0400 (EDT)

> and get a better answer if they support that.

If these are the premises for ANAME, and its special handling, wouldn't
it be better to generalise asking for multiple records (eg A + AAAA
+ ANAME) where ANAME has no special handling on its own? And then do the
generealised multi-query-at-once using one of the previously suggested
proposals?

I thought there were some recent suggested drafts, which I cannot seem
to find now, but an old one on this is draft-yao-dnsop-accompanying-questions.

Then people who want to ask (A + AAAA + TLSA) or (A+AAAA+SSHFP) or
(A+AAAA+IPSECKEY) could use the same mechanism. And ANAME would just be
a regular DNS record without any abnormal processing.

Paul

---

From: "John Levine" <[email-masked]>
Date: 8 Apr 2017 22:41:16 -0000

>generealised multi-query-at-once using one of the previously suggested

But that doesn't solve the original problem.  Clients ask for an A or
an AAAA record, and that's what they want to get back.  The ANAME is
really just a provisioning hack built into the authoritative server
and, depending on the implementation, maybe the cache.

I suppose they might ask for both A and AAAA but that's a separate
problem, even though it might use a similar mechanism.

R's,
John

---

From: Richard Gibson <[email-masked]>
Date: Sat, 8 Apr 2017 21:38:29 -0400

I'm happy to see progress being made on this front. Some comments:

*Section 3.1*

This section calls for limiting the TTL of cached address records to the
lesser of the ANAME TTL and the TTL of the retrieved address records, but
section 3 requires servers to follow chained responses. Are the TTLs of
intermediate records in a chain supposed to be ignored?

What is the expected behavior when the target record set is empty, or
bogus, or when resolution fails?

*Section 3.2*

The wording of this section could use some improvement. It seems to
prohibit secondary servers from resolving ANAME targets when they are
present at the same domain as address types... do I understand correctly?
Are such address records still subject to TTL decrementing (presumably
starting at the time of zone transfer)? And when only a single address type
is present (e.g., just ANAME and A), does that still prevent resolution of
the ANAME target for the other type?

*Section 3.3*

Although labeled "DNSSEC signing", this section also contains more general
specification (e.g., "the master server MUST respect the TTLs of the
address records" and "TTLs [of address records in a secondary server] will
count down").

It is also mute on the use of DNSSEC for resolving ANAME target records,
but that should probably be covered somewhere.

On Fri, Apr 7, 2017 at 2:11 PM, Evan Hunt <[email-masked]> wrote:

> To: Evan Hunt <[email-masked]>, Peter van Dijk <[email-masked]
> >,

---

From: "Peter van Dijk" <[email-masked]>
Date: Sun, 09 Apr 2017 21:56:27 +0200

Hello Richard,

> I'm happy to see progress being made on this front. Some comments:

Thank you for taking the time for this.

> bogus, or when resolution fails?

Empty becomes empty. The common case will be ‘the ANAME target only 
has A, no AAAA’ which means the AAAA lookup encounters a valid ‘no 
data’.

If resolution fails (i.e. runs into an actual SERVFAIL-like error 
condition, including ‘bogus’), we should also SERVFAIL. If the draft 
is unclear on this we should definitely fix that.

> present at the same domain as address types... do I understand 

Yes, that is correct. We went through a few iterations and thought 
exercises and this seemed like the optimal behaviour.

> the ANAME target for the other type?

(1) Yes, they are still subject to TTL decrementing, but if the slave is 
not ANAME-aware, no decrementing will happen and the draft allows this, 
if we wrote it all down correctly.
(2) Yes, when any address records are present, the ANAME is deemed to 
have already been expanded. If A is there and no AAAA, then this means 
that there is in fact no AAAA to be had.

> address records" and "TTLs [of address records in a secondary server] 

Then the section is misnamed or those specifications should be moved. I 
will look at that.

> but that should probably be covered somewhere.

This is an interesting topic actually. There are existing deployments of 
PowerDNS ALIAS (which of course is quite similar to ANAME) that use it 
instead of ‘CNAME to unsigned’ so they can sign the target addresses 
(that they get via a non-DNSSEC but still secure path). This draft 
should also allow that. If you have suggestions for a section on ANAME 
target resolving and DNSSEC, please let us know.

Kind regards,

---

From: Richard Gibson <[email-masked]>
Date: Sun, 9 Apr 2017 19:04:05 -0400

> Thank you for taking the time for this.

My pleasure; this topic has frequently been on my mind over the past
several years. Thank you for drafting it.

*Section 3.1*
>> intermediate records in a chain supposed to be ignored?
What was the response on this point?

> Empty becomes empty. The common case will be ‘the ANAME target only has A,
> no AAAA’ which means the AAAA lookup encounters a valid ‘no data’.

> condition, including ‘bogus’), we should also SERVFAIL. If the draft is
> unclear on this we should definitely fix that.
>

Right; I definitely think there should be text explicitly defining behavior
for timeouts, nonzero RCODEs, and bogus responses received when looking up
ANAME targets. Section 4 covers part of it (for recursive servers only),
but doesn't define how to determine when "resolution fails" or what to do
when not opting to use the accompanying records as a fallback, and there is
no guidance at all for authoritative servers.

*Section 3.2*
> exercises and this seemed like the optimal behaviour.

Dyn went another way with our ALIAS functionality, reserving same-domain
address record sets for fallback data to be used whenever target resolution
doesn't yield records of the appropriate type (including, perhaps
controversially, NXDOMAIN and NODATA empty responses). Assuming a secondary
server predating ANAME, the Dyn behavior would be slightly better when the
primary server is ignorant of that gap (i.e., the secondary would always
serve fallback data) and identical behavior when it is not (i.e., the
authoritative would pre-expand as the draft specifies in Section 5). It
also provides support for multi-type host names with single-type targets,
e.g. static AAAA records sharing a domain with an ALIAS targeting a name
providing only A records. Where it really shines, though, is in handling
error cases like those discussed above—it was very important to our
customers that they could prevent us from ever issuing cacheable negative
responses. What thought exercises took you in this direction?

> not ANAME-aware, no decrementing will happen and the draft allows this, if
> we wrote it all down correctly.
> (2) Yes, when any address records are present, the ANAME is deemed to have
> already been expanded. If A is there and no AAAA, then this means that
> there is in fact no AAAA to be had.
>

I understand the motivation, but there's an interesting wrinkle with
respect to forward compatibility... what happens when a new address type is
added to the DNS? The assumption that pre-expansion of any address type
implies pre-expansion of all address types seems like it could lead to some
dramatic changes in behavior as primary servers, secondary servers,
resolvers, and targeted zones become aware of the new type in a nonuniform
fashion. Has any consideration been given to that concern?

On a related note, should recursive resolvers query for ANAME targets even
when they *don't* correspond to A or AAAA QTYPEs?

> instead of ‘CNAME to unsigned’ so they can sign the target addresses (that
> they get via a non-DNSSEC but still secure path). This draft should also
> allow that. If you have suggestions for a section on ANAME target resolving
> and DNSSEC, please let us know.

Addressing the above points to explicitly define behavior for bogus
responses will cover the functional requirements, so this will likely take
the form of MAY or SHOULD guidance for using DNSSEC when resolving ANAME
targets.

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 10 Apr 2017 10:34:23 +0200

> What was the response on this point?

Oh, right. I suppose the right answer would be to take the lowest of all 
involved TTLs.

> no guidance at all for authoritative servers.

Agreed.

> responses. What thought exercises took you in this direction?

Working back from the premise that there -will- be ANAME unaware 
secondaries, we allow primaries to do the ANAME expansion during 
outgoing AXFR (or on load, but in any case the secondary gets actual 
(signed!) A/AAAA records). Thus, such a secondary will simply serve the 
A/AAAA. To keep things simple, we decided that an ANAME aware auth will 
do the same, so behaviour is consistent.

The alternative, of defining those records as fallback, means that ANAME 
aware slaves that -do- receive a pre-expanded A/AAAA set, need 
configuration knobs to figure out if they should look up the ANAME 
target or not. We could automate this to a limit - say, if you are a 
slave, you understand ANAME, and you do not have the private key for the 
zone, then obviously you have to use what you find in the zone. However, 
it was my feeling that this would yield more complexity than we want.

Anyway, I will ponder your use case.

As for ‘AAAA from config, A from ANAME’, we’ve been discussing 
allowing multiple ANAMEs at a node, and then you could do something like 
this:

www.example.com. ANAME www-v6.example.com.
www.example.com. ANAME example.com.my-cdn.com
www-v6.example.com. AAAA 2001:db8::80

>>> starting at the time of zone transfer)? And when only a single 
>>> address
>>> type
>> have

Not by me so far, I’ll readily admit. Will ponder.

> when they *don't* correspond to A or AAAA QTYPEs?

Probably not.

> the form of MAY or SHOULD guidance for using DNSSEC when resolving 

Indeed.

Kind regards,

---

From: Florian Weimer <[email-masked]>
Date: Mon, 10 Apr 2017 11:29:50 +0200

> Title:		Address-specific DNS Name Redirection (ANAME)

I think the introduction should discuss why it is not possible to push 
the CNAME to the parent zone, replacing the entire zone with an alias.

Section 3 is currently written in such a way that a recursive DNS lookup 
must be performed at the authoritative server side.  I don't think it is 
necessary to require that.  A recursive DNS lookup of the target is just 
one way to implement this.

In particular, the suggested recursive DNS lookup needs some form of 
distributed loop detection.  Otherwise, a malicious customer could 
publish two zones with ANAME records and achieve significant traffic 
amplification, potentially taking down the DNS hoster.  A hop count in 
an EDNS option or an “ANAME lookup in progress” indicator would be one 
way to implement this.  Another approach would impose restrictions on 
the owner name of an ANAME record and its target, and restrict where 
CNAMEs can appear, so that a valid ANAME can never point to another 
valid ANAME.

Thanks,
Florian

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 10 Apr 2017 12:04:52 +0200

> the CNAME to the parent zone, replacing the entire zone with an alias.

Why this is not possible seems obvious to me, but we’ll see what we 
can write.

> Section 3 is currently written in such a way that a recursive DNS 
> lookup must be performed at the authoritative server side.  I don't 
> think it is necessary to require that.  A recursive DNS lookup of the 
> target is just one way to implement this.

What other ways did you have in mind?

> an EDNS option or an “ANAME lookup in progress” indicator would be 
> one way to implement this.  Another approach would impose restrictions 
> on the owner name of an ANAME record and its target, and restrict 
> where CNAMEs can appear, so that a valid ANAME can never point to 
> another valid ANAME.

I’m not sure it’s feasible to forbid chaining ANAMEs. I do agree 
there is a vector for DoS here. Section 6 currently cowardly says 
“Both authoritative servers and resolvers that implement ANAME should 
carefully check for loops and treat them as an error condition.” but I 
am aware that more words are needed.

Kind regards,

---

From: Ray Bellis <[email-masked]>
Date: Mon, 10 Apr 2017 11:39:19 +0100

On 10/04/2017 11:04, Peter van Dijk wrote:

> Why this is not possible seems obvious to me, but we’ll see what we can
> write.

Many TLD registries simply don't permit CNAMEs instead of delegations
for their customer domains.

The only one I've heard of that does is .de

Ray

---

From: Ray Bellis <[email-masked]>
Date: Mon, 10 Apr 2017 11:53:39 +0100

> The only one I've heard of that does is .de

My real point being that the parent / child relationship can have policy
rules in place that prevent things that are technically completely possible.

Ray

---

From: Jan Včelák <[email-masked]>
Date: Mon, 10 Apr 2017 16:16:06 +0200

> Here's the new ANAME draft I mentioned last week.

Hey, thanks for this one! I support the attempt to define a record
type that would cover the existing vendor-specific types that
synthesize A/AAAA records in zone apex. If this gets adopted by the
vendors, it means possible zone transfers between these providers. On
the other hand, I don't like the part which moves ANAME processing to
resolvers. I'll comment on that separately.

Besides that, The Security Section should warn DNS operators that
ANAME may be misused to leak data from any internal networks the
server is part of. This was so far concern for resolvers, but with
ANAME it may become a concern for authoritative servers as well.

Jan

---

From: "John Levine" <[email-masked]>
Date: 10 Apr 2017 15:10:07 -0000

>rules in place that prevent things that are technically completely possible.

True, but the most common broken CNAME I see is something like this:

example.com MX 0 mail.example.com
example.com CNAME www.example.com

www.example.com A 1.2.3.4

I agree that if we go ahead with this document, a paragraph pointing
to the ways that CNAMEs don't solve the problem would be helpful.

R's,
John

---

From: Evan Hunt <[email-masked]>
Date: Mon, 10 Apr 2017 21:44:27 +0000

> generealised multi-query-at-once using one of the previously suggested

I must have been unclear -- I meant the slash to mean "or". This isn't
about getting back multiple records. I did include a MAY in there saying
that if you query for an A you can get AAAA in the additional section, and
vice versa, but that's not the central point of ANAME at all.

This is a mechanism for redirecting address queries. Because it's limited
to address types, it can, unlike CNAME, be used at the zone apex.

So the initial query is going to be for type A or type AAAA. (If we ever
invent a third address family, that would count here as well.)  The
response is going to be an ANAME record plus the address you asked for.
That address has to be looked up by the auth in case the querying resolver
doesn't have ANAME support, but if the resolver *does* have ANAME support,
then it repeats the lookup on its own behalf, just as it would do if it got
back a CNAME.

> a regular DNS record without any abnormal processing.

Fine idea but not related.  ANAME == CNAME for addresses.

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 11 Apr 2017 13:43:18 +0200

Hello Jan,

> ANAME it may become a concern for authoritative servers as well.

Oh good catch, thanks!

Kind regards,

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Apr 2017 16:45:17 +0100

Florian Weimer <[email-masked]> wrote:
>
> I think the introduction should discuss why it is not possible to push the
> CNAME to the parent zone, replacing the entire zone with an alias.

You can't replace an entire zone with a CNAME if it has subdomains. ANAME
records are not just for zone apexes. There are lots of other cases where
address records need a different alias target from MX records, or NAPTR
records, etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty: West 5 to 7, perhaps gale 8 later. Moderate or rough. Rain
then showers. Good occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Apr 2017 16:52:10 +0100

> fact that we can't go back in time and put ANAME support into all

On the authoritative side I think server behaviour should be partitioned
into primary and secondary:

Primary servers are able to modify zone contents. This might be old skool
batch provisioning or dynamic on-demand trickery.

Secondary servers just serve what they get via xfer from primaries.

ANAME expansion happens on primaries and (in the future) on recursors, but
not secondaries nor stubs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Easterly or southeasterly 4 or 5, but 6 or 7 in far southeast,
becoming variable 4 later except far southeast. Slight or moderate. Fair.
Moderate or good.

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Apr 2017 16:54:46 +0100

Wouldn't it be safer to put the ANAME in the additional section?

Do we care about SSHFP?

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Apr 2017 14:16:33 -0400 (EDT)

On Tue, 11 Apr 2017, Tony Finch wrote:

> ANAME

Can you give me an example of deploying ANAME outside the zone APEX that
is not solved by allowing a CNAME to point to a CNAME (which most code I
think already allows anyway)

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Apr 2017 19:42:29 +0100

> think already allows anyway)

https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html

If you have a subdomain that needs to be a mail domain and a web site, you
need an MX pointing at your mail server and address records pointing at
your web server. You can't use a CNAME because they are usually different
servers.

Also, mail domains cannot in practice be CNAMEs because of the disaster of
RFC 821 / RFC 1122 mail domain canonicalization.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Easterly or northeasterly 4 or 5, occasionally 6 in south. Slight or
moderate, occasionally rough at first in south. Fair. Good.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 11 Apr 2017 21:04:59 +0200

> address records need a different alias target from MX records, or NAPTR

Sure, but the document should list that.

FWIW, I think the real problem is that it is perceived as cheaper to 
upgrade DNS servers than to support CNAME records in the provisioning 
infrastructure.

Thanks,
Florian

---

From: Florian Weimer <[email-masked]>
Date: Tue, 11 Apr 2017 21:09:54 +0200

> your web server. You can't use a CNAME because they are usually different

That's not a problem, you can have MX records at the CNAME target.

> RFC 821 / RFC 1122 mail domain canonicalization.

I can see why this is a concern, but does current sendmail still rewrite 
the headers?  (The envelope recipient is far less problematic.)

Thanks,
Florian

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Apr 2017 15:11:03 -0400 (EDT)

> your web server. You can't use a CNAME because they are usually different

Hmm okay. Although you could just make a real zone cut there and then it
becomes the APEX case again :P

> RFC 821 / RFC 1122 mail domain canonicalization.

I'm not sure ANAME's make deployment corner cases easier :P

I still feel using ANAME without preprocessing by auth nameservers and
fixing returning multiple record type to a single query is the more
generic and fix for this problem.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Apr 2017 20:15:43 +0100

> On 11 Apr 2017, at 20:09, Florian Weimer <[email-masked]> wrote:
> 

That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's.

You might also have NAPTR records pointing at providers C and D.

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

---

From: Florian Weimer <[email-masked]>
Date: Tue, 11 Apr 2017 21:11:54 +0200

> What other ways did you have in mind?

Private arrangement with the target zone operator (that is, direct, out 
of-band access to the zone).

> I’m not sure it’s feasible to forbid chaining ANAMEs. I do agree there
> is a vector for DoS here. Section 6 currently cowardly says “Both
> authoritative servers and resolvers that implement ANAME should

I don't see how you can detect loops without DNS protocol changes.  The 
query that comes back will look like a completely fresh query.

Thanks,
Florian

---

From: Florian Weimer <[email-masked]>
Date: Tue, 11 Apr 2017 21:39:56 +0200

> That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's.

I don't understand.

I think it boils down to who operates the target DNS zone and how 
flexible they are.  It has nothing to do with who runs the web server.

Thanks,
Florian

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Apr 2017 21:15:22 +0100

> On 11 Apr 2017, at 20:39, Florian Weimer <[email-masked]> wrote:
> I think it boils down to who operates the target DNS zone and how flexible they are.  It has nothing to do with who runs the web server.

In many cases the ANAME target will be a mass web hosting provider which doesn't have any flexibility in their DNS setup.

And you still don't want CNAME pointing at MX because of the interop problems.

Having implemented something like this on the provisioning end, it seems simpler and more useful to me to make ANAMEs work anywhere.

Tony.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Apr 2017 20:16:16 +0000

> query that comes back will look like a completely fresh query.

We can put a limit on the number of hops that are followed in populating
the A and AAAA records for the expanded ANAME response.  If that limit is
exceeded, the ANAME record could be rejected by the auth; either the zone
wouldn't load or address queries return SERVFAIL.

BIND already has a limit of 16 hops for CNAME loop prevention. I assume
other resolver implementations must do something similar.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 11 Apr 2017 22:20:31 +0200

> In many cases the ANAME target will be a mass web hosting provider which doesn't have any flexibility in their DNS setup.

And in order to accommodate them, we upgrade the DNS server 
infrastructure across the Internet?

I understand that's how things work in practice, but I don't kike it.

> And you still don't want CNAME pointing at MX because of the interop problems.

CNAME to MX is fine.  Isn't this what's relevant here?

Thanks,
Florian

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Apr 2017 20:31:34 +0000

On Tue, Apr 11, 2017 at 10:21:13PM +0200, Florian Weimer wrote:
> But what happens when the target server also performs cache filling at 
> the same time?

If two servers end up being unable to populate their address records
because they're depending on each other for answers, then you end up
with two servers that both return SERVFAIL on address queries.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 11 Apr 2017 22:21:13 +0200

Thanks,
Florian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Apr 2017 06:37:14 +1000

> CNAME to MX is fine.  Isn't this what's relevant here?

There are times when you want the MX of the owner of the CNAME to
be different to the target of the CNAME.  Similarly for every other
record type.

CNAME has NEVER been the correct record to point to a server for a
service.  We are here because browser vendors refuse to actually
use good practices with the DNS.  To follow best practice examples
(e.g. MX records).

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Apr 2017 21:44:18 +0100

> On 11 Apr 2017, at 21:20, Florian Weimer <[email-masked]> wrote:
> And in order to accommodate them, we upgrade the DNS server infrastructure across the Internet?

No.

We are working around a design error in the way CNAMEs work within the DNS. Rather than making a narrow-minded bodge that only works for one special case, we should fix the general case. All that is required is to make ANAMEs work anywhere, just like the vast majority of other RRtypes.

> CNAME to MX is fine.

No it isn't, because it causes mail domain rewrites.

Tony.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Apr 2017 20:47:26 +0000

> infrastructure across the Internet?

Them, and web browser implementers who just don't want to use SRV.

We did the best we could to ensure it can be deployed gradually,
though. The domain that wants to redirect apex addresses can implement
ANAME, and its clients will get answers. Resolvers that want better
answers can do that too. Forklift not required.

> I understand that's how things work in practice, but I don't like it.

So say we all.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 12 Apr 2017 10:21:13 +0200

> Them, and web browser implementers who just don't want to use SRV.

SRV wouldn't work anyway because it is incompatible with existing name 
resolution interfaces anyway.

If you do not insist on using SRV, but something that is just an alias 
(like PTR, ANAME etc.) and processed in the client, it would be quite 
straightforward to put this into the stub resolver, and then all 
applications[*] would automatically get the addresses at the 
substitution name (SNAME).  Disallow multiple substitution names per 
owner name and their chaining (but chaining to CNAME would be okay), and 
I think it would just work.

But then DNS operators will worry about a 50% (from A/AAAA to 
A/AAAA/SNAME) to 150% (from A/AAAA to A/AAAA/SNAME plus A/AAAA at the 
SNAME) increase in query load.  (SRV would be worse because there could 
be multiple target names, all needing separate processing.)  Would that 
be acceptable?  I don't know.

In fact, Firefox already solved the issue in the client: If you enter 
the zone apex, and no address record exists, it automatically redirects 
to the www name in the zone.  Unfortunately, DNS operators broke that 
when they started rewriting NODATA responses, injecting ads into 
existing domains.  So you really have to have addresses at the zone apex 
these days.

Thanks,
Florian

[*] At least all applications which correctly deal with enterprise name 
lookup, which can involve NIS and LDAP, too, not just DNS.

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Apr 2017 10:48:26 +0100

> becomes the APEX case again :P

Well, this is the kind of "just" that involves a huge co-ordination cost
updating the configuration of on-site and off-site secondary servers, and
may have billing implications if you exceed your zone quota on a
commercial provider.

> I'm not sure ANAME's make deployment corner cases easier :P

They would greatly simplify things for me.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Easterly or northeasterly 4 or 5, occasionally 6 in southeast. Slight
or moderate. Occasional rain later. Good, occasionally moderate later.

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 12 Apr 2017 21:06:56 +0200

> resolution interfaces anyway.

Which browsers tend to avoid as far as I know, but it’s besides the 
point - browsers are not doing SRV and we have to accept that.

> owner name and their chaining (but chaining to CNAME would be okay), 
> and I think it would just work.

But that’s a forklift upgrade of -end user stations-.

> SNAME) increase in query load.  (SRV would be worse because there 
> could be multiple target names, all needing separate processing.)  
> Would that be acceptable?  I don't know.

I don’t know either - I do know the draft does not require anyone 
(except the auth operator who decides to use ANAME) to do more queries 
than they are doing now.

> the zone apex, and no address record exists, it automatically 
> redirects to the www name in the zone.  Unfortunately, DNS operators 
> broke that when they started rewriting NODATA responses, injecting ads 
> into existing domains.  So you really have to have addresses at the 
> zone apex these days.

They solved the issue for ‘CNAME at apex’, which is not the only use 
case for ANAME.

Kind regards,

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 12 Apr 2017 21:08:20 +0200

> generic and fix for this problem.

As Evan said, we would love to go back in time and add ANAME support to 
all existing resolvers out there, but we can’t. Until then, the auths 
will have to assist, as many of them are doing today already.

Kind regards,

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 12 Apr 2017 21:10:20 +0200

> think already allows anyway)

One PowerDNS user is using ALIAS (our ANAME precursor, if you will) 
because he is by policy not allowed to CNAME into unsigned zones, and 
his app is hosted on Amazon with ELB which means Route53 is mandatory 
for him.

Kind regards,

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 13 Apr 2017 10:46:23 +0200

> Wouldn't it be safer to put the ANAME in the additional section?

My thinking was that given that DNAME got away with being in ANSWER, so 
could we.

> Do we care about SSHFP?

I understand the question but I’m uncomfortable extending ANAME beyond 
address types. I will put it on the list of things that need more 
thought.

Kind regards,

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 13 Apr 2017 09:53:55 +0000

Hi Peter,

one question, will authoritative server return multiple ANAME RRs for the
same domain at one dns query ?

for example,

www.example.com  ANAME  us.www.example.com
www.example.com  ANAME  cn.www.example.com

or  return only one selected ANAME RR for one domain ? (based on
authoritative's policy, resolver ip/client subnet/...)

www.example.com  ANAME  us.www.example.com

thanks

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 13 Apr 2017 12:54:50 +0200

Hello,

> www.example.com  ANAME  us.www.example.com

Currently the draft explicitly states ‘No more than one ANAME resource 
record SHALL be present at any DNS node.’, but we have received 
multiple requests to relax this requirements, and will consider that.

That said, nothing prevents your own implementation from choosing the 
target based on any kind of local policy. So if you want to pick US or 
CN based on client IP, you can do that.

Kind regards,

---

From: Florian Weimer <[email-masked]>
Date: Thu, 13 Apr 2017 13:30:12 +0200

> point - browsers are not doing SRV and we have to accept that.

If the browser uses DNS directly, it won't be able to use NIS/LDAP, 
WINS, Bonjour, or LLDNS.

Firefox on GNU/Linux uses getaddrinfo, as expected.

> But that’s a forklift upgrade of -end user stations-.

It's just about an optimization.  I think it's doable, except that we'd 
receive pushback on the query load issue.

> (except the auth operator who decides to use ANAME) to do more queries 

Right, that's one advantage of the ANAME proposal.

Florian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 13 Apr 2017 13:27:13 -0700

At Fri, 7 Apr 2017 18:11:39 +0000,

> answer just as it would with a CNAME.

I've read draft-hunt-dnsop-aname-00 and have some comments on it.  I'm
aware that similar comments on some points have been made in this
thread, but I'm providing my own version at the risk of repeating as I
think these are not necessarily a complete duplicate.

Overall I agree this is worth trying to achieve.  There is a clear
need for the ability of defining an alias at a zone apex, and it will
be nicer if we provide a standard-compliant and interoperable way for
that.  I also agree that a long-term goal (hope) should deploy it in
the resolver side even if it will take quite long (if not fail), so
that authoritative server implementations can be kept lightweight and
simple.

I have one high-level concern in terms of the merit of providing a
standard/interoperable version of 'alias'.  As already noted in the
draft there are currently several proprietary mechanisms of 'alias',
mainly to allow an alias at a zone apex.  In order for the standard
version to be successful, it will have to be compatible with these
existing ones as much as possible and as long as it doesn't break
other DNS standards.  In that sense I see some disparity with the
ALIAS record of Amazon Route53, one of the earliest (and probably
largest) players of the idea:
- Supporting other types of records than AAAA and A
- Allowing different target names for different types
I don't know how critical these are for existing R53 ALIAS users, but
depending on that ANAME may not be able to be successful in practice.

I also wonder whether it's okay to allow 'AAAA or A' and ANAME to
coexist for the same owner name.  Shouldn't it be prohibited similar
to that CNAME and other types can't coexist?

Some specific comments on the draft text follow:

- Section 3

   If the original query is for type A, and an RRset of type A exists at
   the final ANAME <target>, then that A RRset (with <owner> changed to
   match that of the ANAME RR), MUST be appended to the answer section
   after the ANAME RRset.

  What if the target name of ANAME does not exist (NXDOMAIN)?
  Returning NXDOMAIN is quite likely to be a bad choice, since the
  owner name of the query actually does exist.  It will be certainly
  problematic if it's a zone apex.  So should it be translated into
  NOERROR+NODATA?  Or something else?  Also, if the zone is signed,
  what kind of proof should be returned?

- Section 3.1

   Address records cached locally MUST have a limited TTL.  The initial
   TTL for locally-cached address records MUST be set to the lesser of
   the ANAME TTL and the TTL of the address records retrieved from the
   ANAME <target>.  The local TTL MUST count down, just as it would in a
   conventional resolver cache.[...]

  Should the local TTL count down, even if the initial value is from
  the ANAME TTL?  I suspect that's not the intent, and if I'm correct
  I think the current text is confusing and should clarify it.

- Section 3.2

   If the zone is configured with an A or AAAA RRset at the same DNS
   node as ANAME, then the ANAME is considered to have been pre-expanded
   for zone transfer purposes.  When a zone is being transferred to a
   secondary server, if any address record already exists at the same
   node as an ANAME RR, then the ANAME RR MUST NOT be further expanded
   by the authoritative server.

  (I have a more fundamental concern about the coexistence as stated
  above, but ignoring it in this context) I'm afraid this text talks
  about something not explained before this point or not even
  explained clearly anywhere in the draft.  I guess the "pre-expand"
  means the following behavior described in section 3.3, but not
  necessarily with RRSIGs:

   Implementers MAY allow address records associated with the ANAME to
   be populated and signed by the primary server, then sent along with
   their RRSIGs to secondaries via zone transfer.

  If my understanding is correct, the concept of population/pre-expand
  behavior for zone transfer should be explicitly introduced before
  the discussion in Section 3.2.

--
JINMEI, Tatuya

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2017 20:03:16 -0000

>My thinking was that given that DNAME got away with being in ANSWER, so 

Seems to me that it belongs in the answer section, since for aname-aware
reasolvers the aname is the answer.

>address types. I will put it on the list of things that need more thought.

Type bitmaps like the ones in NSEC wouldn't be hard to implement.  Add
some sanity rules saying that type bits for DNSSEC types and the like
are ignored, and it's an error to include any types also present at
the same name.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2017 20:34:24 -0000

In article <CANLjSvVJS1-6S78R8xfubmc+rTVUon6Xa4YMbtQ7W9zVFC=[email-masked]> you write:
>-=-=-=-=-=-

We can probably assume that multiple ANAMEs are treated the same as multiple
CNAMEs or multiple DNAMEs.

Don't Do That.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Apr 2017 13:54:54 +0100

> to that CNAME and other types can't coexist?

From the point of view of a provisioning-side implementation of ANAME, the
A and AAAA records are pre-populated answers from the target name.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Sole: East or northeast 4 or 5. Slight or moderate. Fair. Good.

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 19 Apr 2017 20:29:07 +0200

> are ignored, and it's an error to include any types also present at

Type bitmaps would preclude simple implementations that use getaddrinfo 
to do their business. As much as I think the idea may have merit, I feel 
this draft should stay close to the long list of existing ALIAS/ANAME 
implementations if it wants any chance to succeed.

If after that (perhaps after some operational experience with ANAME!) 
you want to draft up a more generic forwarding mechanism, I will happily 
help you write it all down.

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Apr 2017 22:47:24 -0400 (EDT)

> implementations if it wants any chance to succeed.

But the implementation really seems to do two things. Bundle A/AAAA
with other records and providing a level of indirection. By combining
these we are really adding a whole new type of behaviour to the DNS
that could be avoided.

> help you write it all down.

Which is why I don't agree with this.

ANAME could just be a regular RRTYPE without any special handling,
meaning "go look there for up to date information on A/AAAA". It could
come along A/AAAA records using one of the existing bitmaps multi-type
query proposals that have been suggested in the last two years.

Prepopulating or updating the A/AAAA records on the auth server should
also be a separate issue/draft and ideally not need the auth server
to require either recursion or validation. A new type of authenticated
XFR query seems to make more logical sense to me. It would also allow
much stricter firewalling on the auth server.

It seems dnsop is more and more getting these arguments of "but we
are just documenting existing behaviour", like with client-subnet and
RPZ. It's really not the best way to develop new DNS extensions, as I
also argued when we talked about RPZ.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Thu, 20 Apr 2017 06:36:48 +0000

> query proposals that have been suggested in the last two years.

But, because there are always going to be legacy servers, the client would
then need to send an ANAME query, and when it got no answer, send another
query for A and AAAA.

If clients were willing to do that, then they'd have been willing to use
SRV, and we'd have standardized on that long since.  Which would've been
fine, but browser vendors have had years to do it, and they never have.

Apparently, what they want is to send address queries and get redirected
answers. And if we can't make them do the smart thing, at least we can
give them an interoperable and standards-compliant way to do the dumb
thing.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 20 Apr 2017 11:21:38 +0200

On 04/20/2017 08:36 AM, Evan Hunt wrote:
> SRV, and we'd have standardized on that long since.

This is simply not true.  SRV is broken for almost any purpose, which is 
why it is only used for protocols which have mandated its use.

Most name lookup interfaces only take a name and return an address. 
With these interfaces, it is technically impossible to synthesize a 
query name for a SRV lookup, and return the port number in the SRV 
record to the caller.  (This even true for the RFC 3493 interface, which 
is often used without a service name argument, or a numeric service name.)

An ANAME query to find a substitution name does not suffer from this 
problem.  It fits well with existing name lookup interfaces.

> Which would've been

Why are you focusing on browsers?  This is about the system name 
resolution service, which browsers still use to perform NIS/WINS/LDAP 
host name lookups, not just DNS.  As I tried to explain above, SRV is 
incompatible with most of the traditional system name resolution 
interfaces.  A name substitution with an ANAME redirection would not 
have this problem.

> give them an interoperable and standards-compliant way to do the dumb

I have no idea how to map most URI schemes to SRV lookups and resolve 
conflicts between port numbers, transport protocols in use (e.g., if 
QUIC is active), and service names (should an XMLRPC request get a 
different name?).  Without that mapping, there is nothing that browser 
vendors could implement.

What I'm trying to say: The SRV failure is not sufficient evidence that 
client-side name substitution would not see significant uptake because 
SRV works at the wrong layer(s).

Thanks,
Florian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Apr 2017 11:13:54 -0700

At Tue, 18 Apr 2017 13:54:54 +0100,

> A and AAAA records are pre-populated answers from the target name.

As long as those records are generated from the target name that would
probably be okay.  But the current draft doesn't seem to enforce it,
and, (probably unintentionally/implicitly) allows the following setup:

aaaa.example.com. ANAME aaaa.example.net.
aaaa.example.com. AAAA 2001:db8::aaaa ; not populated from ANAME target
aaaa.example.net. AAAA 2001:db8::bbbb

This looks more like a prohibited "CNAME + other AAAA for the same
name" situation to me.

--
JINMEI, Tatuya

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Apr 2017 16:54:55 -0400 (EDT)

> fine, but browser vendors have had years to do it, and they never have.

If that is your use case, I also see no point in ANAME being used by
resolvers, and you should just create the new XFR type for this, so that
AUTH servers can update their A/AAAA records without needing any
recursive DNS protocol changes. Because what you seem to want is a
method for updating some information between two AUTH servers.

> give them an interoperable and standards-compliant way to do the dumb

Maybe if A and SRV could be returned in the same query they would, so
that leads back to generic support for multi-type queries (with I guess
_location support) being a better generic solution to the problem
compared to this ANAME draft that builds a validating recursive resolver
into any authoritative server.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Thu, 20 Apr 2017 21:51:56 +0000

> method for updating some information between two AUTH servers.

What I want is for queries for addresses at a zone apex to be redirectable,
so that (for example) "www.example.com" and "example.com" have the same
degree of flexibility.

I'd love it if an authoritative server, configured with an ANAME, returned
only the ANAME and let the resolver populate it. However, legacy resolvers
won't know what to do with an ANAME answer, so the authority will need to
provide addresses too. Several vendors are already doing that part of it.

> into any authoritative server.

Once again, the recursive resolver needn't be built in. It only has to be
accessible -- via resolv.conf, for example.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Apr 2017 19:48:34 -0400 (EDT)

> accessible -- via resolv.conf, for example.

Mmmm, populating auth servers based on at most an AD bit of something
from resolv.conf. Which more and more people are just pointing to
8.8.8.8. I don't think that's a good idea.

Maybe some good software and an internal-only ANAME special record
with a secure DNS helper app isn't too bad after all. But again,
if done well, would not require ANAME to ever go over the wire.

I think we've circled sufficiently around now that I'll step back and
let others chime in.

Paul

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Apr 2017 10:57:36 +0100

> This looks more like a prohibited "CNAME + other AAAA for the same

From an implementation's point of view, it can't tell the difference
between this kind of misconfiguration, and legitimate mismatches due to
things like stale address records or addresses obtained from different
views, etc. In all these cases it can either use the addresses it has been
given or replace them with the addresses from the ANAME target.

Hostmasters who set up inconsistent ANAME and addresses will suffer the
consequences :-) Maybe their suffering could be avoided by a suitably
intelligent master file loader or other provisioning thing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet: Variable 3 or 4. Smooth or slight, occasionally moderate in
southwest Fastnet. Fair. Good.