Obviously there are a lot of errors by a lot of people that led to this, but here's one that would've prevented this specific exploit:
> As part of our research, we discovered that a few years ago the WHOIS server for the .MOBI TLD migrated from whois.dotmobiregistry.net to whois.nic.mobi – and the dotmobiregistry.net domain had been left to expire seemingly in December 2023.
Never ever ever ever let a domain expire. If you're a business and you're looking to pick up a new domain because it's only $10/year, consider that you're going to be paying $10/year forever, because once you associate that domain with your business, you can never get rid of that association.
This is the most obvious reason why Verisign is a monopolist and should be regulated like a utility. They make false claims about choice and not being locked in. You buy a domain, you use it, you're locked in forever. And they know it. That's why they fight tooth and nail to protect their monopoly.
It’s worse if you stop using the phrase ‘buy’ and instead use the term ‘rent’. A DNS provider could 10,000x your domain cost and there’s nothing you can do about it.
This actually happened to me, but fortunately I never actually used the domain. I registered tweed.dev intending to use robert.tweed.dev as a personal blog. It wasn't classed as a "premium" domain and the first year was £5 or something IIRC, which was half price compared to the normal renewal fee.
The next year they decided it was premium after all, and wanted to charge £492,000 for renewal. I still have a screenshot of that, although needless to say I don't own the domain anymore.
They operate the registry, but are not a registrar (bad choice of terminology) since they sold off that part of their business to Squarespace. Unclear to me who actually raised the price here since you can register a .dev domain with many registrars.
That's insane though, I assumed renewal prices were more or less locked in after you own a domain. Even the premium ones that go for thousands say they renew at the standard $12 or whatever.
Yea, but in this case the property is very special. I don't think anyone has a right to own a "name" for perpetuity, especially such a short one—that's just extending property rights to a nonsensical place.
Granted, I also have zero respect for people who think that trademarks, patents, and copyright are still working to promote rather than stifle the arts and sciences, so I can understand why my above sentiment might rankle.
Ok please stop posting as darby_nine. I’d like my turn with that identity. I think it fits with some objectionable conspiracy theories I’d like to promote.
Countries owning their ccTLDs seems basically correct to me. If you rent a `.tm` domain, you're doing business with the nation of Turkmenistan: might want to think about whether a TLD pun is worth taking on that relationship.
There are a bunch of different domain types all commingled together; non-premium gTLD domains, ccTLD domains, 3rd level domains, registry premium gTLD domains and, as added complexity, aftermarket domains which could be any of the previous listed types.
ICANN provides some protection for standard gTLD domains, but it's minimal. You're guaranteed identical pricing to all other standard domain registrants on the gTLD, so they can only raise your price by raising the price of everyone else at the same time. That hasn't stopped some registries from 10x price increases though. The only thing it does is ensure they can't single you out and massively hike your renewal fee.
However, that does not apply to registry premium gTLD domains. When you register a registry premium domain you waive those protections and the registries can technically do anything they want.
If you register a ccTLD domain, you're at the mercy of that country's registry. If you register a 3rd level domain you're at the mercy of the 2nd level domain owner and they're regulated by either ICANN or a country based registry.
It's actually somewhat complex when you get into it.
To be clear, that's because the country that represents that ccTLD has sovereignty over it. That's also why they can have arbitrary, unusual requirements on them.
See also personal phone numbers, which are now "portable" and thus "required for every single identity verification you will ever perform", without being regulated, which means your identity is one $30 bill autopayment or one dodgy MVNO customer service interaction from being lost forever.
What if you need to stop paying for a phone bill entirely though? Maybe you're living paycheck to paycheck and money is just too tight this month. That's what I think GP was talking about.
Is it possible to "park" your phone number until you can start a new plan?
It's now possible. I work for a mvno that was recently acquired. We have a $5 pause plan. It has no data, voice or text, it just keeps your line active.
Germany is not exactly known for cheap plans, but apparently it’s worse in the US and you can only get comparable plans if you pay yearly, which I guess might just barely make a $5 parking contract worth it.
This wouldn't be surprising. It's sad they've let it atrophy the way that they have. My understanding is that they purchased it to train their digital assistant on the voicemails (where we would correct the transcripts for free)
Though AFAIK there's no law or contract term preventing Google from starting to charge a monthly fee in the future.
And after some time — for me it was 5+ years, porting from a baby Bell land line to a postpaid T-Mobile family plan for a couple years and then to Google Voice — your number will be tarred and feathered as a "VoIP" number and rejected for identity verification by some parties until it's ported back to a paid service (again, after some time).
Even so, it's nice that Google lets me keep the number I was born with for $0/month for as long as it lasts.
Google has already killed my sister's business's Enterprise Workspace plan, because they decided to change their mind, and make "unlimited storage" not a thing. She was paying $200/month and they now wanted $1,600/month. I decided to build a NAS for her instead.
This is despite written emails from their support confirming the use case (videography) and storage needs were suitable, and a written statement that she is "permanently grandfathered" once Google stopped offering the plan to new customers.
To make matters worse, they gave her 30 days to download all data before everything would be deleted permanently. This is how Google treats "enterprise" customers.
> your number will be tarred and feathered as a "VoIP" number and rejected for identity verification by some parties until it's ported back to a paid service (again, after some time).
Where things get fun is when Google Voice IS your paid service (e.g. google fiber's phone service, popular with a certain demographic that used POTS for most their life and want to continue having a similarly behaving service).
You can port your number to NumberBarn and park it for $2/month. Other services probably exist, but I signed up to NumberBarn ages ago and haven't had any issues the handful of times I've used them.
Lose access to your number by any category of errors on your part or your carrier's part, and see what happens.
They're not tied to your person with much more permanency than a DHCP IP address. There's no process to verify your identity or recover your number or help you regain your accounts. The actual process for migrating your number is "Sign up with this other brand you've never tried before and tell them to politely ask your former brand to release the number to them".
If I lose my phone to a trash compactor, the process to change anything in my phone carrier account with regard to SIM cards is going to forward things to my Gmail account, which at random times for random reasons is going to begin to demand 2 factor identification for logging in on a new device via texting my phone number.
There are all sorts of crazy scenarios that can arise with double binds like this.
If we had a resilient authoritative identity verification (say, the DMV, or US Passport Office), or if we had a diverse variety of low-trust identity factors that we could check multiple aspects of ("text my mother" / "Here's a bill showing my address" / "here's a video of my phase saying my phone number"), there would be a way out, but all of corporate America heard "2fa is required for security now" and said "So we just text them right?"
That makes your phone not "another thing that people can use to talk to you in circumstances when you're not accessible", which the FCC's portability plan was maybe sufficient for, but a fragile single point of failure for your entire identity.
I'd assume regulated in the sense of identity verification and transactions. There's no legal basis for needing a north American phone number, but good luck with any US obligations if you are without one.
I’m wondering how feasible would it be to just use a SIM card from another country (e.g. in Estonia, you can get a prepaid card for 1 € that works in EU roaming just fine, with domestic-like prices on local calls). How many services in Germany require you to use specifically German number?
It depends of course how far you are. I used to use an orange Spain SIM before the EU roaming deal because they had free roaming on sister networks. But I didn't go there so much.
There is an alternative to such regulation though. In the Netherlands, all registrars are required to support automatic transfer between registrars. You can lookup your "transfer code", which you can enter at a new registrar, and they will handle that your domain is transferred (with proper DNS etc) and your old subscription stops.
GP is referring to the registry, not the registrar. There's lots of competition between registrars, but the registries have a post-sale monopoly on all domains.
Put another way, as soon as you register a .com domain, the only registry that can sell you a renewal is Verisign. If there weren't price controls, Verisign could increase the price of a .com renewal to $100 and there's nothing anyone could do but pay it.
This whole thread back to the root is right. Verisign has a monopoly, you can never drop a domain once it's associated with your business, and all of it should be regulated like a monopoly.
Yup. Think about what happened when the Internet Society almost sold the .org TLD to Ethos Capital and they were planning on raising the registration prices by a lot.
If you really want to get upset, go look what the NTIA did with the 2018 renewal of the .com agreement. Prior to 2018, the US DoC had a significant amount of oversight and control. The 2018 renewal pretty much gave .com to Verisign. The only thing the US DoC can do now is renew the contract as-is or withdraw.
Not true. If you are hosting user content, you want their content on a completely separate domain, not a subdomain. This is why github uses githubusercontent.com.
I can think of two reasons:
1. it's immediately clear to users that they're seeing content that doesn't belong to your business but instead belongs to your business's users. maybe less relevant for github, but imagine if someone uploaded something phishing-y and it was visible on a page with a url like google.com/uploads/asdf.
2. if a user uploaded something like an html file, you wouldn't want it to be able to run javascript on google.com (because then you can steal cookies and do bad stuff), csp rules exist, but it's a lot easier to sandbox users content entirely like this.
> if a user uploaded something like an html file, you wouldn't want it to be able to run javascript on google.com (because then you can steal cookies and do bad stuff)
Cookies are the only problem here, as far as I know, everything else should be sequestered by origin, which includes the full domain name (and port and protocol). Cookies predate the same-origin policy and so browsers scope them using their best guess at what the topmost single-owner domain name is, using—I kid you not—a compiled-in list[1]. (It’s as terrifying as it sounds.)
3. If someone uploads something bad, it could potentially get your entire base domain blocklisted by various services, firewalls, anti-malware software, etc.
- is allowed to set cookies scoped to *.github.com, interfering with cookie mechanisms on the parent domain and its other subdomains, potentially resulting in session fixation attacks
- will receive cookies scoped to *.github.com. In IE, cookies set from a site with address "github.com" will by default be scoped to *.github.com, resulting in session-stealing attacks. (Which is why it's traditionally a good idea to prefer keeping 'www.' as the canonical address from which apps run, if there might be any other subdomains at any point.)
So if you've any chance of giving an attacker scripting access into that origin, best it not be a subdomain of anything you care about.
A completely separate domain is more secure because it's impossible to mess up. From the browser's point of view githubusercontent.com is completely unrelated to github.com, so there's literally nothing github could accidentally do or a hacker could maliciously do with the usercontent site that would grant elevated access to the main site. Anything they could do is equally doable with their own attacker-controlled domain.
I think one reason is that a subdomain of github.com (like username.github.com) might be able to read and set cookies that are shared with the main github.com domain. There are ways to control this but using a different domain (github.io is the one I'm familiar with) creates wider separation and probably helps reduce mistakes.
I read about this a while back but I can't find the link anymore (and it's not the same one that op pointed to).
client browsers have no "idea" of subdomains, either. if i have example.com login saved, and also a one.example.com and a two.example.com, a lot of my browsers and plugins will get weird about wanting to save that two.example.com login as a separate entity. I run ~4 domains so i use a lot of subdomains, and the root domain (example.com) now has dozens of passwords saved. I stand up a new service on three.example.com and it will suggest some arbitrary subset of those passwords from example.com, one.example.com, two.example.com.
Imagine if eg.com allowed user subdomains, and some users added logins to their subdomains for whatever reason, there's a potential for an adversarial user to have a subdomain and just record all logins attempted, because browsers will automagically autofill into any subdomain.
if you need proof i can take a screenshot, it's ridiculous, and i blame google - it used to be the standard way of having users on your service, and then php and apache rewrite style usage made example.com/user1 more common than user1.example.com.
Because there's stuff out there (software, entities such as Google) that assume the same level of trust in a subdomain vs its parent and siblings. Therefore if something bad ends up being served on one subdomain they can distrust the whole tree. That can be very bad. So you isolate user provided content on its own SLD to reduce the blast radius.
I've read - because if a user uploads content that gets you on a list that blocks your domain - you could technically switch user content domains for your hosting after purging the bad content. If it's hosted under your primary domain, your primary domain is still going to be on that blocked list.
Example I have is - I have a domain that allows users to upload images. Some people abuse that. If google delists that domain, I haven't lost SEO if the user content domain gets delisted.
This is probably the best reason. I had a project where it went in reverse. It was a type of content that was controlled in certain countries. We launched a new feature and suddenly started getting reports from users in one country that they couldn't get into the app anymore. After going down a ton of dead ends, we realized that in this country, the ISPs blocked our public web site domain, but not the domain the app used. The new feature had been launched on a subdomain of the web site as part of a plan to consolidate domains. We switched the new feature to another domain, and the problems stopped.
CDNs can be easier to configure, you can more easily put your CDNs colocated into POPs if it's simpler to segregate them, and you have more options for geo-aware routing and name resolution.
Also in the case of HTTP/1 browsers will limit the number of simultaneous connections by host or domain name, and this was a technique for doubling those parallel connections. With the rise of HTTP/2 this is becoming moot, and I'm not sure of the exact rules of modern browsers to know if this is still true anyway.
There's historical reasons regarding per-host connection limitations of browsers. You would put your images, scripts, etc each on their own subdomain for the sake of increased parallelization of content retrieval. Then came CDNs after that. I feel like I was taught in my support role at a webhost that this was _the_ reasoning for subdomains initially, but that may have been someone's opinion.
Search engines, anti-malware software, etc track sites' reputations. You don't want users' bad behavior affecting the reputation of your company's main domain.
I actually think they need 2, usually need a second domain / setup for failover. Especially if the primary domain is a novelty TLD like.. .IO which showed that things can happen at random to the TLD. If the website down it's fine, but if you have systems calling back to subdomains on that domain, you're out of luck. A good failover will help mitigate / minimize these issues. I'd also keep it on a separate registrar.
Domains are really cheap, I try to just pay for 5-10 year blocks (as many as I can), when I can just to reduce the issues.
I felt the need to get in addition to (shall we say) foo-bar.nl the foobar.nl the foo-bar.com and foobar.com because I dont want a competitor picking up those and customers might type it like that.
Don't forget about infrastructure domains, static-asset domains, separation of product domains from corporate domains ... there are plenty of good reasons to use multiple domains, especially if you're doing anything with the web where domain hierarchies and the same-origin policy are so critical to the overall security model.
Why? I always get frustrated when I end up in some parallel universe of a website (like support or marketing) and I can't easily click back to the main site.
The non-technical reason is that these are usually owned by different teams in your org (after you mature beyond a 5-person startup).
The technical perspective is that things like wildcard subdomains (e.g. to support yourcustomername.example.com), or DNSSec if your compliance requires it, etc. cause an extra burden if done for these two use-cases at a time.
> can't easily click
Http pages don't have problems with having a link to example.net from within example.com. Or the opposite.
Seems like an unrelated problem.
One potential reason is that marketing teams often want to do things that are higher risk than you may want to do on your main application domain. For example, hosting content (possibly involving a CNAME pointing to a domain outside your control) on a third party platform. Using a framework that may be less secure and hardened than your main application (for example WordPress or drupal with a ton of plugins) using third party Javascript for analytics, etc.
Could you elaborate on why? The companies I have worked for have pretty much all used domain.com for marketing and app.domain.com for the actual application. What's wrong with this approach?
If there’s any scope for a user to inject JavaScript, then potentially this gives a vector of attack against other internal things (e.g admin.domain.com, operations.domain.com etc)
Also, if for example the SaaS you’re running sends a lot of system emails that really shouldn’t end up in spam filters, you can’t afford to let things like marketing campaigns negatively influence your domain’s spam score.
I like the point you are making in this post. It makes me think about the Backblaze blog posts where they discuss the likelihood of enough drive failures to lose user data. Then, they decided the calculation result hardly matters, because people are more likely to forget to pay due to an expired credit card or email spam filtering (missed renewal reminders!).
How do mega corps remember to pay their domain bills? Do they pay an (overpriced) registrar for "infinity" years of renewals? This seems like a genuinely hard business operations problem.
Mega corps have their own top-level domains. For example there're .apple, .google, .amazon, .youtube and probably some more I had forgotten.
Even when companies don't have their own top-level domain, they can have their own domain registrar. For example "facebook.com" is registered with "registrarsafe.com" as registrar. The latter registrar is a wholly owned subsidiary of Facebook. I learned this from this HN thread https://news.ycombinator.com/item?id=28751497
The megacorp that I work at requires us to surrender domain names payment that we own to a central authority who takes care of this in perpetuity. Any domain names we buy we also have to tell them about it. Your triple boss gets a good Stern talking to if you're not following these procedures.
> If you're a business and you're looking to pick up a new domain because it's only $10/year, consider that you're going to be paying $10/year forever, because once you associate that domain with your business, you can never get rid of that association.
Please elaborate...
Also, what about personal domains? Does it apply there as well?
As per the article, the old domain expired and was picked up by a third party for $20. Said domain was hard-coded into a vast number of networking tools never to be updated again, effectively letting the new domain owner unfettered access into WHOIS internals.
My brother used to own <our uncommon family name>.com and wrote on it a bunch. Eventually he bailed out and let it expire. It turned into a porn site for a few years and now its for sale for like $2k from some predatory reseller.
Same happened to my personal website for which I purchased the domain when I was 14 (long time ago) and at some point decided that a .com domain is ridiculous for a personal website. Chinese porn site it was thereafter …
People bookmark stuff. Random systems (including ones you don’t own) have hardcoded urls. Best to pay for it forever since it’s so low of a cost and someone taking over your past domain could lead to users getting duped.
A friend of mine recently let the domain used for documentation of Pykka, a Python actor library, expire. Some of course registered the domain, resurected the content and injected ads/spam/SEO junk.
Since the documentation is Apache License 2.0 there isn't much one can do, other than complain to the hosting about misuse of the project name/branding. But so far we haven't heard back from the hosting provider's abuse contact point (https://github.com/jodal/pykka/issues/216 if anyone is interested).
> As part of our research, we discovered that a few years ago the WHOIS server for the .MOBI TLD migrated from whois.dotmobiregistry.net to whois.nic.mobi – and the dotmobiregistry.net domain had been left to expire seemingly in December 2023.
Never ever ever ever let a domain expire. If you're a business and you're looking to pick up a new domain because it's only $10/year, consider that you're going to be paying $10/year forever, because once you associate that domain with your business, you can never get rid of that association.