On Wed, 19 Apr 2017, Peter van Dijk wrote:
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.
But the implementation really seems to do two things. Bundle A/AAAA with other records and providing a level of indirection. By combining these we are really adding a whole new type of behaviour to the DNS that could be avoided.
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.
Which is why I don't agree with this. ANAME could just be a regular RRTYPE without any special handling, meaning "go look there for up to date information on A/AAAA". It could come along A/AAAA records using one of the existing bitmaps multi-type query proposals that have been suggested in the last two years. Prepopulating or updating the A/AAAA records on the auth server should also be a separate issue/draft and ideally not need the auth server to require either recursion or validation. A new type of authenticated XFR query seems to make more logical sense to me. It would also allow much stricter firewalling on the auth server. It seems dnsop is more and more getting these arguments of "but we are just documenting existing behaviour", like with client-subnet and RPZ. It's really not the best way to develop new DNS extensions, as I also argued when we talked about RPZ. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
