Skip to content(if available)orjump to list(if available)

Dotless Domains

Dotless Domains

161 comments

·May 11, 2025

nulbyte

> According to ICANN's SSAC,[1] SMTP requires at least two labels...

ICANN does not define SMTP, and the "relevant quote" from SSAC in the article footnotes mentions nothing about it, either.

In fact, RFC5321 makes explicit reference to the possibility of an email address using a TLD as the domain in section 2.3.5.

qingcharles

I've known people back in the 90s with user@tld domains, and they were definitely sending and receiving mail. So, even if it wasn't spec-compliant it certainly got through all the early mail relays.

I mean.. you can use emoji domains right now. They work most places for email. The part I found didn't work so well is emoji usernames on emoji domains. That has poor deliverability.

null

[deleted]

Joker_vD

> you can use emoji domains right now

ICANN, by the way, heavily discourages such domain names, even though it can't actually prohibit them: yes, RFC 5892 explicitly prohibits emoji code points in internationalized domain names but so what? If registrars allow (and many acually do allow) registration of such names that only means that they violate some RFC and they already violate quite a lot of them. Who cares! Just pay the money and we will delegate you whatever names you want.

rzzzt

I'd think/hope the Punycode representation is actually registered in these cases: https://en.wikipedia.org/wiki/Emoji_domain

null

[deleted]

pas

sure, and you can use it internally, or with your own private/internal DNS (or other name resolution system), but in practice it means that for new gTLDs it's a no-go, right?

tech234a

Similarly, browsers also accept IP addresses in decimal form, for example http://16843009 for 1.1.1.1

bingo-bongo

And the shortened form, eg. http://127.1/ (for 127.0.0.1)

leshokunin

TIL

0points

or a public one, http://1.1/

ranger207

Usually they'll also accept octal with a leading zero (010.010.010.010 is 8.8.8.8), hexadecimal with a leading 0x, and omitted 0 octets (127.1 is 127.0.0.1). IIRC these are all adopted from BSD's sockets library, or some similar early IP implementation

ryao

They will accept IPv4 addresses in IPv6 addresses too:

http://[::ffff:1.1.1.1]/

Sadly, cloudflare does not.

efitz

That is a syntactically and semantically valid IPv6 address; no browser trickery.

immibis

OS trickery, though, because it doesn't send IPv6 packets to that IPv6 address, but rather sends IPv4 packets to the corresponding IPv4 address.

layer8

Which doesn’t conform to RFC 3986, by the way.

   The syntax rule for host is ambiguous because it does not completely
   distinguish between an IPv4address and a reg-name.  In order to
   disambiguate the syntax, we apply the "first-match-wins" algorithm:
   If host matches the rule for IPv4address, then it should be
   considered an IPv4 address literal and not a reg-name.
This means that URL syntax like http://16843009/, http://127.1/, http://010.010.010.010/, and http://127.0.0.1./ (note the final dot) should be interpreted as domain names, not as IP addresses. (Domain labels are allowed to be purely numeric.)

chrismorgan

But it does comply with WHATWG’s URL Standard, which declares the goal of obsoleting RFC 3986, providing something that’s actually robustly implementable, and reflecting reality.

Some things do definitely try to follow RFC 3986 still, but my feeling is that it’s mostly legacy stuff, and the URL Standard is much more important these days. Though RFCs dealing with URLs will probably still cite it (e.g. RFC 9110, HTTP Semantics, June 2022).

https://url.spec.whatwg.org/#host-parsing, follow step seven.

layer8

True, though the WHATWG algorithm still raises validation errors internally for all these cases. Meaning, while these representations are leniently accepted, they aren’t intended to be valid representations.

esperent

What's decimal form (base ten?) and why is that 16843009 the decimal form of 1.1.1.1?

fluidcruft

1.1.1.1 is 0x01010101 and 0x01010101 is 16843009 in decimal

esperent

> 1.1.1.1 is 0x01010101

Huh, in many years of web development I never knew that. Thanks!

ForOldHack

Um no. Parent is exactly right: p256^3+q256^2+r*256+s

itsgrimetime

00000001 00000001 00000001 00000001 = 16843009 in base 10 (concatenate each dot-separated 8bit number as one big base 10)

phanimahesh

IP addresses are 4 bytes, each in the range 0-255. In binary bits xyz would be equivalent to decimal x2^2+y2+z. Similarly, bytes abc would be equivalent to decimal a256^2+b256+c.

