Subject: [DNSOP] ANAME loop detection

From: Jan Včelák <[email-masked]>
Date: Thu, 4 Jul 2019 11:37:42 +0200

Hello.

I would like to resurrect the discussion about ANAME loops handling
and detection. I attempted to write a discussion section on this topic
for draft-ietf-dnsop-aname
[https://github.com/each/draft-aname/pull/70] and we also talked about
this a little off-list with Shane and Matthijs.

If you are still not concerned about the loops, imagine this setup:
Let's have two authoritative servers X and Y performing ANAME sibling
address substition on the fly (i.e. they attempt to resolve the ANAME
target when the client query arrives). If server X gets a query for
FOO.TEST which is an ANAME to BAR.TEST, it will send a query to server
Y for BAR.TEST which is an ANAME to FOO.TEST. Server Y will then start
a new query to server X, which has no way to know that it is regarding
the original FOO.TEST lookup.

The only indicator of the presence of the loop in the described setup
is the network timeout. Ideally we would recognize the loop explicitly
based on the exchanged DNS messages.

The on-the-fly ANAME substitution is allowed by the draft and it's
just the most obvious scenario where the problem can be demonstrated.
I'm quite sure there are other cases which do not involve
authoritative server doing on-the-fly substitution and where the loops
will still be a problem.

The root cause is that when the server gets a query it doesn't know
why and that the server always attempts to fully resolve the ANAME
target before sending the response.

We had been thinking about how this could be fixed and here is what we
have came with:

1. EDNS "do not follow ANAME" option: The requester would indicate
that it is capable of following ANAME and that the server receiving
the query should not include the ANAME sibling address records. The
loop detection would then work exactly the same ways as with CNAMEs.

2. QTYPE=ANAME: According to the current version of the draft, server
answering to ANAME must include the ANAME and should include the
sibling records. Let's modify the behavior and say the server should
not (must not) include the sibling records. Then the server performing
ANAME sibling address resolution could first query for ANAME before
trying A or AAAA. We get the same loop detection mechanism as with
CNAMEs at the cost of an extra query per ANAME

3. EDNS "seen names" options: An option with a list of visited ANAMEs
would be introduced. The requester would add the option into the query
when resolving an ANAME target. The receiving server would consult the
list in case another ANAME was encountered and either broke the loop
or forwarded the updated option to the next server.

4. EDNS "nonce" option: Variance on the previous option which would
include a numeric nonce instead of full domain names. A receiving
server would break the loop if it has seen their nonce. It would be
more compact but the question is how to select the nonce pragmatically
especially if there can be more servers serving the same zone.

Do you have thoughts on the listed options or brand new suggestions?

It's also worth mentioning that this is an optimization in a sense.
The timeouts will be the only option to resolve the loop with
ANAME-unaware resolvers.

Jan

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 4 Jul 2019 11:54:10 +0200

Jan,

I like something like option 2 the best, I'll react to your options below.

> Hello.
[ ... ]

> loop detection would then work exactly the same ways as with CNAMEs.

This would be an easy addition I think, however I thought the "do not
follow ANAME" option actually meant "really don't do a target lookup I
can do it myself".  The authoritative server can still send the sibling
address records that are placed in the zone, they can be used if the
requester fails to perform the ANAME target lookup (for example due to a
network error or outage).

Furthermore, a service provide receiving such a request might want to
ignore it if it feels strongly it should hand out more appropriate
addresses than the sibling records (basically because that is the
service they provide their customers, will they rely on an EDNS option
from the requester saying "no really I can do this"?).

> CNAMEs at the cost of an extra query per ANAME

Again, I think what we should clarify is that it is a signal to not do
do ANAME target lookup. Sibling address records are fine and required at
some point.

I like this option the best, because the requester is interested in the
ANAME record in the particular zone, and so there is no need for
chasing.  While with address queries the requester is actually
interested in the target address, and so chasing makes sense.

We could change the specification such that a server that does ANAME
target lookups MUST use QTYPE=ANAME and servers receiving ANAME queries
MUST NOT chase the target and would solve the loop problem.

> especially if there can be more servers serving the same zone.

These options feel like more work and if one of the earlier options work
I would rather do that.

Best regards,

Matthijs

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

---

From: Shane Kerr <[email-masked]>
Date: Thu, 4 Jul 2019 14:29:58 +0200

Matthijs,

> I like something like option 2 the best, I'll react to your options below.

I like something like option 1. Details below as well. 😊

> network error or outage).

