CNAME, SRV, and MX records are exported without trailing full stops.
HaxNobody opened this issue · comments
Issue type
Bug report
cli53 version (cli53 --version)
0.8.8
OS / Platform
Windows amd64
Steps to reproduce
Export a zone from Route53 like so:
cli53.exe export zonename.com >zonename.txt
Expected behaviour
The export of CNAME, MX, and SRV records, etc should end with a full stop.
Actual behaviour
CNAME, MX, and SRV records are exported without a full stop (.) at the end. This is only valid if the apex domain should be appended to the line, however the export includes the apex domain at the end of the line already.
The output below has been anonymized and has unnecessary records removed. Note the MX record ending with the zone apex, but without a full stop - it should have either no apex, and no full stop, or with the apex, and with a full stop. Same with the SRV record. In the case of the example CNAME record, it points to an external zone and should have a full stop on the end no matter what.
The NS record is exported correctly, as is the $ORIGIN line and the SOA line.
$ORIGIN fakedomain.eu.com.
@ 900 IN SOA ns-xxxx.awsdns-xx.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
@ 300 IN MX 10 mail.fakedomain.eu.com
@ 900 IN NS ns-xxxx.awsdns-xx.org.
_h323cs._tcp.vcs-express1 300 IN SRV 1 1 1720 vcs-control1.fakedomain.eu.com
xxxx._domainkey.cloud 1800 IN CNAME xxxx.dkim.amazonses.com
Have you checked if the documentation has the information you require?
The documentation references broken CNAME exports for some providers such as GoDaddy, but this is happening with Route53 and includes CNAME, SRV, and MX records.
Could you contribute a fix or help testing with this issue?
I can test any fixes as required.
cli53 exports the values as they are represented in route53 without alteration. So in your case you've stored the records in route53 without the trailing period. The reason you don't see query time issues is because route53 also implicitly resolves relative records ended in the apex without further qualifying them - in a way that's not consistent with how bind would be expected to behave.
Changing cli53 would have reprecussions for maintaing consistency in import and export, and it's not likely something that would change.
The simplest solution is to rewrite your records to correct them, and reimport them.
I understand now that Route53 also stores records in a nonstandard manner. However, the import does not store the records in the same format they were exported - is this because of how the Route53 API interprets the records as they are imported?
No, I don't believe that to be true - if you import a correct bind file, then export you should get out exactly the same. If that's not the case, it's definitely a bug! What I believe you are seeing is with records created elsewhere (the web UI perhaps?) in route53 that are in this non-standard format?
On second thoughts, I think it would be better for cli53 to behave as you suggest. There's still slightly odd behaviour if you export/import one of these records (it will show as changing, because it effectively is since cli53 can't both produce valid bind files and preserve the non-standard route 53 representation), but this is better than the unexpected behaviour before.
Could you try latest master and let me know if this helps?
Unfortunately, I'm not sure how to build the windows version for testing. Is it something you can build and upload for me?
OK, that was pretty easy. I was able to build and test, and the export and import of my test zone worked exactly as expected this time. Thanks!
Thanks for verifying.