Skip to content

I got a namesilo domain to test and fix this: trailing dots in MX, CNAME, SRV, NS - #8

Open
coolaj86 wants to merge 1 commit into
libdns:masterfrom
coolaj86:fix/trailing-dot-targets
Open

I got a namesilo domain to test and fix this: trailing dots in MX, CNAME, SRV, NS#8
coolaj86 wants to merge 1 commit into
libdns:masterfrom
coolaj86:fix/trailing-dot-targets

Conversation

@coolaj86

Copy link
Copy Markdown
Contributor

The API requires that trailing dots be stripped, but the test was testing with the dot already stripped. This makes sure that trailing dots are normalized for use in the API and comparison.

This specific change is: 6de202c
Stacked on #7 due to the line ending issues.

@maischus

Copy link
Copy Markdown
Collaborator

I am fine with the changes. Do you mind updating the PR to resolve the conflicts?

The Namesilo API rejects FQDNs with trailing dots on hostname targets,
returning: "Field 'Target hostname' should be valid. Please use only
letters (A-Z, case-insensitive), numbers (0-9), and hyphens (-)."

The libdns convention is that callers pass FQDNs with trailing dots
(e.g. "10 mail.example.com."). Every other libdns provider normalizes
trailing dots for its API -- Cloudflare, Namecheap, and NFSN all do
this. The namesilo provider had no such normalization, and its tests
only used CNAME data without trailing dots ("wikipedia.com"), so the
bug was never caught.

This strips trailing dots from:
- MX exchange target (fields[1])
- SRV target (fields[3])
- CNAME, NS, ALIAS, PTR record data
- findRecordId comparison (so DeleteRecords matches stored values)

Adds TestTrailingDotTargets which creates CNAME, MX, and SRV records
with trailing dots on unique subdomain names (testtdcname, testtdmx,
_testtd._tcp), verifies they exist, then deletes them.
@coolaj86
coolaj86 force-pushed the fix/trailing-dot-targets branch from 6de202c to d8a8b49 Compare August 28, 2026 17:48
@coolaj86

Copy link
Copy Markdown
Contributor Author

Done.

If you turn on "fast forward" in the repo settings it (or disable "merge" so that it will fast forward" like normal git), it won't create conflicts between stacked PRs. It always confuses me how GitHub seems to decide at random to turn otherwise compatible branches into conflicts over having the exact same commits.

Not that you'll frequently be dealing with that, but I straight out disable merge on all of mine so I don't have that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants