I like the ANAME idea and find it overall simple if what we are trying to solve is CNAME at apex. If what is being solved is per service then it is another story. As much as I like it, I find the resolution at the auth nameserver a bad thing for a couple of reasons.
As has been mentioned before: 1) it will add workload on the authoritative nameserver which so far was mostly doing key/value lookups and now may need to either recurse or forward to a recursor. 2) the resolution from such lookup will be wrong for resolver/ecs based answers as you will now get an answer for the recursor at the authoritative site instead of the client (recursor talking to the auth or ECS). While doing per site ANAME resolution may make the answers a bit more accurate, it will definitely not help with operations. if someone want to do the chaining, I guess they could already do it with some tooling on their side which will perform regular lookup and update their zones so essentially making the ANAME resolution an out of band task. If all that was required was to return an ANAME in the additional section, it would be pretty straightforward to implement on the authoritative side and add no complexity there neither workload (or very minimal). On the recursor side, this will most likely heavily reuse the CNAME logic and may not be that complex to implement (implementors may tell otherwise). Recursors that understand ANAMES will be able to treat it as a CNAME and follow the name chain just like for CNAME. If they don't, well nothing has changed for them. It may take time before it gets widely deployed, but it would be a simple solution that could be easily implemented by the auth that are interested in it, gets picked up as the recursors get upgraded and be backward compatible during the transition phase. Manu On Mon, Nov 5, 2018 at 3:35 PM Måns Nilsson <mansa...@besserwisser.org> wrote: > Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at > 04:39:09PM +0000 Quoting Tony Finch (d...@dotat.at): > > It's really good to see more discussion about ANAME. > > I agree. > > > I think a resolver-side or client-side alternative (like the various > > web-specific record types we have been discussing) is defintely soemthing > > we should aim for in the long term, but that isn't what this work is > > about. > > IMNSHO _any_ work on "fixing CNAMES at apex" that gets traction is > a spanner in the works for what we seem to agree is a better solution. > A interim fix will be deployed and stall every attempt at DTRT. > > I am well aware of "perfect being the enemy of good enough" but I'm not > certain DNAME is "good enough". > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE SA0XLR +46 705 989668 > Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS ... > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
