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