On 31 Mar 2017, at 1:08, John Levine wrote:
If you sign offline, what happens when the A records change?
You Lose(tm). For that matter, you lose even when the A records don't
change since the signer only sees the ANAME, not the A or AAAA.
There are PowerDNS ALIAS deployments that signs offline (for some
stretch of the definition of offline) - every minute. For small zones
the NOTIFY+XFR overhead is very tolerable, and the public auths do not
need the private key data.
Obviously, whatever way you sign, you would make sure the signer sees
the A/AAAA RRsets, otherwise you have nothing.
This lets me do things that regular ANAME can't, in particular
shadowing data from a server that is not authoritative for the zone.
My users often host their web sites at hosting providers that insist
you use their name servers, except that they don't provide usable mail
so I have to do the mail and DNS. On my server, the aname-like things
can specify what server to query as well as what name, so it
automatically follows the A and AAAA records that the web host
publishes in their DNS.
You could point your ANAME-aware auth at a specific resolver that has
stub zones configured for those domains, and then this would work with
ANAME as well.
My objection to ANAME is more or less the same as it is to BULK, even
though ANAME is vastly less complex. It requires that an
authoritative server include a recursive client and do online signing,
both of which would be rather large additions to the mandatory set of
server features.
Recursive clients are easy - your libc/libresolv comes with one. Live
signing is not mandated if you can tolerate frequent XFRs. And, of
course, any auth implementer is free to not implement ANAME if he does
not like the requirements.
I think it'd be fine to reserve ANAME as a pseudo-rrtype so that
people can do the name following magic consistently in their
provisioning
software, but I wouldn't want to put it into DNS servers.
Yet the operational reality is that several big DNS hosters have it
today, and I am aware of a few private PowerDNS ALIAS deployments as
well. It’s obvious the need is real, and people today rely on ALIAS
being transferred in AXFR without in line expansion. Anthony’s draft
documents existing widespread practice. The upcoming replacement draft
by Evan, Anthony and me adds some improvements to it, including details
that may, if resolver operators cooperate, reduce the need for
online/live signing in the future.
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
