Point domain name of my zone to name in somebody else's zone?

[Dave Warren]

On 2014-05-08 15:09, Mark Andrews wrote:
> In message <536BCCED.8060002 at hireahit.com>, Dave Warren writes:
>> On 2014-05-08 07:45, Barry Margolin wrote:
>>> In article <mailman.171.1399542062.26362.bind-users at lists.isc.org>,
>>>    Tony Finch <dot at dotat.at> wrote:
>>>
>>>> Dave Warren <davew at 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