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

[Mark Andrews]

In message <536C0392.3020200 at hireahit.com>, Dave Warren writes:
> 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.

ANAME is service agnostic.  If it exists it should be implemented in
the applications not the nameserver.  A and AAAA should be additional
data.

> > 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)

MX works for wildcards.  SRV doesn't work for wildcards.

"* CNAME <httpserver>" is often used which is why SRV is not
such a good fit.
 
> -- 
> Dave Warren
> http://www.hireahit.com/
> http://ca.linkedin.com/in/davejwarren
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org