I think that your understanding is correct, and is basically what is 
meant. Again, the idea is to avoid having the authoritative server do 
lookups on behalf of anything trying to follow an ANAME chain.

So the language would probably be like, "An ANAME-aware server that 
receives a query with the 'do not follow ANAME' option MUST NOT send DNS 
queries in order to look up ANAME targets. It MAY include ANAME targets 
in the response if getting those does not require sending DNS queries."

> from the requester saying "no really I can do this"?).

I suppose this makes a certain amount of sense, although the service 
needs to be careful to ensure that ANAME records timeout no later than 
the sibling records so that no resolvers will resolve ANAME without 
going to it.

If this is a use case that we care about, it might be worthwhile to have 
some explicit text around this, possibly in the "On preserving TTLs" 
section?

> MUST NOT chase the target and would solve the loop problem.

My main concern about this approach is the extra lookup required.

Keep in mind that most ANAME targets are NOT going to be ANAME 
themselves (although probably many will), so this means that in most 
cases ANAME servers will have to do an extra lookup before moving on to 
usual A/AAAA lookups. These QTYPE=ANAME cannot be done in parallel with 
A/AAAA queries, since those might trigger the ANAME loops that we are 
trying to prevent.

Everything will work, and caching might make this unimportant. Still, I 
think that the EDNS option is a better choice overall.

I will admit that QTYPE=ANAME will have an advantage in complex setups 
because EDNS is hop-by-hop and DNS queries will relayed without this 
concern.

> These options feel like more work and if one of the earlier options work

Totally agreed. I am happy that they are here for completeness though.

Cheers,

--
Shane

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 4 Jul 2019 08:32:27 -0400

> from the requester saying "no really I can do this"?).

I would say they should rely on that.  Why shouldn't they?  Isn't our goal
to get downstream servers to adopt the extension and do their own lookup?
The server-side lookups and sibling records are bolt-ons to handle the
adoption period.  Remember, this record is geared toward customers of CDNs
being able to do get similar behaviour to:
www.example.com. IN CNAME webfarm.cdn.net.
at the apex of example.com.  That was the original problem we're trying to
solve.  I read your statement above about "the service they provide their
customers" being about the CDN resolving webfarm.cdn.net, which most CDNs
can already do within their own infrastructure.

Sending out the sibling records in the presence of this EDNS option might
make sense as a backup, since that is low effort on the part of the
authoritative, but a declaration by the querying server that it understands
ANAME and is prepared to do its own lookups should be trusted by the
authoritative server, and it should not to recursive lookups.  To take that
further, why would the authoritative server believe that the results of any
lookups it does would not be thrown away?

This EDNS option should also be useful to recursive servers that understand
ANAME, and are planning to do their own ANAME resolution.  They can get
their answer from the authoritative server much faster this way.

This is also a way to measure adoption.  As the ratio of "EDNS do not
follow ANAME" queries to total ANAME queries approaches 1.0, we know that
adoption has been successful.  Maybe we could even begin to deprecate
authoritative resolution (of ANAMEs) at that point, and begin to get back
to something that looks more like plain CNAME.

I would suggest that better EDNS semantics would be just "I
understand/support ANAME".   That gets the desired information across
without the sense of sending a command to the upstream server.

Option #2 gets similar behaviour but at the cost of additional lookups.  #3
and #4 don't work well in the presence of server farms.

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 4 Jul 2019 15:19:09 +0200

Shane,

> A/AAAA queries, since those might trigger the ANAME loops that we are

If we change the specification such that sibling address records MUST be
in the response to an ANAME request that extra lookup is not needed.

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 4 Jul 2019 16:54:41 +0200

Matthew,

On 7/4/19 2:32 PM, Matthew Pounsett wrote:
> 
> 
> On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     >
> I would say they should rely on that.  Why shouldn't they?  Isn't our
> goal to get downstream servers to adopt the extension and do their own
> lookup?  The server-side lookups and sibling records are bolt-ons to
> handle the adoption period.  Remember, this record is geared toward
> customers of CDNs being able to do get similar behaviour to:
> www.example.com <http://www.example.com>. IN CNAME webfarm.cdn.net
> <http://webfarm.cdn.net>. 
> at the apex of example.com <http://example.com>.  That was the original
> problem we're trying to solve.  I read your statement above about "the
> service they provide their customers" being about the CDN resolving
> webfarm.cdn.net <http://webfarm.cdn.net>, which most CDNs can already do
> within their own infrastructure.

I am talking about DNS providers that perform CNAME at the Apex like
features: a customer goes to them and opts in to this feature. Such a
provider wants to make sure that it is providing the behavior the
customer expects and thus wants to make sure it hands out appropriate
addresses.

Also what is wrong with an authoritative server already giving out more
optimal answers than just the ANAME and sibling address records?

> Sending out the sibling records in the presence of this EDNS option
> might make sense as a backup, since that is low effort on the part of
> the authoritative, but a declaration by the querying server that it
> understands ANAME and is prepared to do its own lookups should be
> trusted by the authoritative server, and it should not to recursive
> lookups.  To take that further, why would the authoritative server
> believe that the results of any lookups it does would not be thrown away? 
> 
> This EDNS option should also be useful to recursive servers that
> understand ANAME, and are planning to do their own ANAME resolution. 
> They can get their answer from the authoritative server much faster this
> way.

I am not sure if that is true. Perhaps if you do ANAME target lookup on
the fly yes, but I think most implementations will have a side process
that does the target lookup and the query resolution can get the target
addresses just from cache.

> follow ANAME" queries to total ANAME queries approaches 1.0, we know
> that adoption has been successful.  Maybe we could even begin to
> deprecate authoritative resolution (of ANAMEs) at that point, and begin
> to get back to something that looks more like plain CNAME.
> 

I am fine with a "understand/support ANAME" signal, I don't like if that
prohibits the receiver to do its own target lookups. So I am in favor of
a signal that says "this query is part of an ANAME target lookup" to
distinguish it from an address query.

> Option #2 gets similar behaviour but at the cost of additional lookups. 
> #3 and #4 don't work well in the presence of server farms.

If addresses are in the response to the ANAME request there is no
difference in number of lookups between 2 and 3 I think.

Best regards,

Matthijs

---

From: Tony Finch <[email-masked]>
Date: Thu, 4 Jul 2019 16:37:53 +0100

> CNAMEs at the cost of an extra query per ANAME

The main reason I thought it would be a good idea to include sibling
address records in ANAME responses was so that we could get a one-shot
address query as a side-effect. But I think we keep learning that it is a
bad idea to load too much stuff onto ANAME, so I think it's a reasonable
trade-off to ditch the addr query feature so that loop detection is
easier.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Isle of Man: West or southwest 3 or 4, becoming variable 2 at times. Smooth or
slight. Fair. Good.

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 4 Jul 2019 11:39:35 -0400

> customer expects and thus wants to make sure it hands out appropriate

And "CNAME at the Apex like feeatures" is to hand out a CNAME and let the
downstream server process that.  It may include additional information from
other zones it is authoritative for, but it doesn't do side-lookups.  I
think that's the behaviour we should be aiming for, and to do that some
sort of "I understand ANAME" signal would allow the authoritative server to
behave more like CNAME.

> optimal answers than just the ANAME and sibling address records?

Nothing, as long as it's not going to increase the time it takes to respond
to the query.

But, you didn't respond to my question.  Let me rephrase it a bit:  If the
authoritative server knows the client understands ANAME, why would the
authoritative server not assume that any additional data it supplies will
be thrown away?    I suggest that it would be wise for an authoritative
server to assume that a client that understands ANAME will resolve its own
ANAME and ignore any other data it gets.

> difference in number of lookups between 2 and 3 I think.

Did you mean "lookups between 1 and 2"?    I didn't say anything about the
number of lookups required for 3.  I think 3 and 4 are poor choices because
they won't behave well with most server farms.

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 4 Jul 2019 17:54:11 +0200

On 7/4/19 5:39 PM, Matthew Pounsett wrote:
> 
> 
> On Thu, 4 Jul 2019 at 10:54, Matthijs Mekking <[email-masked]
>     > www.example.com <http://www.example.com> <http://www.example.com>.
>     IN CNAME webfarm.cdn.net <http://webfarm.cdn.net>
>     > at the apex of example.com <http://example.com>
>     <http://example.com>.  That was the original
>     > webfarm.cdn.net <http://webfarm.cdn.net> <http://webfarm.cdn.net>,
>     which most CDNs can already do
> And "CNAME at the Apex like feeatures" is to hand out a CNAME and let
> the downstream server process that.  It may include additional
> information from other zones it is authoritative for, but it doesn't do
> side-lookups.  I think that's the behaviour we should be aiming for, and
> to do that some sort of "I understand ANAME" signal would allow the
> authoritative server to behave more like CNAME.

