On 4/13/18, 15:02, "DNSOP on behalf of Matthew Pounsett" <mailto:dnsop-boun...@ietf.org on behalf of mailto:m...@conundrum.com> wrote:
>On 13 April 2018 at 11:11, bert hubert <mailto:bert.hub...@powerdns.com> wrote: >>RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that in step 2 we look up the best zone again for the target of the CNAME. I have not looked if newer RFCs deprecate this or not. So with 'chase' I mean, consult other zones it is authoritative for. There might be millions of these btw, operated by other people. >Wouldn't there be a security concern with doing that? Certainly. And you just woke up a hole I've seen but not realized. A name server may be properly authoritative (legit?) for a zone - meaning that somehow, when consulting the (grand)parent of the zone on another server, you can manage to get to the zone. (The wording here is hairy as I'm accounting for cases where the NS sets above the cut and below the cut aren't the same, having some overlap. Yes, that's broken, but it works.) Name servers may also be configured to host zones they "ought not" (ill-legit) - such as a zone of an exited customer of a DNS hosting service. I know this could happen in multi-tenant hosting providers who don't check whether their customers are registered "owners" of the zones the customer configures. Or forget to clean up after departed customers. If a name server CNAME chases from a "legit" zone to an "ill-legit zone" things could get interesting, especially when debugging. I have thought, for a very long time, "chasing" of any DNS "rewrite rule" is wrong - CNAME or DNAME. Leave the query gymnastics to the DNS iterator, the trust policy ought to be homed at the searcher's end. But that is just opinion... Oh, I meant to say - the above opinion I had when I worked for a hoster. Since the hoster charged by query volume, if I had made that public I'd be accused of trying to raise revenue artificially. But as a protocol analyst, I think that a few more queries is worth the simplicity...but you can argue "round trips" and all latency problems...but then I'd argue "that's what caching is for... _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
