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

[Mark Andrews]

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.

CNAME is not and never has been the correct solution for this.  The
problem is that CNAME "works" for www.example.net because only
address records are put at www.example.net.  This covered 99.9% of
use initially.

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.

> Although allowing a CNAME to coexist 
> with NS could have some interesting side effects. There might be 
> backward compatibility issues that make this impossible, but I would 
> hazard a guess that since DNAMEs already return a matching CNAME and 
> nothing explodes, the problems would be minor and limited in scope.
> 
> -- 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org