Why Marketo LP Domains and Domain Aliases can’t have an underscore

[SanfordWhiteman]

Some apps (but not Marketo) are far too open-minded about underscores in host names. Here’s one SaaS setup guide saying underscores aren’t “web best practice,” but allowing them anyway:

Needlessly vague, since the underscore in mobile_conference has predictable consequences for this particular app. In all browsers but Internet Explorer, the site will function correctly. In IE, cookies won’t work, breaking autofill for that site’s forms, among other things.

So for the above app, underscores are either (a) very wrong, if you do support IE, or (b) alright, if you don’t. (For the record, underscores are standards-compliant in the context of this app — otherwise I wouldn’t call ’em “alright.”1)

While the underscore maybe-works in the above app, that’s hardly true of the web at large. For Marketo LP domains, underscores cannot be used, period. This is not only mandated by standards, but also by real-world consequences in all browsers.

Marketo is properly strict in the Admin » Landing Pages section:

Why must Marketo prohibit underscores? The answer may surprise you.

 

It’s not about DNS standards

The question of where underscores are allowed in DNS has been relitigated for decades, from BBS chats to NNTP newsgroups to Stack Overflow.

It’s unsurprising that people still have questions, since the answer hinges on the technical difference between “host name” values and “domain name” values in DNS standards. The fact that apps constantly use “domain” where they mean“host” (see the first screenshot up top) doesn’t help matters!

In short, a host name is a type of domain name, but with strict naming restrictions. DNS A and AAAA records denote host names.

But other common record types, like the alias (left hand side) of a CNAME and the TXT records used for DKIM and SPF, are domain names, but don’t denote hosts.

Host names are restricted to what’s called the Preferred name syntax or LDH (Letter-Digit-Hyphen) syntax: letters A-Z, numbers 0-9, and the hyphen, treated case-insensitively.

Domain names have more leeway and, to start with, can use any 8-bit characters, even including invisible control characters! That means a CNAME or TXT label can include underscores.

(Of course, record types enforce additional restrictions, like a DMARC record always needing to start with _dmarc. Plus, DNS clients may refuse to look up records with non-traditional names. Doesn’t matter what the standard says if something doesn’t work in practice.)

In practice, underscores in CNAMEs work anywhere but IE. In IE, the name will be resolved and the page will be drawn... but cookies are blocked, which renders many sites unusable (think sites requiring a login). This is a bug in IE: CNAMEs are allowed to have underscores, but IE treats them the same as As, which are not.

Marketo LP domains use a CNAME record:

pages.example.com IN CNAME exampleco.mktoweb.com

So if it were only about DNS, and you could swear to Marketo you didn’t care about IE, this would be fine, too:

pages_of_mine.example.com IN CNAME exampleco.mktoweb.com

But it’s about something else.

 

It’s about SSL standards

The CA/Browser Forum, which dictates standards for certificate authorities, voted in 2018 to stop issuing SSL certs containing domain names with underscores. (The measure took effect in 2019.)

You can’t buy certs for such domains, as you see on the DigiCert signup form:

As a few years have passed and old certs have expired in the interim, such certs have been eliminated from the public internet.

But — confusion ahead — that doesn’t mean you can’t connect securely to a domain with underscores!

The SSL certificate can’t contain complete domains with underscores, but it can contain an asterisk, i.e. a wildcard cert:

And that wildcard cert will handle connections to with_an_underscore.example.com without a problem. Assuming with_an_underscore.example.com is a DNS CNAME (not A) record, that setup is standards-compliant on both fronts. It’ll be screwed up in IE — but it’s otherwise legal and functional.

Yet Marketo LP domains don’t meet the above requirements. Marketo does use CNAMEs. But as you probably know by now, Marketo uses Cloudflare for DDoS protection and caching. Cloudflare automatically generates SSL certs that bind to a single domain, i.e. the domain you’re connecting to:

Since they don’t use wildcard certs, they can’t serve domain names with underscores, and that in turn restricts Marketo LP domains/domain aliases.

There you have it!

NOTES

[1] It’s standards-compliant in this case because the app uses a wilcard SSL cert (Subject Alt Name = *.toopermissive.com) and a wildcard DNS entry (*.toopermissive.com IN A 1.2.34). So no stored record with the underscore exists. Since the record mobile_conference.toopermissive.com doesn’t exist in the DNS zone — at least as far as I understand the specs — it’s not subject to the typical rule about A records.