IP address p.q.r.s is decimal p256^3+q256^2+r*256+s.

90s_dev

I'm bad at math. What's the algorithm for this? Something about 256^(1..4)?

opello

You can think about it like the IP address in hex if you like: 0x01.0x01.0x01.0x01 becomes 0x01010101 which is 16,843,009. So the first 0x01 is 0x01000000 which is the familiar 16,777,216 which then gets the further "base 256 digits" added to it.

Or maybe in your terms it's 256^(0..3) where you can think of it like each dotted component is a symbol (like 0-9 in base 10) where each component is a position digit. Where the right-most element is the "256^0" ("ones") digit, and the left most element is the "256^3" ("16,777,216s") digit.

hug

IPs are 4 octets, normally represented as a decimal between 0 and 255, or 00000000 and 1111111 in binary.

Remove the dots and concat the binary value for 1.1.1.1 and you get 00000001000000010000000100000001.

Convert that binary value to decimal and you get 16843009.

davejagoda

echo 256^3+256^2+256^1+256^0|bc

16843009

90s_dev

Ha, then I was right, but with a one-off error!

FlamingMoe

I think this post is trending because of a comment on the announcement about the new Pope, where someone pointed out the redundancy in the vatican.va domain.

AStonesThrow

The vatican.va domain has long been an outlier for not operating a web server at that shortened address.

They insist on using the “www.vatican.va” only, and my browser’s autocomplete history reflects this.

pimlottc

They might as well then just use www.va!

AStonesThrow

Well I suppose they could. But as we've seen, there are plenty of 2nd level domains under .va, and in fact, many if not most of those, especially vatican.va, actually refer to the Holy See.

It's very common and understandable for folks to conflate the Holy See with the Vatican, but they are distinct entities with two different functions and purposes.

If we're discussing the administration/governance of the Church and the organs which make up the Roman Curia, then we're definitely looking at the Holy See. It's the Holy See, not the Vatican, which is a Permanent Observer to the U.N.

But again, if we're looking at any sort of physical presence, it's the Vatican City State. The actual territory that's an enclave and microstate is the Vatican. It's where people live, work, and worship. "The Vatican" is the entity selected for the ".va" ccTLD simply because of the way the rest of the world works. But only a few of those 2nd level domains can properly be considered more "Vatican" than "Holy See".

pelagicAustral

This is such a beautiful thing, it gets you in the head as much as in the heart... alas, probably nobody else feels this way about it...

rat87

> There 86 domains names starting with "www" in the .va zone,[6] with many more email-only subdomains.

https://www.vatican.va/siti_va/index_va_en.htm

tony-allan

Website is currently rate limited.

https://archive.is/MDRWw

Animats

Most browsers treat one word not as a domain but as a search key. This was an issue when companies started getting their own TLDs. Could you just type "amazon" or "microsoft", which are TLDs, and go there without being diverted to a search engine? The answer is no. Even if you put a dot after the domain name.

DNS lookup and web browser domain lookup are not quite the same. This is the price of a unified input bar.

eadmund

> This is the price of a unified input bar.

I never saw what was wrong with having a URL and a search box in the same bar. It was fine, and I knew that whatever I typed into the URL bar would be treated as a URL.

Fast forward a few years, and URLs I type into the bar are not treated as URLs (internal HTTP URLs get rewritten to HTTPS when a server is restarting).

wibbily

Mobile Safari likes to do this to me w/ machines on my tailnet. Whether dropping "foo:8080" in the address bar takes me to the webserver or to Google is random and I swear there is no pattern

dgellow

in my experience you have to explicitly add the https:// prefix to get it to consistently load the address

Tsiklon

Drop a slash at the end, it tends to turn it into an actual NS lookup not a search.

71bw

...add .local and pray it works this time.

anticrymactic

A forward slash at the end usually does the trick for me.

homeserver -> Google

homeserver/ -> http://homeserver/

thedufer

Putting a slash '/' at the end consistently gets you there, at least in Chromium-based browsers. We use this a lot at work (via DNS search suffixes, not private TLDs).

Biganon

The "correct" way would be to add a dot at the end

thedufer

Why would that be more correct? A trailing dot indicates that a domain is fully-qualified, but that's not the issue here. The browser is trying to decide whether your query is a search string or a URL.

Also, a trailing dot would indicate the opposite of what we want - we're using single-label domains that only work if we can rely on search suffixes to qualify them.

tuckerman

