On 14 Apr 2017, at 22:03, John Levine wrote:
In article <05429b5d-904b-4913-9843-654c917de...@powerdns.com> you
write:
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.
Seems to me that it belongs in the answer section, since for
aname-aware
reasolvers the aname is the answer.
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.
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.
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,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
