Add specification for testing SPF#1146
Conversation
Take the draft specification in the state it was in for pull request \zonemaster#1100 before that PR was closed.
Reduce the scope of this test case by removing all of the tests that involve semantics. In this test case, we will care about the syntax only, in order to simplify the specification.
matsduf
left a comment
There was a problem hiding this comment.
It looks good but I have some minor comments.
* Output extra messages if SPF is inconsistent (Z11_DIFFERENT_SPF_POLICIES_FOUND); * Align the message ID for Z11_SPF1_MULTIPLE_RECORDS with @matsduf’s suggestion for Z11_DIFFERENT_SPF_POLICIES_FOUND.
matsduf
left a comment
There was a problem hiding this comment.
It looks fine, but I have a few comments. Then I can approve.
| :--------------------------------|:--------|:-------------|:-------------------------------------------- | ||
| Z11_INCONSISTENT_SPF_POLICIES | WARNING | | The *Child Zone* publishes different SPF policies on different name servers. | ||
| Z11_DIFFERENT_SPF_POLICIES_FOUND | NOTICE | ns_ip_list | The following name servers returned the same SPF version 1 policy, but other name servers returned a different policy. Name servers: {ns_ip_list}. | ||
| Z11_NO_SPF_FOUND | INFO | | The *Child Zone* does not publish an SPF policy. |
There was a problem hiding this comment.
Looking at this again, is it a problem if SPF policy is missing? Is that against recommendations? Should we raise the level to NOTICE when there is no policy?
Do you see a connection between the existence of MX and existence of SPF for a domain?
There was a problem hiding this comment.
IMHO, not publishing an SPF policy is similar to not signing a zone with DNSSEC: not an error in itself, but maybe something a domain name owner should consider implementing.
The same can be said for DKIM (unless the SPF policy is a so-called “null SPF”, such as v=spf1 -all) and DMARC.
According to my data, on the .fr zone, 62.6% of zones have both MX records and an SPF policy, and 33.2% of zones have no MX at all but an SPF policy. I assume most of these would be “null SPF” policies (i.e. v=spf -all).
There was a problem hiding this comment.
In order to be consistent with the level of the message Zonemaster outputs if there is no DNSSEC signature, I think we can raise the message level for Z11_NO_SPF_FOUND to NOTICE.
Regardless of whether the domain originates mail, it is a good practice to implement SPF:
- if a domain originates mail, specifying the mail servers authorized to send mail on the domain’s behalf is a basic defense against spoofing and even though SPF alone won’t stop all forms of spoofing, it’s required by DMARC;
- if a domain does not originate mail (for example, when it’s a parked domain), then it’s a good practice to publish a “null SPF” policy.
There was a problem hiding this comment.
* if a domain does not originate mail (for example, when it’s a parked domain), then it’s a [good practice](https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bcp-2022-06.pdf) to publish a “null SPF” policy.
In ZONE09 the test case detects Null MX. Is it easy to detect a Null SPF? Should this test case report Null SPF and update ZONE09 to report Null MX?
matsduf
left a comment
There was a problem hiding this comment.
This is fine for implementation. My comment can be handled later.
|
Either way, let’s merge this! |
|
@marc-vanderwal, could you move the specification to the new path? |
Follow-up to zonemaster#1129 and zonemaster#1146
|
Sure, I’ve just created a pull request for that. |
Purpose
This PR adds a simple test case for SPF on a domain under test.
Context
Following up on, and simplifying, PR #1100.
Changes
Adds one test case which tests SPF.
How to test this PR
This is a documentation update.