Domains: Can't Add a DNS Record for Root Domain (Requires Subdomain)

[BrookeDot]

When adding a DNS Record for a domain with WordPress.com Name Servers it is currently not possible to add a record for the root domain. For example if I wanted to use Google's MX record I would enter something like the following:

Which results in:

In a perfect world the flow would look like this:

(using @ but should also accept domain name or blank)
resulting in:

Once we allow a blank or @ to be entered for DNS settings this should no longer be an issue.

I'm not 100% sure but I think this may have started with the merge of #2262.

FWIW I also tested #3150 which also has the issue reported above by requiring a subdomain. See: #3150 (comment)

Related: #1604 (blank MX records) and #234 (root A Records)

cc:// @andreabadgley @richardmtl

[andreabadgley]

I've encountered this issue several times in live chat, where a user attempts to add blank MX records, as in step 17 in adding email through Google Apps, and they are not able to add the records. If the user enters mygroovydomain.com in the host field, the record ends up being mygroovydomain.com.mygroovydomain.com as @BandonRandon mentioned above. If the field is left blank, the user receives an Invalid Name error for the host field:

The user ends up opening a live chat and we add the records via wordpress.com/my-domains (Atlas)

[klimeryk]

Thank you for a detailed report @BandonRandon and @andreabadgley, but this is a duplicate of #1604.
Also, as already discussed (#1604 (comment)), using @ as a special/magical character that denotes a root domain is far from ideal. It's something that Google might be using, but it's not a standard and is plain confusing - how would the user discover that he/she should input @.example.com to set the root domain?

[BrookeDot]

@klimeryk I'm not thinking this is a duplicate of #1604 It's actually a regression. When #1604 was reported you could actually enter the root domain, and get a valid record. For example, if your domain was example.com and you entered Example.com in the MX field you'd get back example.com as the root for the MX Record. What is currently happening is you enter example.com in the MX field and get back example.com.example.com

I'm reopening this but happy to move the discussion over to #1604. IMHO it went from "not a blocker" to "blocker" as it now is preventing valid MX records from being entered.

[BrookeDot]

I'm changing this to "normal" as #3235 allows blank MX records making this no longer a blocker. Sorry for the panic.

[richardmtl]

but it's not a standard and is plain confusing - how would the user discover that he/she should input @.example.com to set the root domain?

Google's own docs say to use @ ; I suspect that a lot of people see those instructions and will attempt it. Also, I may be misunderstanding this document, but it does appear to be part of a standard ; see this Stackoverflow comment and the linked document. Again though, I'm not an expert, but it does seem to be something that is used de facto by many places, including the big one (Google Apps), so I think we should support it.

[BrookeDot]

While I do agree that we should support @ (even if we convert it to the domain name on save) IMHO that's the core of #1604. This issue is open to allow the full domain name to be entered into the host field (as our documentation currently states) without using the domain as a subdomain.

[klimeryk]

Google's own docs say to use @ ; I suspect that a lot of people see those instructions and will attempt it. Also, I may be misunderstanding this document, but it does appear to be part of a standard ; see this Stackoverflow comment and the linked document. Again though, I'm not an expert, but it does seem to be something that is used de facto by many places, including the big one (Google Apps), so I think we should support it.

They say Blank or @ - it seems more intuitive to me to support a blank subdomain as meaning "root domain" than @ (which is usually connected with an email address for most people). @breezyskies agreed with this in #1604 (comment)
BTW, thanks for pointing out that how it's defined in the RFC - but for me that's an implementation detail that we shouldn't bother the user with. Just as we don't tell them about FQDN vs DN, etc.

This issue is open to allow the full domain name to be entered into the host field (as our documentation currently states) without using the domain as a subdomain.

I'm sorry - I'm kinda lost. The current implementation is that the Host field has the domain part automatically appended (which is hinted by the .example.com suffix in the input field). The user only has to input the subdomain (which, in some cases, is optional). Requiring the user to input the whole domain into the input field does not make sense - looking at it from the UI. But when implementing this, I did add support for such a corner case - if you input test.example.com into the Host field, the domain part will be stripped and test will be used.

You are right that inputting just the root domain (example.com) will result in example.com.example.com - which is a bug that I'll fix. I'll also add a corner case for @ so that our HEs don't have to deal with additional work ❤️ But this is still a corner case and inputting the root domain in this manner should not be officially supported - if that's how the documentation is recommending it right now, then they should be changed. Please ping me on Slack if I should bother someone directly or if you already know who can help out with this :)

Please don't misunderstand me - I'm more than happy to lessen the workload for our Happiness Engineers. But the way this issue was phrased seemed to me like you want to have @ or example.com as the main and official way of inputting root domain, while the new UI is strongly suggesting just leaving the field blank. Hence my apprehensive approach to this issue.

[BrookeDot]

Thanks for the detailed response @klimeryk

But the way this issue was phrased seemed to me like you want to have @ or example.com as the main and official way of inputting root domain,

I can see how it seems that way. I think it's more important that we allow for user error. It's not uncommon for a user to want to use @ in the subdomain field. Even if our documentation and Happiness teams encourage leaving it blank we can only reach so many users. By converting @ to blank on save we can avoid some confusion.

But this is still a corner case and inputting the root domain in this manner should not be officially supported - if that's how the documentation is recommending it right now, then they should be changed.

Up until #3235 leaving the root field blank resulted in an error. For this reason we recommended/required the domain name be entered into the field. Myself and others can work on re-creating the screenshots/updating the documentation. However, if we support example.com and removing it on save that would be best for now. In other words, save MX example.com as example.com instead of example.com.example.com. I would argue if someone entered example then we save that as example.example.com. The exception only applying when the full domain is entered.