Subject: [DNSOP] ANAME precedence [issue #58]

From: Matthijs Mekking <[email-masked]>
Date: Wed, 24 Apr 2019 11:44:37 +0200

Hi,

I would like to start separate threads on the remaining issues of the
ANAME draft. One issue that remains to be solved is whether having an A
or AAAA record next to the ANAME should take precedence or not.

  Draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
  Issue: https://github.com/each/draft-aname/issues/58

This was discussed face to face during IETF 101 and at that time the
conclusion was that the correct behavior is that ANAME takes precedence:
If you implement ANAME, the target lookup for A and AAAA will always be
made. If the lookup succeeds, the sibling address records are replaced
with the target address records. If the lookup fails, the sibling
address records remain in the zone.

Jan Včelák mentioned that at least NS1 uses a different order of
priority: If an sibling address record exists next to the ANAME it takes
precedence and no target lookup is done for that address record type.

In order to provide identical behavior between providers (make ANAME
work in the multi-provider model) we should agree on the priority order.

To me, it makes much more sense to use the sibling address record as a
default, and the ANAME target lookup can replace the sibling address
records. The target address records will improve the answer.

If you place an override, adding an address record next to ANAME, you
can achieve the same thing by not placing the ANAME record in your zone
at all.

But when the sibling address records take precedence, it has the
property that you can set up ANAME for only one address type, for
example ANAME for A but not for AAAA. I would like to know if there is a
good use case for having this property.

I would like to hear an opinion from the working group (preferably from
ANAME providers). Specifically do you have a preference of priority
order? Do you think having the "set up ANAME for one address type"
property is worth having?

Thanks,

Matthijs

---

From: 神明達哉 <[email-masked]>
Date: Thu, 25 Apr 2019 11:34:32 -0700

At Wed, 24 Apr 2019 11:44:37 +0200,

>   Issue: https://github.com/each/draft-aname/issues/58
[...]
> precedence and no target lookup is done for that address record type.

Is this choice #2 of the github issue #58?

>> sibling address records take precedence, don't to a target lookup for an
address type next to the ANAME.

I'm not sure what this means...if this approach is taken and an
authoritative server has these for an example.com zone:

a.example.com. ANAME another.example.org.
a.example.com. AAAA 2001:db8::1

then, does it always just return the AAAA RRset to a query for
a.example.com/AAAA, regardless of any possible changes to
another.example.org/AAAA?

How is that AAAA created in the first place?  (Is it taken from
another.example.org/AAAA or completely up to the example.com
maintainer?).

Also, especially if both AAAA and A sibling records are available,
what's the purpose of ANAME in the first place if it's (effectively)
not used?

I'm sure I'm just confused and don't understand the expected usage,
but I can't figure it out from the available descriptions.  Could you
clarify it?

--
JINMEI, Tatuya

---

From: Anthony Eden <[email-masked]>
Date: Thu, 25 Apr 2019 14:41:16 -0400

I've commented on the GH issue directly.

-Anthony

P.S. To everyone involved, thank you for continuing your hard work on this
specification.

On Wed, Apr 24, 2019 at 5:45 AM Matthijs Mekking <[email-masked]>
wrote:

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

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

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 26 Apr 2019 09:16:58 +0200

On 4/25/19 8:34 PM, 神明達哉 wrote:
> Matthijs Mekking <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Correct.

>>> sibling address records take precedence, don't to a target lookup for
> an address type next to the ANAME.
> 
> authoritative server has these for an example.com <http://example.com> zone:
> 
> a.example.com <http://a.example.com>. ANAME another.example.org
> <http://another.example.org>.
> a.example.com <http://a.example.com>. AAAA 2001:db8::1
> 
> a.example.com/AAAA <http://a.example.com/AAAA>, regardless of any
> possible changes to
> another.example.org/AAAA <http://another.example.org/AAAA>?

That is exactly what choice #2 does. But it can do a target lookup for
the A RRset.

> another.example.org/AAAA <http://another.example.org/AAAA> or completely
> up to the example.com <http://example.com>
> maintainer?)..

The AAAA record may initially be added to the example.com zone by the
zone operator. With choice #2 it is not updated by the ANAME (with
choice #1 it is).

> but I can't figure it out from the available descriptions.  Could you

Personally I agree that the purpose of ANAME becomes less useful with
choice #2.  The difference is that you can set up ANAME for example for
AAAA only, or for A only. I don't know what the expected usage of that
is, and that is why I am asking on the list. If it turns out there is no
useful case, I think we should put text in the draft that says ANAME
takes precedence over sibling A and AAAA records.

Best regards,

Matthijs

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Apr 2019 11:29:59 -0700

At Fri, 26 Apr 2019 09:16:58 +0200,

> takes precedence over sibling A and AAAA records.

Okay.  In that case I agree we should go for choice #1 (ANAME should
be preferred) unless the expected usage for choice #2 is clarified and
convinces us (the wg).  Choice #2 looks awkward to me especially if we
consider the case where both AAAA and A siblings exist.

According to your original message choice #2 was derived from the

> precedence and no target lookup is done for that address record type.

if there's a specific use case where this behavior is important,
either the developer or user of this implementation should be able to
clarify that.  At least until we know that I don't see the point of
considering this choice.

--
JINMEI, Tatuya

---

From: Jan Včelák <[email-masked]>
Date: Tue, 30 Apr 2019 11:56:15 +0200

> clarify that.  At least until we know that I don't see the point of

The reason for different processing order in our implementation is
merely historical: ALIAS was intended to solve the problem with CNAME
in zone apex, our customers were familiar with CNAME processing, and
therefore we wanted ALIAS to resemble CNAME closely. CNAME is
practically a fallback record as well. I'm not aware of any specific
use case where such behavior would be required although it's possible
that our customers have developed some use case over the years.

It looks like there is an agreement that ANAME should take precedence
over A/AAAA. That's fine with me. We will figure it out for our
customers.

Jan

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 30 Apr 2019 15:21:18 +0200

Hi,

Jan and everyone else, thanks for your feedback. It feels indeed like we
should continue with the behavior that ANAME will take precedence over A
and AAAA when on the same name. I shall go over the draft and see if the
text is correct in that sense.

Best regards,

Matthijs