fix(mx): keep null MX and strip trailing dot - #6661
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Coverage Report for CI Build 33159371836Coverage increased (+0.01%) to 82.083%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions14 previously-covered lines in 3 files lost coverage.
Coverage Stats
💛 - Coveralls |
|
Verified end to end against a real PowerDNS in Docker with a kind cluster and the CRD source, comparing DNSEndpoint used: spec:
endpoints:
- dnsName: example.com
recordType: MX
recordTTL: 300
targets: ["10 mail.example.com.", "010 backup.example.com"]
- dnsName: nomail.example.com
recordType: MX
recordTTL: 300
targets: ["0 ."]
Previous head of this branch — trailing dot fixed, still fatal: Current head: PowerDNS rejects a non-canonical MX target server-side, so the whole zone patch fails and the ownership TXT records and the null MX never get written either — not only reconcile churn. Setup follows |
NewEndpointWithTTL trimmed the trailing dot off the whole MX target, turning the null MX "0 ." (RFC 7505) into "0 ", which no longer parses as an MX record. On cloudflare, the CRD source exempts MX from its target format check while the API never returns a trailing dot, so "10 mail.example.com." diffed on every reconcile and getRecordID could not resolve the record to delete.
Trailing dots reached every provider, not just cloudflare. Unparseable targets and the null MX are left as-is.
Render MX targets as "<preference> <host>" in NewEndpointWithTTL and the CRD source, replacing the Cloudflare-only normalization: a single space, no leading zeros on the preference, no trailing dot on the host, with unparseable targets and the null MX "0 ." left alone. PowerDNS rejects a non-canonical target server-side, so the whole zone patch fails rather than merely diffing on every reconcile. Doing this in endpoint covers pdns, google and both Azure providers as well.
a87dc1f to
89e9a3e
Compare
NormalizeMXTarget already renders MX targets undotted before they reach newCloudFlareChange, so the extra trim there did nothing. Revert the helper to its original name and scope: only SRV keeps a trailing dot this far down the write path.
e5bd5e3 to
3bfd8f0
Compare
|
/lgtm |
What does it do ?
NewEndpointWithTTLtrimmed the trailing dot off the whole MX target, turning the null MX0 .(RFC 7505) into0, which no longer parses as an MX record.source/crd.gopassed MX targets through unchecked while every other source normalizes themvia
NewEndpointWithTTL, so a DNSEndpoint with10 mail.example.com.diffed on everyreconcile — on any provider.
It now normalizes instead, leaving unparseable targets and the null MX alone.
Motivation
Follow-up to #6660, split out per review.
More