Possible Impact of losing .io domains and alternatives

[dims]

• Article: https://every.to/p/the-disappearance-of-an-internet-domain
• Discussion on slack: https://kubernetes.slack.com/archives/CCK68P2Q2/p1728467155678289
• Thread on mailing list: https://groups.google.com/a/kubernetes.io/g/steering/c/YY2-Omod1E0/m/gUtXFw05AAAJ

Quote from linked article:

According to Davies, one such change “may involve ensuring there is an operational nexus with Mauritius to meet certain policy requirements. 
Should .io no longer be retained as a coding for this territory, it would trigger a [five-year retirement process](https://www.iana.org/help/cctld-retirement), 
during which time registrants may need to migrate to a successor code or an alternate location.”

Link to policy from @sftim:
https://ccnso.icann.org/sites/default/files/field-attached/board-report-proposed-policy-retirement-cctlds-17sep21-en.pdf

[dims]

/sig architecture
/sig k8s-infra

[dims]

from slack:

@pohly - Go source code importing *.[k8s.io](http://k8s.io/) package is also affected.
@ameukam - The biggest concern would be the public workloads using [k8s.io](http://k8s.io/)

[dims]

from mailing list:

@jdumars - I still have k8s.sh that I can donate to the project.

@mrbobbytables - we do have [k8s.dev](http://k8s.dev/) and IIRC are sitting on a few others as well.

@BenTheElder longer response :)

.dev would be good but ... we're using [k8s.dev](http://k8s.dev/) for other (contributor facing) content already? e.g. [k8s.dev/release](http://k8s.dev/release) != [k8s.io/release](http://k8s.io/release)

We need to be able to potentially move all the *.[k8s.io](http://k8s.io/) endpoints without conflict ...

Also, if we think something like this is likely, we should be bracing for another round of notifying users and redirecting all the things.
We probably shouldn't have ever adopted .io but ... that's history now.

Migrating will be very painful.
Having a reserved alias live in place ahead of time would help.

I would not pick another country code TLD.

[sftim]

Having a reserved alias live in place ahead of time would help.

[ameukam]

Note that this a geopolitical issue still in discussion that go beyond the scope of this project.
If we decide that using a ccTLD is a bad idea regardless of the situation, we should start to establish a migration plan.

[BenTheElder]

/assign

[BenTheElder]

Even if we don't ultimately lose the TLD, we should hedge against this because most of it is not terribly difficult but we will want to take some time in-between steps and give users plenty of time to preemptively switch if they wish. I've been thinking about this problem since the thread last night, here's my proposal:

Background

We own kubernetes.dev and k8s.dev, .dev is a gTLD and while nothing is guaranteed, it is less likely to disappear in the forseeable future than .io (see above). If we have a more "mainstream" gTLD like .org, .com or .net we should consider those, but to my knowledge we / CNCF do not own these. We should NOT use any other ccTLDs to avoid future issues like this, and we already own .dev.

Unfortunately, kubernetes.dev and k8s.dev have already been adopted to host contributor facing content from github.com/kubernetes/community, so they're not merely parked for use currently.

Proposal

1. We should move the contributor content site to a subdomain like community.k8s.dev or contributor.k8s.dev or something similar (we can bikeshed this later if we think the overall plan makes sense). This will only impact contributors, who we have an easier time reaching out to (we can notify dev@kubernetes.io, post in slack, and put up a github banner), and this site has less traffic and exposure than kubernetes.io and k8s.io currently.

2. Once this is in place, we notify the community and migrate inbound links from k8s.dev / kubernetes.dev to the subdomain.

3. Then we can setup *.kubernetes.dev and *.k8s.dev to alias *.kubernetes.io and *.k8s.io. NOT redirect. Alias. Secondary domain. We should automatically enforce identical A, AAAA, CNAME, etc. but NOT txt verification records between kubernetes.io <=> kubernetes.dev and k8s.io <=> k8s.dev

4. We update all serving infra to accept both hostnames and provision certs.

5. Once this is all in place and functioning correctly, we can notify the broader community roughly like:

Subject: k8s.io / kubernetes.io alternate k8s.dev / kubernetes.dev domains now available
Body:

Hello Kubernetes community! To get ahead of the possible turn down of the .io TLD, we have made all resources on kubernetes.io available on kubernetes.dev, and all resources on k8s.io available on k8s.dev. As long as .io remains a valid TLD we will continue to serve all content on .io and you do NOT have to migrate. However we recommend preemptively migrating just in case.

For example instead of dl.k8s.io you can use dl.k8s.dev, instead of registry.k8s.io you can use registry.k8s.dev.
Both will remain valid as long as possible.

kubernetes.io and k8s.io namespaces remain reserved for the Kubernetes project in APIs, labels an annotations. k8s.dev and kubernetes.dev are also reserved along with x-k8s.io, we recommend using a domain you own for any custom APIs.

If you have any questions, you can reach out to SIG K8s Infra at: https://github.com/kubernetes/community/tree/master/sig-k8s-infra#contact

Thank you!

6. We can start to migrate our content to prefer kubernetes.dev / k8s.dev when linking etc.

---

Open questions:
A) Bikeshedding the contributor site subdomain. We'll reach out to SIG Contributor Experience for this one.
B) Do we have an equivalent for x-k8s.io? can we obtain one? currently this is used for unofficial APIs within the project that have not gone through SIG Arch API review (e.g. kind's config format), at one point we gave official guidance around this. We should collaborate with SIG-Architecture to revisit this guidance.
C) Prior to or following 5) should we prepare to change our canonical import path for go packages to k8s.dev? This will cause a lot of churn, but if we don't, eventually imports can break. Just setting up the alias is not enough, since module metadata contains the canonical import path.
D) Do we want to move the APIs out of k8s.io? I personally think the answer is a resounding NO, we can continue to use k8s.io to avoid breakage, it doesn't actually involve the network, but IMHO this question is out of scope for K8s Infra and steering so an official answer would need to come from SIG Arch.

