Open klaus-nicat opened 3 years ago
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.
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.
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?
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.
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.
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.
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.
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.
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.
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: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
Steps to reproduce
Expected behaviour
Actual behaviour
;; ANSWER SECTION:
Other information