Open mistabe opened 10 months ago
Thank you for opening this issue, we will look into it.
I am having the same issue with one of my Azure public DNS zones. We do have a large-ish TXT record in there (thanks SPF/DKIM!) but the error message doesn't specify exactly what is causing the parse error. I would assume python can handle strings longer than a few KB so is length truly the root cause?
Update, I did notice we have a Let's Encrypt-generated _acme-challenge.example.com TXT record where the value starts with a hyphen (actual value is very similar to -rYJcTo0vUmJ8MFmEkegMg8ReuVl1a-8dBmBurWpMko
This is perfectly valid in DNS RFCs but could it be causing an issue with az network dns zone export
command?
I believe I have tracked this down. When a TXT record contains an empty string as its value, that is when the export fails. This is common for DNS validation records such as _acme-challenge recrods where a value is added to the recordset by automation and then removed post-validation. When I updated all our existing TXT records containing empty strings to contain "foo" instead the export worked.
Basically, this command needs to be updated to handle TXT recordsets with empty string values.
@rmalayter Yes yes! We had a single TXT record with an empty value. I've notified colleagues, removed that empty TXT record and BOOM. Export ran. Please MS, can you fix it for us now we know that's the problem?
I'll second the importance of this as most TLS certificates on the interwebs are issued by Let's Encrypt, and the Azure DNS validation for ACME certificate automation tools add and then remove a TXT validation record to Azure DNS. However if a delete lock is present (usually the case in production DNS zones!) an empty TXT record is the common result.
Describe the bug
The export of the zone fails with a spurious error. The