PTR, Alias, CNAME, and DNAME target value validation

[PeterDaveHello]

Hello,

I'm preparing a pull request to improve the validation (cc #3) of CNAME, DNAME, ALIAS target record, make sure that they should be a valid FQDN in the record, the PR is almost ready, just need to pass the tests right now.

During the test process, I found that there are two test cases of Azure DNS in test_octodns_provider_azuredns.py seem to have empty record, and the target value of these two tests seem to be . if you print it out:

1. cname2
2. ptr2

So, before this not sent yet pull request, OctoDNS seems to treat those records with value . valid, and the above tests should pass, looks a little bit weird.

Here are some error message from the cloud DNS services that I tested and doesn't support . as the record of the types mention above:

• Cloudflare: DNS Validation Error (Code: 1004) Content for CNAME/PTR record is invalid
• DigitalOcean: Invalid hostname
• Gandi: An error has occurred. Please try again. / The server has either erred or is incapable of performing the requested operation.
• Azure: Each label must contain at least one character. You may not input consecutive period '.' characters.

Even though that AWS Route53 and Google Cloud DNS seems to accept ., the nslookup or dig process won't return something really useful or meaningful(I replaced my own domain record with root.example.com as masked result):

$ nslookup root.example.com 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
root.example.com	canonical name = .

The content of RFC is a lot, and I haven't read it all or enough to tell should it be valid or not, just guess this behavior may need to be changed, what do you think? Thanks!

[ross]

The content of RFC is a lot, and I haven't read it all or enough to tell should it be valid or not, just guess this behavior may need to be changed, what do you think? Thanks!

👍 to validation rejecting . if that doesn't appear to be supported by most providers. I can't think of a use case where that'd make sense or even guess at what it'd do if you could. If the azure provider tests don't comply they can be updated in the PR that adds the additional validation.

[PeterDaveHello]

Thanks for the prompt reply @ross, I'll prepare the PR.

[PeterDaveHello]

Found something interesting which pointed out the reason why to test Azure with empty record: #84 (comment)

The change here might be a breaking change to Azure users, but could still be more consistent after the change. What OctoDNS would like to do in this case?

Azure actually won't allow me to create a CNAME record with empty value on the Azure Portal right now, not sure if the original case came from historical reason, but empty record is still making no sense to me personally:

[PeterDaveHello]

PR #631 sent!