Most of this is actually pretty cheap and easy for us to do, especially as we already own these alternate domains.
C) and D) could be painful, but we could simply opt to punt those for now and still be better prepared. I would personally suggest that we consider C) and reject D).

/triage accepted
@kubernetes/sig-architecture @kubernetes/sig-contributor-experience

cc @jeefy @mrbobbytables re: do we have something else like x-k8s.io, if not can we obtain one? Is anyone currently tracking x-k8s.io ownership even?

[liggitt]

C) Prior to or following 5) should we prepare to change our canonical import path for go packages to k8s.dev? This will cause a lot of churn, but if we don't, eventually imports can break. Just setting up the alias is not enough, since module metadata contains the canonical import path.

I think we have to be prepared to, but I wouldn't do that proactively until it is clear the .io domain will actually go away. That will be enormously painful.

D) Do we want to move the APIs out of k8s.io? I personally think the answer is a resounding NO, we can continue to use k8s.io to avoid breakage, it doesn't actually involve the network, but IMHO this question is out of scope for K8s Infra and steering so an official answer would need to come from SIG Arch.

I definitely don't think we should change API group / annotation / label suffixes from kubernetes.io / k8s.io

[dims]

@BenTheElder note from CRA - https://kubernetes.slack.com/archives/CCK68P2Q2/p1563920528024200

dims 12:28 PM @caniszczyk
Chris, is x-k8s.io now under our control?

...

caniszczyk :rainbow-heart:  6:22 PM
yes [x-k8s.io](http://x-k8s.io/) is, along with k8s.dev

[jberkus]

Couple of notes of caution:

1. It's not 100% that IO is going away. We need to plan for it -- there's at least a 50% chance -- but it's possible that it'll be handled specially.
2. If it does go away, we're talking at least three years according to the article.

That said, the current company managing the IO TLD has been unreliable, so this is a good thing to plan for anyway.

We could try to secure kubernetes.org. It's a trademark.

[BenTheElder]

I think we have to be prepared to, but I wouldn't do that proactively until it is clear the .io domain will actually go away. That will be enormously painful.

I definitely don't think we should change API group / annotation / label suffixes from kubernetes.io / k8s.io

Agreed. I think we should only switch where it's not painful (Serving traffic from both, preferring .dev for web links and advertising downloads), and hold off for go packages.

I don't think it's worth it or necessary for API groups / labels / annotations.

I do think we should assert that we reserve kubernetes.dev / k8s.dev for these wherever we document reserving k8s.io / kubernetes.io, to at least help leave the option open for future project-owned APIs.

---

Thanks @dims! I think we should see about acquiring something like x-k8s.dev, with MUCH lower priority than the rest, since we only use it as a namespace for APIs that haven't been reviewed by SIG arch, to my knowledge ..

---

It's not 100% that IO is going away. We need to plan for it -- there's at least a 50% chance -- but it's possible that it'll be handled specially.
If it does go away, we're talking at least three years according to the article.
That said, the current company managing the IO TLD has been unreliable, so this is a good thing to plan for anyway.

Right, I think we should hedge our bets without actively panic-ing or breaking anything.

We have time, but our experience has been that users need a lot of time to migrate, so giving them the option sooner at relatively low cost seems worthwhile.

We could try to secure kubernetes.org. It's a trademark.

Agreed, I'll go ahead and open a service desk ticket with the CNCF.
EDIT: I filed CNCFSD-2491 to track asking about kubernetes.org and other domains.

[jberkus]

We have time, but our experience has been that users need a lot of time to migrate, so giving them the option sooner at relatively low cost seems worthwhile.

Yeah, I was thinking about websites. The API domain is going to take 3 years to migrate.

[pohly]

C) Prior to or following 5) should we prepare to change our canonical import path for go packages to k8s.dev? This will cause a lot of churn, but if we don't, eventually imports can break. Just setting up the alias is not enough, since module metadata contains the canonical import path.

