Hey Matthijs, On 12 Jun 2019, at 04:11, Matthijs Mekking <matth...@pletterpet.nl> wrote:
> 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. I also think that is worth testing. If that's a widespread behaviour in the deployed infrastructure. > This motivates me to write down that the ANAME should go in the answer > section for address type queries. That seems like the right thing to write down. >> 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. I agree. Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
