In message <536c0392.3020...@hireahit.com>, Dave Warren writes: > 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.
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: ma...@isc.org _______________________________________________ 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
