Subject: [DNSOP] ANAME in answer or additional section [issue #62]

From: Matthijs Mekking <[email-masked]>
Date: Tue, 11 Jun 2019 10:31:55 +0200

All,

While working on the next version of the ANAME draft, one additional
question came up: When querying for A or AAAA, we want to include the
ANAME in the response as a signal to anticipate aliasing.  Should we
include the ANAME record in the answer section or the additional section?

The main argument for putting it in the additional section is that given
the experience with DNAME, putting the ANAME in the answer section there
is a risk of interop problems (because there is an unexpected record in
the answer section).

The main argument for putting it in the answer section is that putting
it in the additional section implies a lower trust level, and that the
record is optional and can be removed when minimizing responses.

Does the working group have any thoughts on this?

Issue is tracked here: https://github.com/each/draft-aname/issues/62

Best regards,

Matthijs

---

From: Bob Harold <[email-masked]>
Date: Tue, 11 Jun 2019 08:53:30 -0400

> Issue is tracked here: https://github.com/each/draft-aname/issues/62

If the camel was not already overloaded, then a cautious approach might be
to put it in the additional section, *unless* there was a capability signal
in the request that indicated that the requester would understand ANAME, or
at least not have a problem if it were in the answer section.   I am
guessing that the capability signal would be some EDNS option, or perhaps
an EDNS version.  Is that reasonable?

-- 
Bob Harold

---

From: "Michael J. Sheldon" <[email-masked]>
Date: Tue, 11 Jun 2019 17:07:00 +0000

On 6/11/19 5:53 AM, Bob Harold wrote:
> 
> If the camel was not already overloaded, then a cautious approach might
> be to put it in the additional section, *unless* there was a capability
> signal in the request that indicated that the requester would understand
> ANAME, or at least not have a problem if it were in the answer section. 
>  I am guessing that the capability signal would be some EDNS option, or
> perhaps an EDNS version.  Is that reasonable?

An EDNS capabililty signal would allow the ANAME to be sent in the
answer bare, no accompanying A/AAAA needed.

In absence of that signal, the authoritative *could* return the ANAME in
the additional, but not sure if there would be much value to it,
assuming the signal was standard behaviour.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com

---

From: Evan Hunt <[email-masked]>
Date: Wed, 12 Jun 2019 00:04:59 +0000

> record is optional and can be removed when minimizing responses.

I'm inclined to favor this argument (probably unsurprisingly, since I'm the
one who argued it).

IMHO, the ANAME is the real answer we're sending; the A and AAAA records
are just friendly hand-holding for legacy servers.  It doesn't make sense
to me to demote the real answer into the additional section, any more than
it would have to move DNAME there. The protocol specificaions are clear on
this point - the more so considering we've already deployed DNAME - and my
sympathies for an implementation that got it wrong would be limited.

That said, if any resolver implementations are known to choke if they see
an unexpected extra RRset in the answer section, it would be good to find
out about it. I guess we should do some testing.

Hm, stub resolvers might be stupider than full resolvers. Perhaps it
would be useful to differentiate RD=0 and RD=1?

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

---

From: Anthony Eden <[email-masked]>
Date: Tue, 11 Jun 2019 20:11:51 -0400

I'm a fan of Michael's suggestion of using EDNS to signal that the
authoritative should return ALIAS vs synthesizing. Any reason this won't
work?

-Anthony

On Tue, Jun 11, 2019 at 8:05 PM Evan Hunt <[email-masked]> wrote:

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

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

---

From: Joe Abley <[email-masked]>
Date: Tue, 11 Jun 2019 18:34:58 -0700

On Jun 11, 2019, at 20:04, Evan Hunt <[email-masked]> wrote:

> MHO, the ANAME is the real answer we're sending; the A and AAAA records

I think DNAME provides a useful example. I think emulating DNAME's
demonstrated success in both being tolerated and interpreted correctly
is useful.

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 11 Jun 2019 19:41:37 -0700

