I have found one other issue with the CNAME validator though, but this might need a separate report. It looks like that any content that is put in is treated as valid, but this can lead to invalid record resolving.

As a tested example: I can put in a record as test CNAME www which is then happily accepted by Poweradmin. However, as the content of the record is not expanded to FQDN within the current domain it is put in the database as test CNAME www. which cannot be resolved.

So, record as put into the zone:

Leads to this at resolving it from a client and yields an error:

I think this is one of the 'trailing dot' issues that we have had before in the UI and not sure how to permanently fix this. I can think of two options:

1. Put in a validator check for CNAME stating an error is anything less than FQDN is in the content of the record, this will force the user to always specify a FQDN which leads to valid resolving.
2. By default, check for a FQDN in content and if not found append the zone name after the content before saving to the database, unless the user ends the field with a trailing dot which is an edge case and that should lead to an error being displayed as the user then intended to use a short-form which is not valid for CNAME.

I think option 1 is the most likely the easiest one as per RFC1035 that specifies DNS a CNAME always should contain a FQDN and the user should thus specify one.

Originally posted by @michielvisser in #719