On 2014-05-08 15:09, Mark Andrews wrote:
In message <536bcced.8060...@hireahit.com>, Dave Warren writes:
On 2014-05-08 07:45, Barry Margolin wrote:
In article <mailman.171.1399542062.26362.bind-us...@lists.isc.org>,
Tony Finch <d...@dotat.at> wrote:
Dave Warren <da...@hireahit.com> wrote:
DNSMadeEasy calls this an "ANAME" record, internally they just lookup the
destination's IP and cache it, updating it as needed.
It works, but it would be nice if this could be done in DNS. Sadly, it
can't,
and probably won't in our lifetimes.
Never say never :-)
You can implement something ANAME-alike with a script that polls the
A and AAAA records at the target name and does a DNS UPDATE on the owner
as necessary, but that might not scale too well.
There are a couple of difficulties with implementing ANAME inside the
server.
Firstly it implies a weird authoritative/recursive hybrid. A bit ugly but
not unreasonable.
Secondly, and more importantly, is the question of how this works with
zone transfers and secondaries. How do you ensure they support ANAME
records? Do you include a backwards compatibility hack by adding the A and
AAAA records to the zone?
It also has adverse implications for DNS-based CDN routing, e.g. Akamai.
Everyone will be routed to the servers close to the auth servers of the
domain containing the ANAME, instead of routing each end user to their
closest servers.
Indeed. Were such a thing implemented, I'd think it would be smart to
have the authoritative server return both the ANAME and A records,
allowing a compliant resolver to do it's own A record lookup to find an
appropriate CDN endpoint, while older resolvers with no concept of ANAME
would simply ignore it and use the (possibly-less-than-optimal) A record.
Arguably adjusting CNAME to allow it to coexist with other record types
might be a better long-term solution, perhaps allowing CNAME to coexist
with SOA, NS and DNAME records?
But that does not help when you want a MX record at the apex or
some other record at the apex.
I'd argue that it does -- Since the record is now CNAME'd, the MX record
is now under the control of the destination of the CNAME record and MX
records can still be set. This is no different than if I CNAME'd
dog.example.com to cat.example.com, email to @dog.example.com will flow
to the MX records of cat.example.com.
Not ideal? Well no, it's not. Don't use a CNAME if you don't want to
delegate everything, instead use a HTTP/HTTPS level redirect to www.
which is properly distributed.
ANAME records might be more flexible, but since they require
authoritative servers to gain resolver-like capabilities to provide
backward compatible A-records, I believe that the concept will be a
non-starter outside of proprietary solutions that just update A records
dynamically.
SRV or a HTTP specific record like MX is the correct solution.
However it requires browser vendors to be on board change the initial
lookup and then fallback to A/AAAA if the record does not exist.
Agreed, and I touched upon this in one of my earlier replies. I wish you
the best of luck pushing the world toward using SRV records; it would
solve a lot of problems, but they seem to scare too many people.
I actually think that MX records were a boneheaded thing to do, had
email started using SRV records in the first place we might be in a
position now where using SRV records is the defacto standard if not the
actual standard for all services. (No offense to the folks that made MX
records happen, I realize that in historical context it was the correct
decision and it solved the very immediate problem -- I'm just saying
that in an ideal world, SRV records instead of MX records would solved
the same problem in a more generic fashion, and would have pushed us to
a better place for other protocols)
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