On Jun 11, 2019, at 20:11, Anthony Eden
<anthony.eden=[email-masked]> wrote:

> I'm a fan of Michael's suggestion of using EDNS to signal that the authoritative should return ALIAS vs synthesizing. Any reason this won't work?

It won't work unless it's implemented. On a grand scale, then, it
won't work unless it's implemented everywhere. The combined lifting of
implementation, Interop and deployment is significant; is it worth it?

Joe

---

From: Brian Dickson <[email-masked]>
Date: Tue, 11 Jun 2019 20:09:19 -0700

> demonstrated success in both being tolerated and interpreted correctly

I agree that there is much from DNAME that can be useful to learn from.

I think it helps to articulate what DNAME did, and why it worked (well, and
at all):

DNAME returned both DNAME and synthesized CNAME records, for queries
received below the DNAME "cut" (query longer than the matching label for
the DNAME).
When a recursive queried an authority server, if it got back a DNAME but
did not understand it, it ignored the DNAME but processed the CNAME (as if
only the CNAME existed) (plus any other data like chained CNAMEs or A/AAAA
records)
When a client queried a recursive, there were two possible kinds of
recursive: DNAME-aware, and DNAME-unaware. The same general answers were
received, modulo the presence of the DNAME.
If the client received, and understood, DNAME, it was effectively the same
as if no CNAMEs had ever been sent or cached. If the client did not
understand DNAME, then it would ignore any DNAME, and use the CNAME -- at
that point, the question of whether the resolver spoke DNAME was more or
less moot.

The elegance of this was due to the fact that a synthesized CNAME was
compatible with the namespace structure which might include a DNAME, as
well as additional CNAMEs and/or DNAMEs.

All of this is unfortunate, because of the fact that there is no genuinely
backward compatible record similar to ANAME that can be used, without a
very strong likelihood of breaking things.
>From authority to recursive: You can't return an ANAME and a CNAME (as a
backward-compatible rewrite signal that corresponds to the ANAME), since
the CNAME will effectively obscure other RRTYPEs that might coexist (e.g.
at the zone apex).
>From recursive to client: An ANAME-aware resolver can maybe return a
fully-resolved A/AAAA record, along with an ANAME (optionally with
additional ANAME/CNAME/DNAME records chained) -- but I think testing this
would strongly be advised.

So, I suspect having the ANAME in the Answer section is worth experimenting
(and the history of DNAME suggests it would not break badly).

The real problem here, is the "other" record for backward compatibility
isn't a rewrite-type (such as CNAME or DNAME), but is a "promoted" A/AAAA
record of potentially limited utility and questionable provenance (due to
geo-ip stuff, TTL stuff, and RRSIG problems).

Brian

---

From: Evan Hunt <[email-masked]>
Date: Wed, 12 Jun 2019 06:42:01 +0000

> authoritative should return ALIAS vs synthesizing. Any reason this won't

Not that I can think of, but it adds significant implementation complexity
in order to solve a problem that I'm not at all sure we have.

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 12 Jun 2019 09:59:52 +0200

> implementation, Interop and deployment is significant; is it worth it?

Is it worth it? No IMHO.

Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 12 Jun 2019 10:11:47 +0200

Brian,

Thanks for the detailed background on why DNAME worked. There are a few
things that caught my attention:

> When a recursive queried an authority server, if it got back a DNAME
but did not understand it, it ignored the DNAME but processed the CNAME
(as if only the CNAME existed) (plus any other data like chained CNAMEs
or A/AAAA records)

Following this logic, this suggests that having an ANAME in the answer
section, together with the requested A or AAAA records, the resolver
most likely will ignore the ANAME and use the A/AAAA records.

> All of this is unfortunate, because of the fact that there is no
genuinely backward compatible record similar to ANAME that can be used,
without a very strong likelihood of breaking things. From authority to
recursive: You can't return an ANAME and a CNAME (as a
backward-compatible rewrite signal that corresponds to the ANAME), since
the CNAME will effectively obscure other RRTYPEs that might coexist
(e.g. at the zone apex).

This is fine, because that is not what we want: We would like to add the
ANAME in the answer section with the A/AAAA records (not a CNAME).

> So, I suspect having the ANAME in the Answer section is worth
experimenting (and the history of DNAME suggests it would not break badly)..

This motivates me to write down that the ANAME should go in the answer
section for address type queries.

> The real problem here, is the "other" record for backward
compatibility isn't a rewrite-type (such as CNAME or DNAME), but is a
"promoted" A/AAAA record of potentially limited utility and questionable
provenance (due to geo-ip stuff, TTL stuff, and RRSIG problems).

I actually see the A/AAAA record as the backward compatibility records:
An ANAME-aware resolver would understand the ANAME and can act upon it,
an ANAME-unaware resolver will use the A/AAAA records that the
authoritative returned.

Best regards,

Matthijs

On 6/12/19 5:09 AM, Brian Dickson wrote:
> 
> 
> On Tue, Jun 11, 2019 at 6:35 PM Joe Abley <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On Jun 11, 2019, at 20:04, Evan Hunt <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> I think it helps to articulate what DNAME did, and why it worked (well,
> and at all):
> 
> did not understand it, it ignored the DNAME but processed the CNAME (as
> if only the CNAME existed) (plus any other data like chained CNAMEs or
> A/AAAA records)
> If the client received, and understood, DNAME, it was effectively the
> same as if no CNAMEs had ever been sent or cached. If the client did not
> understand DNAME, then it would ignore any DNAME, and use the CNAME --
> at that point, the question of whether the resolver spoke DNAME was more
> or less moot.
> 
> All of this is unfortunate, because of the fact that there is no
> genuinely backward compatible record similar to ANAME that can be used,
> without a very strong likelihood of breaking things.
> the CNAME will effectively obscure other RRTYPEs that might coexist
> (e.g. at the zone apex).
> additional ANAME/CNAME/DNAME records chained) -- but I think testing
> this would strongly be advised.
> 
> So, I suspect having the ANAME in the Answer section is worth
> experimenting (and the history of DNAME suggests it would not break badly)..
> 
> isn't a rewrite-type (such as CNAME or DNAME), but is a "promoted"
> A/AAAA record of potentially limited utility and questionable provenance
> (due to geo-ip stuff, TTL stuff, and RRSIG problems).
> 
> Brian
>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Jun 2019 10:50:27 -0700

> an ANAME-unaware resolver will use the A/AAAA records that the

So, this is where the analogy to DNAME diverges from reality of ANAME, and
IMHO is the the crux of one of the main problems with ANAME.

In the DNAME/CNAME example, the A/AAAA records are returned ONLY IF the
server that is authoritative for the DNAME is also authoritative for the
DNAME "target" (right-hand-side/RDATA).
If the DNAME auth server is not, it will only return DNAME+CNAME records.

The only "legitimate" (in my opinion) reason that the ANAME authoritative
server should also return A/AAAA records, is if it is also authoritative
for the ANAME "target" (right-hand-side/RDATA).

