mirror of
https://github.com/Such-Software/adaptive-multi-protocol-gateway.git
synced 2026-10-17 07:31:32 +02:00
jw
76eb7cfc69
Dynadot's records endpoint returns suchshop.lol's apex MX with record_type "stealth", the mail host in record_value1 and the preference in record_value2. Sending that record back, which any preserve-unmanaged write has to do, is rejected by Dynadot with "Please enter a valid stealth forwarding url looks like this: http://subdomain.example.com". The POST replaces the whole zone, so the rejection takes every other record in the batch with it. Six DMARC report authorizations could not be published for exactly this reason, and no amount of correctness in the manifest would have helped. Confirmed rather than inferred. The apex returns three records, stealth/txt/a, and the apex serves three records, MX/TXT/A. Matching them one to one gives stealth = MX 10 mail.suchshop.lol; the txt and a records match their live values exactly, and there is no fourth record and no forwarding configured. Three separate reads across two days returned the same thing. The correction is narrow because the two shapes cannot overlap. A genuine stealth forward stores a URL in value1 and leaves value2 empty, which is the format Dynadot's own error message asks for. A hostname in value1 with an integer preference in value2 is not a valid stealth record in any configuration, so the reader treats that combination, and only that combination, as MX. The end-to-end read test already carried a copy of this zone and asserted the bogus type was preserved verbatim, calling it "an unusual type is still a record". That assertion described the bug. It now requires the apex to read as MX with its preference intact.