(Starting a new thread so my mailer doesn't sort the new discussion with
messages from November!)
Thanks to Matthijs Mekking for the good summary this morning. I am happy
for someone else to take over editorial/authorship duties on the draft.
There were several useful points at the mic; thanks Paul Hoffman for
noting them in the minutes (especially because I could not remember who
said what). In no particular order...
Petr Spacek said he thought zone transfers are difficult. In earlier
revisions that is true; in the -02 revision there is nothing special about
zone transfers, they are just the same as in the absence of ANAME. All the
work has been moved to how the records get into the zone. (However the
huge "as if" clause allows implementations to do funky things at zone
transfer time if they want, and you won't be able to tell the difference
from outside.)
Matt Pounsett talked about strategies for polling the DNS at scale
efficiently. Timing was something I worried about a lot when writing the
draft, and I probably over-specified it. I eventually concluded that it
isn't possible in many reasonable implementations to avoid significantly
stretching the TTL of the ANAME target address records by copying them to
the ANAME siblings. Maybe the spec should become more relaxed about this,
and make it a quality-of-implementation issue rather than a requirement.
Regarding geoip, ANAME is no worse than manually configured address
records, and it will eventually become better as resolver support is
deployed. Geoip is the main reason for specifying (optional) ANAME support
in resolvers. (I guess another reason might be to more faithfully respect
the target address TTLs...) Resolver support isn't necessary, though,
provided the ANAME target addresses work everywhere. So it might not be
compatible with all existing geoip implementations, but I don't think
that's a bug in ANAME.
Scalability is definitely a challenge. The worst case is when you have a
very large number of zones sharing the same ANAME target, and that changes
address. If ANAME is implemented using existing standard protocol features
(i.e. UPDATE, NOTIFY, IXFR) as specified, then the change of address is
going to cause a huge volume of modification traffic. But the "as if"
clause exists to allow large scale implementations to do clever things to
mitigate this.
On the list, Brian Dickson and Dan York talked about "just as if there was
a CNAME there”. The -02 draft tries to have semantics very close to CNAME,
but there are other interesting possibilities if we relax that
requirement.
What I had in mind for an -03 revision was to remove any requirements
about how the sibling address records are populated. The remaining
requirement is that the sibling addresses must work the same way as the
target addresses, from the point of view of the end user. The sibling
addresses can freely be replaced by the target addresses at any time
(provided whatever is doing the substitution can sign the records when
that is necessary).
This covers both draft -01 and -02 style implementations, and Oracle Dyn's
notion of fallback addresses, and perhaps even vertically integrated
providers that might prefer to direct client to thei own http 302 server
instead of substituting addresses in the DNS. (Though they risk making too
many assumptions about what the point of view of the end user is!)
Dunno if this is a useful direction or not - argue away :-)
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Southwest 3
or 4, occasionally 5 at first, becoming variable 3 or less, then north 4 or 5
later. Smooth or slight, becoming slight or moderate later in north. Fair.
Good.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