I agree we should be aiming for that, but initial stage will very likely
be that authoritative servers will do the target lookups (otherwise we
could just deploy the HTTP record right now ;))

> Nothing, as long as it's not going to increase the time it takes to
> respond to the query.
> 
> But, you didn't respond to my question.  Let me rephrase it a bit:  If
> the authoritative server knows the client understands ANAME, why would
> the authoritative server not assume that any additional data it supplies
> will be thrown away?    I suggest that it would be wise for an
> authoritative server to assume that a client that understands ANAME will
> resolve its own ANAME and ignore any other data it gets.

I sure hope not that requester will throw away responses, why else is it
 querying the servers in the first place? ;)

The sibling address records that the authoritative server provides are
needed if the requester does its own ANAME target lookup but fails to do
so because of an outage for example. Then it can use the sibling address
records as the response to the client. It would be better if those are
already "ANAME processed" rather than just handing out the sibling
records that were available in the zone file.

So it may be a poor judgment if the requester just throws away the
answer the authoritative server sends.

> Did you mean "lookups between 1 and 2"?    I didn't say anything about
> the number of lookups required for 3.  I think 3 and 4 are poor choices
> because they won't behave well with most server farms.

Yes, 1 and 2. Sorry.

---

From: Shane Kerr <[email-masked]>
Date: Fri, 5 Jul 2019 10:16:45 +0200

Matthijs,

> in the response to an ANAME request that extra lookup is not needed.

I mean in the sense that it requires an extra lookup where the ANAME 
target is not another ANAME.

The logic looks something like this:

if answer.rrtype == ANAME:
     discovered_aname = query_for_aname(answer.rdata)
     if discovered_aname:
         answer.update_with_aname(discovered_aname)
     else:
         discovered_a = query_for_a(answer.rdata)
         answer.update_with_a(discovered_a)
         discovered_aaaa = query_for_aaaa(answer.rdata)
         answer.update_with_aaaa(discovered_aaaa)
reply(answer)

That query_for_aname() call is the extra lookup that using this method 
requires.

If the ANAME target is itself an ANAME, then indeed no extra work is 
required (in fact probably less).

However, if the ANAME target is not an ANAME, then an extra query and 
the associated delay is required (this is probably the more common 
path). The A & AAAA queries can be done in parallel, but they both have 
to wait until the ANAME is finished to avoid loops.

Cheers,

--
Shane

---

From: Jan Včelák <[email-masked]>
Date: Mon, 8 Jul 2019 11:32:20 +0200

> optimal answers than just the ANAME and sibling address records?

I also understand the sibling address records only as a mean to gap
the adoption period. It should not be a feature.

If the DNS provider (i.e. authoritative server) wanted to perform some
magic to provide more optimal answer than the resolver could get by
resolving the ANAME then there is no point of involving ANAME. You can
perform the magic with A/AAAA already.

> addresses just from cache.

This is speculative. The conditions may be very different in each setup.

> > to get back to something that looks more like plain CNAME.

This probably makes me like the option #1 the most.

Jan

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 8 Jul 2019 11:47:00 +0200

Jan,

> the adoption period. It should not be a feature.

It's not a feature, its an optimization: If the requester receives a No
Data response to its ANAME query, he can finalize the target lookup with
an address query to the last target in the chain.

> perform the magic with A/AAAA already.

Not more optimal than the resolver, but more optimal than the default
sibling address records that are put into the zone.  The benefit of that
is that the resolver has more sane addresses to hand out to the client
in case it is unable to perform ANAME target lookup (due to timeout for
example).

---

From: Jan Včelák <[email-masked]>
Date: Mon, 8 Jul 2019 14:15:02 +0200

Matthijs,

> an address query to the last target in the chain.

I tend to disagree. I would not mind if this optimization came for
free but we have to deal with ANAME loops due to the existence of
sibling address records.

> in case it is unable to perform ANAME target lookup (due to timeout for

Sorry, I might have misinterpreted what you meant by the "optimal
answer" originally. I think we are in agreement that the sibling
address records resolved by the resolver are preferred to the ones
retrieved from the authoritative server to be used as a last resort.

Jan

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Jul 2019 14:12:19 +0000

if HTTPSSVC goes through, i think we can all stop talking about ANAME.