Ctrl.blog

Linode includes DNS hosting services to customers at all price tiers. This lets you manage the domains for your VPS’ in the Linode Manager on the web and app. Linode’s distributed DNS services have great performance and a good track record when it comes to uptime and availability. The Linode DNS Manager, however, leaves some things to be desired. Input validation and normalization is one of those things.

Say you want to add a TXT record to your DNS zone to contain SPF, DKIM, or any one of the many other types of data records that are kept in such DNS records. If you’ve ever done any work on DNS, you know that values in TXT records must be surrounded by quotes. All of the web based management tools I’ve used for DNS have refused to save records that don’t have the " character as the first and last character in TXT records.

Let’s say I create two new records in the Linode DNS Manager. I enter the exact input values "test" and "test" (the last one with a trailing space character.)

Other than the fact that it looks like you’ve an exact duplicate TXT record – which isn’t allowed; the two records looks correct in the Linode DNS Manager:

The above representation, quotes and all, is how TXT records are displayed in the DNS managers of other service providers including GoDaddy, Hurricane Electric, Uniregistry, Amazon AWS Route 53, cPanel, and Dyn. It’s also an accurate representation of the entry in the DNS zone file.

The generated DNS zone file for these two entries will reveal that things aren’t quite as dandy as they appear:

ctrl.blog.  604800  IN  TXT  "\34test\34"
ctrl.blog.  604800  IN  TXT  "\34test\34 "

I’ve never managed to create anything like the above mess in my two decades of maintaining websites and DNS. There are two obvious issues:

1. Anyone who know their ASCII tables will immediately recognize \34 as a decimal representation of ". In other words, the dumb quotation mark I entered earlier is being escaped and included as part of the TXT record’s value.
2. You can also see that the second entry isn’t an exact match as leading and trailing whitespace isn’t stripped from user input.

If I’d used a DNS manager from a *cough* competent DNS provider, I wouldn’t have been able to create these entries without escaping the quotes myself to willingly create a strange TXT record.

I won’t claim this would never have been an issue with other DNS service providers I’ve used have all had their own unique quirks. None of the alternatives I’ve used would have let me create this particular mess, however. I did some quick tests in the web interfaces of some other DNS providers, and they all strip away whitespace — as people copy-paste examples — and either require me to remove or insert quotes, or handles both variants without raising any warnings.

I’ll count this one up as a strike against using DNS services from DNS providers who aren’t strictly in the DNS business. Specialized services and tools can indeed do a better job than a free service that’s bundled in with another service as a convenience.

dig example.com TXT

Resolve-DnsName -name example.com -type TXT