(And the reason that having the ANAME authoritative server obtain and
return A/AAAA records itself leads to what I called:

> potentially limited utility and questionable provenance (due to geo-ip
> stuff, TTL stuff, and RRSIG problems).
>

I have elaborated on this problem previously, but will do so again for
completeness/context:

   - There can be differences (possibly significant differences) in the
   results returned for resolution of the "target" between the ANAME
   authoritative server, and the querying resolver.
      - E.g. Any sort of "stupid DNS tricks" that return different values
      based on either physical topology (anycast instance) or geo-ip
      (client-subnet)
      - That discrepancy can direct clients to a suboptimal server, where
      suboptimal can even be, from a user perspective, badly broken (e.g. wrong
      language, illegal content, etc.)
   - The interactions on TTLs and the need for repeated lookups can have
   adverse impacts on both clients, resolvers, and auth servers
      - An auth server might want to use longer TTLs to reduce query
      volume, for ANAME values that do not change frequently (A/AAAA TTL set to
      same as ANAME TTL)
      - The original A/AAAA TTL (for the "target" owner name's A/AAAA
      RRDATA) might be short because it changes frequently (e.g. CDNs)
   - If the "sibling" data is only a hint, non-upgraded resolvers will
   serve A/AAAA records that are either poor (longer latency, higher loss),
   wrong (incorrect language due to wrong CDN node), broken (long TTL -> wrong
   server), or slow (requery required)

I don't have a better suggestion on how to fix this within the context of
ANAME; IMNSHO it is an intractable issue, a fundamental problem with ANAME
if sibling records are required.

Brian

---

From: Joe Abley <[email-masked]>
Date: Thu, 13 Jun 2019 14:06:30 -0400

Hey Matthijs,

> most likely will ignore the ANAME and use the A/AAAA records.

I also think that is worth testing. If that's a widespread behaviour in the deployed infrastructure.

> section for address type queries.

That seems like the right thing to write down.

> an ANAME-unaware resolver will use the A/AAAA records that the

I agree.

Joe

---

From: Bob Harold <[email-masked]>
Date: Thu, 13 Jun 2019 16:50:54 -0400

On Thu, Jun 13, 2019 at 1:50 PM Brian Dickson <[email-masked]>
wrote:

>       suboptimal can even be, from a user perspective, badly broken (e..g. wrong

I see two main cases:

   - ANAME replaces a CNAME record, so that other records can be attached
   to the same name. I don't think this is likely to be a big use case. In
   this case, all your concerns apply.

   - ANAME replaces A/AAAA records, most likely at a zone apex, where CNAME
   was desired but not allowed. I think this is the main case for ANAME. And
   in this case, the old A/AAAA records are returned as previously, but with
   the added ANAME record. Your concerns only apply if they already applied to
   the A/AAAA records - nothing has gotten any worse.

Is there another major case I am missing?

-- 
Bob Harold

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Jun 2019 15:33:58 -0700

On Thu, Jun 13, 2019 at 1:51 PM Bob Harold <[email-masked]> wrote:

>
> On Thu, Jun 13, 2019 at 1:50 PM Brian Dickson <
> [email-masked]> wrote:
>
>>
>>
>> So, this is where the analogy to DNAME diverges from reality of ANAME,
>> and IMHO is the the crux of one of the main problems with ANAME.
>>
>>       - E.g. Any sort of "stupid DNS tricks" that return different
>>       values based on either physical topology (anycast instance) or geo-ip
>>       (client-subnet)
>>       - That discrepancy can direct clients to a suboptimal server,
>>       where suboptimal can even be, from a user perspective, badly broken (e..g.
>>       wrong language, illegal content, etc.)
>    - ANAME replaces A/AAAA records, most likely at a zone apex, where
>    CNAME was desired but not allowed. I think this is the main case for ANAME.
>    And in this case, the old A/AAAA records are returned as previously, but
>    with the added ANAME record. Your concerns only apply if they already
>    applied to the A/AAAA records - nothing has gotten any worse.
>

Yes, ANAME placed at apex, where no A/AAAA exists or existed. Typically
when there is a "www" CNAME, and the zone owner wants to make a "magic apex
CNAME" that points the same place as "www" currently does.

I think that (addition of ANAME) is going to be 95% of the deployments,
versus a 5% migration of already-existing proprietary RRTYPEs or
pseudo-types (vertical integration) to ANAME. (If those weren't the
expected levels of deployment, I don't the the efforts on ANAME would be
worthwhile.)

Brian

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 14 Jun 2019 08:59:55 +0200

Brian,

On 6/13/19 7:50 PM, Brian Dickson wrote:
> 
> 
> On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Brian,
> 
> The only "legitimate" (in my opinion) reason that the ANAME
> authoritative server should also return A/AAAA records, is if it is also
> authoritative for the ANAME "target" (right-hand-side/RDATA).

I disagree.  I do think an authoritative should be careful when doing a
target lookup and not recklessly replace its sibling records. But this
is all about how much trust you have in your ANAME resolution.

>     potentially limited utility and questionable provenance (due to
>   * There can be differences (possibly significant differences) in the
>       o E.g. Any sort of "stupid DNS tricks" that return different
>         values based on either physical topology (anycast instance) or
>         geo-ip (client-subnet)>       o That discrepancy can direct clients to a suboptimal server,
>         where suboptimal can even be, from a user perspective, badly
>         broken (e.g. wrong language, illegal content, etc.)>   * The interactions on TTLs and the need for repeated lookups can have
>       o An auth server might want to use longer TTLs to reduce query
>         volume, for ANAME values that do not change frequently (A/AAAA
>         TTL set to same as ANAME TTL)
>       o The original A/AAAA TTL (for the "target" owner name's A/AAAA

I agree with these issues, but I also think they are solvable with some
trickery. Perhaps some words in a Considerations section about that make
sense.

>   * If the "sibling" data is only a hint, non-upgraded resolvers will
>     serve A/AAAA records that are either poor (longer latency, higher
>     loss), wrong (incorrect language due to wrong CDN node), broken
>     (long TTL -> wrong server), or slow (requery required)

The sibling data is not a hint, it is the actual answer that the
authoritative hands out for address queries. The ANAME target lookup
process is replacing the sibling address records with the target values.

Best regards,

Matthijs

> I don't have a better suggestion on how to fix this within the context
> of ANAME; IMNSHO it is an intractable issue, a fundamental problem with
> ANAME if sibling records are required.
> 
> Brian

---

From: Bob Harold <[email-masked]>
Date: Fri, 14 Jun 2019 08:19:20 -0400

On Thu, Jun 13, 2019 at 6:34 PM Brian Dickson <[email-masked]>
wrote:

>>>    - The interactions on TTLs and the need for repeated lookups can
>>>    have adverse impacts on both clients, resolvers, and auth servers
>>    - ANAME replaces a CNAME record, so that other records can be
>>    attached to the same name. I don't think this is likely to be a big use
>>    case. In this case, all your concerns apply.
>>
>>

But in that case, the ANAME (with A/AAAA records) is a new addition, and
not worse that not having anything there.  I don't have any data, but I
expected that most cases would already have A/AAAA at the apex.

Does anyone have data on how many "www" names have or do not have A/AAAA
data for the label without the "www"?

-- 
Bob Harold

---

From: Thomas Peterson <[email-masked]>
Date: Fri, 14 Jun 2019 14:14:15 +0100

I don't believe this answers your question directly, however late last 
year I performed some analysis[0] that showed that 64.17% of the Alexa 
Top 1 million domains I had queried for www records returned CNAME 
records that pointed to apex A records. If it is of use for this work I 
could re-run this and give you up-to-date information that answers this 
fully.

Regards

0: https://thpts.github.io/a_or_cname/analysis/ietf-dnsop-2018-11-21/

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Jun 2019 13:42:36 +0100

> is a risk of interop problems (because there is an unexpected record in

I think ANAME will cause too many problems if it puts unexpected records
in the answer section. Speaking as an ANAME proponent, the reason ANAME
is such a hack is for compatibility with the installed base, and it will
be annoying if it isn't actually compatible and we have to wait another
10+ years to be able to use it without worries.

We (mostly Chris Thompson) deployed DNAME in the reverse DNS in 2010 (the
DNAME specification was published in 1999) and we observed at least two
annoying interoperability problems:

* glibc chattering noisily in syslog (fixed only 2 years ago)
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b9b026c9c00db1a1b5b4a3caa28162655a04a882

* mail delivery failures - MTAs typically have their own DNS message
handling code which is often super careful

I expect that there will be several more interestingly problematic
DNAME failures in the forward DNS.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Gibraltar Point to North Foreland: Variable, mainly southwesterly 3 to 5,
occasionally 6 in south. Smooth or slight, occasionally moderate in south.
Showers then fair. Good, occasionally moderate at first.