CNAMEs should not be followed when out of bailiwick

[klaus-nicat]

• Program: Authoritative
• Issue type: Bug report

Short description

PowerDNS does not just return CNAMEs, but tries to follow the CNAME as far as possible. For example: autodiscover.example.com. CNAME autodiscover.microsoft.com. For such a RR, PowerDNS will search the backends for autodiscover.microsoft.com and, if found, adds the result to the response. For example, the response may look:

;; ANSWER SECTION:
autodiscover.example.com.   60      IN      CNAME   autodiscover.microsoft.com.
autodiscover.microsoft.com. 60      IN      A       6.6.6.6

As the CNAME target is out of bailiwick a resolver must not accept the additional A record. Otherwise the resolvers cache could be poisened.

As there is no reason to follow such out of bailiwick CNAME targets, PowerDNS should not do it.

Hence, instead of blindly following all CNAMEs, PowerDNS should check if the CNAME target is within the currently used zone (this information should be available where PowerDNS follows CNAMEs). If yes, follow the CNAME; if no, stop following the CNAME.

Environment

• Operating system: Ubuntu 18.04
• Software version: PDNS 4.2, PDNS 4.4
• Software source: self compiled

Steps to reproduce

example.com.   SOA ...
autodiscover.example.com.   CNAME   autodiscover.microsoft.com.
microsoft.com. SOA ...
autodiscover.microsoft.com. A       6.6.6.6

Expected behaviour

;; ANSWER SECTION:
autodiscover.example.com.   60      IN      CNAME   autodiscover.microsoft.com.

Actual behaviour

;; ANSWER SECTION:

autodiscover.example.com.   60      IN      CNAME   autodiscover.microsoft.com.
autodiscover.microsoft.com. 60      IN      A       6.6.6.6

Other information

[mnordhoff]

As a data point, Knot DNS follows CNAMEs within the current zone, but does not follow them to other zones.

I believe it's not configurable.

IIRC, it had some different behavior years ago.

[mind04]

Cache poisoning is no issue in modern resolvers. And the performance impact is extremely limited for the authoritative server since the entire answer is cacheable (positive and negative). It could houwever save a few roundtrips when the answer is signed.

[Habbie]

It could houwever save a few roundtrips when the answer is signed.

I was also pondering this - do any resolvers accept signed things out of bailiwick? If not, should they?

[klaus-nicat]

Cache poisoning is no issue in modern resolvers. And the performance impact is extremely limited for the authoritative server since the entire answer is cacheable (positive and negative).

Indeed. Let's put random data into the response as resolvers will ignore it anyways and it does not cost much CPU adding those data. ;-)

It could houwever save a few roundtrips when the answer is signed.

That might be a valid usecase.

[Habbie]

Indeed. Let's put random data into the response as resolvers will ignore it anyways and it does not cost much CPU adding those data. ;-)

Sarcasm is not a useful communication format.

[peterthomassen]

Sarcasm is not a useful communication format.

But it's a fun one ;-) (At least sometimes, and depending on subjective perception.)

Cache poisoning is no issue in modern resolvers. And the performance impact is extremely limited for the authoritative server since the entire answer is cacheable (positive and negative). It could houwever save a few roundtrips when the answer is signed.

An issue could arise is someone hijacks another customer's CNAME target and puts a very large rrset there. Perhaps resolvers couldn't be convinced to trust that additional data, but the extra data could be so that packet lengths are exceeded, which can have DoS-like impact in some (pathological?) network environments. I don't know if problems like #11804 could also be triggered.

As a general precaution, it seems reasonable to me that the response size and implications would not be affected by another customer's out-of-bailiwick zone contents.

[mnordhoff]

What about related zones?

E.g. example.com and foo.example.com are zones, should a CNAME from bar.example.com to bar.foo.example.com be followed?

Or if foo.example.com and bar.example.com are zones, and there's a CNAME from baz.foo.example.com to baz.bar.example.com?

They're may or may not be managed by the same customer, and a resolver is likely to be unaware of the zone cut and trust the records.

[peterthomassen]

Without extra data (like user management information), you never know where the organizational boundaries are. Therefore, the concept of "relatedness" seems flawed to me.

Take example and com as placeholder labels which could be anything else (like co and uk). The situation is then structurally the same for bar.co.uk and bar.foo.co.uk -- two entirely unrelated domain names. It's similar with the other example you gave.

There is no number of labels below which you can safely assert that an organizational boundary does not exist, so it's better to make no assumptions.

---

This is not to say that CNAMEs can't be followed. If we think that all resolvers cope well with it and amplification is not an issue, it may be an okay thing to do. My point is only that the idea of "relatedness" does not play in favor doing that. If CNAMEs are followed, it should be done for other reasons.

[klaus-nicat]

Any news on this? I was just hit by this again, as an old version of the zone of the CNAME target was also configured on the same PDNS. I even would prefer to have "follow-CNAMEs" as an config option and turn it off completely if follow-cname-only-within-zone is too complicated.