Closed mejofi closed 5 months ago
Interesting one. Thanks for the report.
I have updated the check to filter to only SPF records. I wasn't aware that the CNAME record would be returned when quering for SPF records.
This passes for your domain now.
I've set up a test domain (subdomain-with-spf-record.b5n.sh
) that has an SPF record to test the failure.
> python3 -m ready.ready subdomain-with-spf-record.b5n.sh --request-filter=dns --check-filter=spf
Domain: subdomain-with-spf-record.b5n.sh, Domain (no path): subdomain-with-spf-record.b5n.sh, First Level Domain: b5n.sh
[FAIL] SPF DNS record is depreciated and should not exist (['"v=spf1 -all"'])
I don't mind the idea of following the CNAME chain but it's probably slightly out of scope for this check. Someone using this tool could manually check their CNAME domain for the bad SPF record.
FYI - the other SPF checks do recursively follow includes.
Just noticed a typo in this check, by the way; 'depreciated' != 'deprecated'. Shall I file this as a separate issue?
Ooops. That's a typo / mistake that haunts me for some reason. Whenever I go to type deprecated, depreciated comes out if I'm not careful.
Yeah, it's sneaky one 😄
Version: 1.2.1
It looks like the
SPF DNS record is depreciated and should not exist
test fails if it encounters a CNAME, such as when a subdomain lookup yields a CNAME response instead of A/AAAA records.I would expect this to result in either an additional lookup, following the CNAME chain until it yields a definitive response, or to recognise it as the wrong answer, perhaps checking if it's properly formatted, such as starting with
v=spf1
?Example: when testing 'www.ur.nl', it fails with the following error;
The answer makes sense, since it is the CNAME record;