I think we have to be prepared to, but I wouldn't do that proactively until it is clear the .io domain will actually go away. That will be enormously painful.

Let's call it out explicitly. We would have to:

• change all module k8s.io/* lines in our go.mod files
• change the import comments in package clientgo // import "k8s.io/client-go"
• change all of our own import statements
• publish new releases of everything

Once we have done that, the entire ecosystem will have to switch, including all dependencies. If they don't, a binary might end up having both k8s.io/klog/v2 and k8s.dev/klog/v2 which won't work properly.

Painful indeed.

So painful that I wonder whether it would make sense to ask the Go developers to support aliases for import paths: The client-go go.mod could declare that k8s.dev/client-go is an alternative module name that can be used to import it. If imported under both names in a single module, only one instance under the canonical name must be used. Consumers can switch to the alias as soon as its available, but they only have to when k8s.io goes away.

[sftim]

serving infra

We serve https://kubernetes.io/ as a service (run by Netlify); I imagine we'll need to liaise with them about the aliasing there. We're on an enterprise plan so I expect they'd be friendly.

If we want to have two builds from one lot of source and treat the different hostnames as separate-but-identical, that sounds technically fine too.

API names

If the io TLD disappears, we can still use kubernetes.io within our APIs indefinitely - nobody else will be using the domain either - and I don't see that use as problematic (but that's a question for Steering).

[chris-short]

I'd like to at least mention via K8s Contributor channels that we're aware of the issue potentially impacting the .io gTLD and are planning accordingly. No links to issues, no blog post. cc @kubernetes/contributor-comms @kubernetes/steering-committee

[BenTheElder]

@sftim multiple domain "aliases" for a single site is a standard netlify feature? https://docs.netlify.com/domains-https/custom-domains/multiple-domains/
I don't think we'll need multiple builds.

@pohly agreed. Changing the Go import paths would be enormously expensive. We should not touch that until we have concrete info that .io is winding down. But we could go ahead and ask the Go team about aliases.

See above re: yes we should not touch GVK, it should be fine to continue to use k8s.io in contexts where the network isn't involved.

Thanks @chris-short. We also shouldn't actually need any comms while there isn't an upstream announcement about .io, but we would if there is.

I really strongly suggest we take cheap preventative measures and merely be aware that we may have to do more later. I don't think we need to be worried yet or make big breaking changes.

Setting up an alternate domain for our services is a routine operation for SIG K8s Infra, however previously they have both been .io, and recently the root of .dev has been used for other purposes. So we either need another domain set (like .org) or we need to agree on a suitable subdomain for the contrib site. I think the latter is reasonable, and it may be rather expensive to obtain another short domain like k8s.dev / k8s.io suitable for the APIs (IE for now the registry and downloads, possibly Go imports some day). But we need to agree that we can move it and to what subdomain.

Doing those parts is not high effort, but it does need time to settle.

If we reach that point, then we can discuss notifying users that the alternate hostnames are available (see the draft above). We know users take a very long time to shift hosts, to the point that we're still redirecting traffic from k8s.gcr.io for the foreseeable future and we'll still be receiving a smaller amount of traffic to gcr.io/google-containers (3 hosts and many years ago...) right up through the GCR turn down. So it may be beneficial to go ahead and non-urgently notify users that an alternate gTLD endpoint is available should they wish to preemptively begin to switch.

[chris-short]

From a planning perspective for the contributor site: I think to eliminate any confusion (given the Comms branding is K8sContributors in most places) we could do contributor.k8s.dev as the canonical link and a 301 redirect for community.k8s.dev to contributor.k8s.dev to match industry practices.

This is me looking over the horizon for what likely is a long way off into the future. I think the last thing we'd want is to confuse community and contributor subdomains by using both for different things.

I'll make Comms folks aware of this issue via Slack and hold tight on crafting language. But, Comms is always here to help.

[pohly]

But we could go ahead and ask the Go team about aliases.

If I don't hear otherwise within a week, I'll go ahead and file an issue.

[BenTheElder]

mrbobbytables (who works at the CNCF) in slack:
https://kubernetes.slack.com/archives/CCK68P2Q2/p1728574873011279?thread_ts=1728467155.678289&cid=CCK68P2Q2

lf does not have any other k8s related domains, no idea whos sitting on kubernetes.org / k8s.org so dev would be the way to go

[re: acquiring kubernetes.org / k8s.org versus repurposing kubernetes.dev / k8s.dev]

Specifically regarding the contrib site and the .dev domains, see also: https://kubernetes.slack.com/archives/C1TU9EB9S/p1728497692495869

[munnerz]

See above re: yes we should not touch GVK, it should be fine to continue to use k8s.io in contexts where the network isn't involved.

Would that apply to new API groups too? e.g. if we create the core foo group (let's say after .io has gone away), would we still create foo.k8s.io?

[sftim]

Would that apply to new API groups too? e.g. if we create the core foo group (let's say after .io has gone away), would we still create foo.k8s.io?

No need to decide that part yet; the key things to plan are around actual network services, where having (and announcing) an early plan is useful.

[sftim]

/lifecycle frozen

Change this if frozen doesn't feel like the right fit.

[BenTheElder]

Would that apply to new API groups too? e.g. if we create the core foo group (let's say after .io has gone away), would we still create foo.k8s.io?

I think we punt that for now. IF we get to a place where .io is shutting down or we're otherwise losing the domain, we can consider it.

I doubt we would just to avoid confusion versus all the existing API groups that we're unlikely to ever move anyhow.
Not worth breaking people over something that doesn't touch the network anyhow ...

---

CNCF got back to me on the service desk, they also have have:

kubernetes.solutions
kubernetes.training

Aside from the above mentioned .dev an .io domains.

Other .io domains the project owns besides k8s.io / kubernetes.io

• x-k8s.io: (mentioned above, we own this for clarity and use it for unofficial APIs, we likely do nothing here)
• etcd.io: docs, playground, go.etcd.io import aliases ...

This repo feels like the wrong place to track etcd.io, filed etcd-io/etcd#18744

EDIT: see also: etcd-io/etcd#18744 (comment)

---

It seems like we're not readily getting another domain for the project (#127966 (comment) plus further discussion in slack), so I think we should again look at migrating the contrib site to a subdomain so we can go ahead and park kubernetes.dev / k8s.dev as backup domains.

[sftim]

We might want to liaise with CNCF about phippy.io too.

[BenTheElder]

We're currently waiting on a broad plan on the CNCF end for any new domains (xref: etcd-io/etcd#18744 (comment))

On our end I still think we should prepare to shift k8s.dev / kubernetes.dev to a place where they can be used as alternate domains, by migrating content off of the root onto a subdomain and matching 1:1 with .io, before we get even more inbound links to this relatively new and largely contributor facing site. It's unlikely we will get another k8s.$something.

I'll probably reach out to contribex + infra again after kubecon at this point.

[ameukam]

FYI: https://www.icann.org/en/blogs/details/the-chagos-archipelago-and-the-io-domain-14-11-2024-en

[BenTheElder]

Also on the CNCF's end, from the service desk ticket we were not able to obtain any additional domains. So it remains true that if we have to phase out .io in the future we would need to repurpose .dev as the alternate.

The problem with waiting is that we will have more inbound traffic to the current .dev content, if we align that content on a subdomain sooner, then we can make .dev / .io match 1:1 without breaking as many links etc., given the relatively recent introduction of contributor facing content on .dev

From past experience we know that it takes years to move hosts with lots of traffic, and is generally a big pain. It will not be a big pain if we preemptively secure 1:1 alternate domains, but for now we only have kubernetes.io : kubernetes.dev, k8s.io : k8s.dev to work with.

[jberkus]

Yes. If ICANN is going to shut down IO, though, they'll have a minimum of 3 years sunset period. So we can wait for the announcement to take action, unless there's some other benefit to making the transition regardless.

[sftim]

Hey, we also (kind of) have downloadkubernetes.com as a domain we can use.

[BenTheElder]

Yes. If ICANN is going to shut down IO, though, they'll have a minimum of 3 years sunset period. So we can wait for the announcement to take action, unless there's some other benefit to making the transition regardless.

Because if we wind up having to do it later, the cost to move k8s.dev be higher (more inbound links to k8s.dev), and it should be a lot less impactful to do now while it's more nascent. The other parts can wait. We can leave redirects in place for a long time if we start earlier because we don't actually need the domain root yet.

We have past experience that moving domains is irritating and takes many years and requires redirecting traffic during the transition. If we can cheaply get ahead we should just do that and then shelve the rest (go imports, etc).

[BenTheElder]

I spoke with a couple of the contribex leads this week, we will follow up on that part in the near future.

[pohly]

It took a bit longer than originally said, but now I filed a Go issue about supporting module aliases.