At least in chrome the final period doesn't seem skip search, so I guess you want tld./ (or foo/ if you want to use your search domain)

CraftThatBlock

At a previous company, our intrasite was a bare custom domain, and the most reliable way to get there was to add a / at the end. This is likely browser dependent though

1718627440

You can change that in Firefox by setting keywords.enable to False. This is in fact the first thing I change on the browser.

90s_dev

Ahh, I actually ran into this question, at least indirectly, about a month ago!

I was writing an email validator for my project which I'm so excited to announce soon. And my research (some stackoverflow answers) suggested that, yeah, you can have "a@b" as a valid email, as long as there's a one-letter TLD that can have MX records.

Which it seems there can be!

So my email validator is essentially just /^.{1,}@.{1,}$/ ... yay.

jph00

Last time I checked the RFC the bit before the '@' can actually be empty. And the root zone is just '.', but we generally can leave off the trailing dot in domain names. So I believe '@' on its own is a valid email address.

Many years ago I managed to get a cctld owner to point their tld MX records at my smtp server, modified postfix to allow empty usernames (even although the RFC allows them, postfix didn't), and successfully had someone send me email to '@tld', in order to win a bet. :) (And it was a 2-letter tld.)

90s_dev

> So I believe '@' on its own is a valid email address.

Then the owner of "@" cannot use my site. I'm fine with that.

gerdesj

I don't know if it is still required but hostnames used to require a minimum of two chars and the first shalt not be an integer. Given that DNS does not put a proper boundary on host/domain, that might extend to your top level ... thingie.

However, there is absolutely no technical reason that I can think of that precludes u@x. In the end DNS query -> DNS answer. Given that say, PowerDNS has LUA built in, I can make it respond with "my little pony's stable is in {random_country}" - to A record requests, which might make the requester a little queasy!

Bugger standards, they are so 1990s!

null

[deleted]

esperent

the first shalt not be an integer

I recently came across the 3.ie domain so I guess that's more of a guideline than rule.

AStonesThrow

I believe that the rule has been deprecated due to better parsing.

In the mid-90s, 3M was a customer of the ISP I worked for. Unable to procure the domain name “3m.com” they settled for the alternate “mmm.com”: mildly hilarious considering their lines of business.

38

90s_dev

My site doesn't use HTML so that's not gonna help here.

andrewmcwatters

You should know there is a standard regular expression for validating email addresses mentioned in an RFC.

Xss3

The real validation is the link in the confirmation email.

Tbh though ideally you would use the most restrictive validation that exists in the mail server. If mail server accepts '@tld' you do too.

90s_dev

I'm sure there is. And I'm sure many email servers deviate from it.

1718627440

But that would fail on the valid email "alice".

Dylan16807

{1,} is just an awkward way of saying + isn't it?

qaisjp

out of curiosity, why are you trying to validate emails?

90s_dev

Just a base level regex before sending emails, to avoid some errors sending to non-email addresses and logging otherwise unnecessary errors.

esperent

The best you can hope to do is reduce a small class out of possible errors. But you'll never get a test that can prevent errors like name@gnail.com, name@gmaip.com, nane@gmail.com etc. So is it really worth doing any checks at all?

I have a .blue email address and it's amazing how many sites still won't accept it. I keep a spare Gmail account for these.

bch

Does this block things like the unconventional Google-filing trick of:

  myemail+90sdev@gmail.com
which gives me the “90sdev” tag for my emails, which still go squarely into my “myemail@gmail.com” address? I don’t know what the best route is, but I’ve certainly run into bad validators that block things that otherwise work, and that’s annoying. It seems to me the best thing might be to have a user twice input their address, then have the next step/confirmation done via email.

qingcharles

Does your regex support emoji usernames and domains? (both of which are in use, e.g. https://mailoji.com/)

tzury

All domains including TLDs are sub domains of “.”

That’s why there is a trailing dot you see in NS records for example.

stackskipton

Trailing dot is complete record, don't add any search domains onto it. (https://en.wikipedia.org/wiki/Search_domain) It's why NS records should have trailing dot in return to prevent unexpected lookup behavior.

Technically you can put just hostname for CNAME record. Obviously, any clients that don't have that domain as search domain will fail but for internal domain, you could do it.

Salgat

Seems Chrome also adds the dot at the end in the address bar.

jfengel

Oh. Thank you. I had wondered.

mesrik

AFAIK calling DNS root the "." is quite recent phenomenon.

I'm fairly old guy who did work with DNS about 35 years before retirement and what I recall from the beginning when I was reading my first copy of DNS and BIND somewhat quite soon it came out -92 I think the second chapter which describes DNS root "A null (zero-length" was already there.

So a FQDN (Fully Qualified Domain Name) well known www.google.com the would be www.google.com."" where between the quotation denotes where the DNS root is shown.

However, resolvers don't recognise that syntax. Don't be fooled by

$ host www.google.com.""

www.google.com has address 216.58.209.164 www.google.com has IPv6 address 2a00:1450:4026:802::2004

from the shell as it removes those double quotes. Using single quotes around shows how that fails and you can check it easily.

$ host 'www.google.com.""'

Host www.google.com."" not found: 3(NXDOMAIN)

The way I learned to understand it the dot in DNS name is (it signifies) the DNS-tree separator, not part of the DNS name. A bit like in some languages (Pascal) use semicolon (;) a sentence separator not an end of sentence like it's in C and many it's practise adopted later.

OK, here's an excerpt from DNS and BIND by Cricket Liu & Paul Albitz, O'Reilly ISBN 0-596-10057-6, Fifth Edition 2006 book which I still have a printed copy in my shelf and shows what I'm referring above.

Chapter 2: How Does DNS Work, page 12, text after Figure 2-1 they write:

"Domain Names

Each node in the tree has a text label (without dots) that can be up to 63 characters long. A null (zero-length) label is reserved for the root. The full domain name of any node in the tree is the sequence of labels on the path from that node to the root. Domain names are always read from the node toward the root ("up" the tree), with dots separating the names in the path. If the root node's label actually appears in a node's domain name, the name looks as though it ends in a dot, as in "www.oreilly.com." (It actually ends with a dot—the separator—and the root's null label.) When the root node's label appears by itself, it is written as a single dot, "", for convenience. Consequently, some software interprets a trailing dot in a domain name to indicate that the domain name is absolute.

An absolute domain name is written relative to the root and unambiguously specifies a node's location in the hierarchy. An absolute domain name is also referred to as a fully qualified domain name, often abbreviated FQDN. Names without trailing dots are sometimes interpreted as relative to some domain name other than the root, just as directory names without a leading slash are often interpreted as relative to the current directory.

... "

I don't have old book copies any more, I've just this one with me.

hirsin

At one point we were looking at moving a bunch of separate domains under a single dotless domain, due to the threatened death of 3p cookies, so that cookies could be dropped directly onto the cctld (think "you're logged into the entire TLD"). As the owners of the cctld it felt like a neat use that technically could work but ICANN and other groups are explicitly against that.

To me it felt very AOL keyword

mattl

I think done well, AOL keywords are actually a good idea.

They could also cut down on the fraudulent websites out there.

Not sure how to fully implement it but given the safe browsing features already implemented in web browsers it could perhaps be part of that. Or a new TLD.

hirsin

I imagine they'd have all the lovely problems of both EV certs (sure, you're legitimately PayPal Corp, in Malawi) and limited real estate price squeezes.

Curation of "good" or "real" websites has been tried before - I don't envy anyone that wants to try another go at it.

vzaliva

I knew someone who had email ??@ua (two letters masked for priivay) which might have been one of the shortest email addresses in the world. Unfortunately it was not very useful as most email systems failed to recognize it as a valid email address. :(

thequux

I know that Len Sassaman had r@ai for quite some time, so your friend didn't have the absolute shortest address. Still a cool one though

codethief

> two letters masked for priivay

You do realize there are not that many two-letter combinations…? :)

Dylan16807

That doesn't impact the privacy much. Much like being able to guess every phone number.

codethief

I would assume there are not that many valid email addresses of the form ??@ua, so narrowing things down is a matter of sending out 26² emails and waiting for the mailer daemon to respond.

zatkin

It's funny seeing that list of MX apex records. In response to me trying to show off how I had acquired a single letter domain, and had a single letter e-mail address (which resulted in *@*.**, replacing asterisks with letters), my boss showed how he was able to receive an e-mail address under one of those two-letter 'MX apex records'...

zoky

I had a teacher in high school who once wrote a URL on the whiteboard like this: com/foo/bar.html

Upon informing him that he had forgotten to write the domain, I learned that the site was actually www.com, and he had just left the http://www part off because “the web browser adds that automatically”. I assured him that, while in principle he was more or less correct, but in this case it wouldn’t work. He ended up adding the www, but I could tell he was skeptical that I was just being a smart ass.