Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Matthew Pounsett <[e-mail]>]

On 13 April 2018 at 11:11, bert hubert <[e-mail]> wrote:

> > >1) chase CNAMEs that point to another zone
> > >2) look for glue outside of the zone
> >
> > 1) What was the historical text that indicated that an authoritative
> server
> > should chase CNAMEs before responding? This worries me.
>
> 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?

Let's say you're a DNS hosting company and I get you to host example.com
for me, and delegate it to your servers.  For some good, but obscure reason
I have:
update.example.com IN CNAME update.microsoft.com.

An attacker comes along and asks you to host microsoft.com, which is not
delegated to you.  They have:
update.microsoft.com IN CNAME attack.badguy.com.

If you follow CNAME chains outside the zone (but inside the "authoritative"
zones in your server) then you have just participated in redirecting a
CNAME chain away from where it's supposed to go.  Either recursive servers
will trust your supplied CNAME chain and their users will be attacked, or
they will (rightly) not trust you and go look up update.microsoft.com
themselves, which, in which case you have wasted resources looking it up in
your own.