I’ve used GitHub - auto-ssl/lua-resty-auto-ssl: On the fly (and free) SSL registration and renewal inside OpenResty/nginx with Let's Encrypt. on some SaaS projects that need custom domains. It is Lua and nginx…I have no idea what DFINITY uses on the nodes.
1 Like
Only re-iterating what others have already said, but would be in favour of:
- Being able to point any domain name to a canister
- Only implementing custom subdomains as an interim if there are significant technical barriers to the above
- Not sidetracking things with the .icp TLD (it suggests vendor-lock, which is not a good thing IMO)
7 Likes
Regarding the first two bullet points in the Tricky Parts section:
Public announcements of the IC’s DNS developments and several notices before launch + perhaps incentives for IC ecosystem participants (stakers, etc.) would be the most legitimate foundation for how to do it, in my opinion.
Or…maybe have the community vote through the NNS on whether to do a set of customer Canister names that are auction-only – auction would be priced in ICP and be held for the first X days after the system is live.
What I think you don’t want to have happen is to turn the entire DNS into a bidding war, but for some names like the subset you seem concerned about, the auction idea is worth considering. Some component of first come first serve needs to be in there.
1 Like
Arbitrary domain names please, and if extremely difficult subdomains only as a temporary solution.
4 Likes
Hey!
This is the creator of ICME. People keep asking me about how to setup their own domains.
CNAME: if this worked it would be great.
Currently doing A NAME records to point to the ‘vanity’ IC URLs 
This is of great importance to get resolved. For SEO, and normal people being able to find and remember their favorite IC apps. Think of the use case from a blogger, EC site, etc, if no one can find their product or easily forget the URL they do not get business. Many want to transfer over to the IC, but cannot if their sites vanish from the web. SEO and domains are very important to most people.
They do not care about the tech to get it done, they care about their bottom line.
Really good suggestions above. Having CNAME work for any domain would be ideal. Heroku has some setup which seems similar to me. They have arbitrary domains names for apps. something.heroku.com. You can add a custom domain name: mysite.com. And then apply SSL that they do for you.
After that you just point a CNAME record to something.heroku.com
9 Likes
Amen. I don’t know why this seems to be a controversial idea…
2 Likes
Custom domains are going to happen, it is just a question of when. In the meantime it is possible to set up your own via simple free static hosting e.g. GitHub - jplevyak/icfront: Secure custom domains for smart contracts on the Internet Computer.. Stay tuned for a proposal.
17 Likes
Fantastic news. 
2 Likes
Thanks for the Firebase hosting info, I’m going to give it a try.
One of my key reasons for going all in on the IC is to fully escape from the Google ecosystem but this is a great temporary solution.
fwiw, the solution @jplevyak posted above uses Firebase only because that is what he is more familiar with, but it is not tied to it for any particular design reason (just an implementation detail).
3 Likes
Understood. I’m not criticising, it was just a remark. I’m grateful for a working solution but still excited by the prospect of native custom domains on the IC.
3 Likes
oh i did not take it as a criticism (sorry if my wording made it sound like that), I just wanted to make clear that savvy hackers can retrofit the solution John posted to their platform of choice
4 Likes
No problem at all. I am so excited to see this moving forward.
2 Likes
A bit late to this thread but here’s my two cents.
As a developer there are more technical priorities than custom URLs.
However having spoken highly of the IC and showed about a dozen friends website such as DSCVR the returning theme is the “suspicious/scammy look” of the current URLs
Overall for proper “mass” adoption custom URLs will be an essential stepping stone.
7 Likes
I don’t see nice-name.ic0.app, user-supplied custom domains, and full DNS served by the IC as mutually exclusive – I think they extend or complement each other. nice-name.ic0.app is technically easier to achieve than arbitrary custom domains for the reason @nomeata pointed out: TLS and certificate handling. nice-name.ic0.app essentially lets us use the existing certificates, at the cost of handling sub-domain name registration on the IC as stated by @nomeata above.
@jplevyak’s IC front tooling is certainly a great step forward for projects that anyway assert centralized control over their canisters – which I believe are most projects on the IC at the moment – as those can use the tools to have custom domains right now. At least it can be a stepping stone until the IC properly serves custom domains. Using these tools won’t really be an option for Open Internet Services, though, since IC front itself will still need to run in some centralized setting.
Serving DNS from the IC is certainly a great long-term goal, but doing this in a way that is both decentralized and secure requires a few components that we’re still building – such as threshold ECDSA signatures.
6 Likes
It might be worth pointing out that custom domains (nice-name.com) are in some sense easier than nice-name.ic0.app domains: With nice names, we’d have to build a registry with canister mapping, ownership, etc. Not hard, but a big load of bikeshedding to be done, with many cooks involved.
But with custom domains, the registry exists already: DNS! A TXT record in the nice-name.com DNS record can tell the HTTP Gateway (or service worker) which canister to forward to, and maybe whether it’s raw or certified. So assuming the TLS problem can be solved easily (automatic letsencrypt certificates), this seems to be easier in reach than nice subdomains. And much more impactful, I guess.
So it might be a fallacy to consider custom domains an extension of nice name subdomains, and thinking of it like that might block us from the actually easier path forward.
3 Likes
You’re right in that there is no strict order on the difficulty of building the first two. Solving the TLS problem is one project we’re actively working on, but we also know that a solution that we find acceptable from a security standpoint will still need a bit of time.
2 Likes
I see this as a moot discussion. The solution is obvious. Once Threshold ECDSA is implemented, we can just build the ACME protocol (rfc8555) into the Gateway nodes, and they will be able to participate directly in the X.509 certificate process. The CA (Let’s Encrypt in this case) would simply see the boundary node as the correct endpoint, and the boundary node would get a valid LE cert for any domain managed by the IC. I hope this makes sense. It does in my head. This is the explanation of how it works right now (How It Works - Let's Encrypt). The “Web Server Admin Software” could just be replaced with “IC Boundary Node.”
1 Like
I don’t think the boundary nodes would do this, I don’t think they participate in consensus thus will not have access to the threshold ECDSA. But I imagine some canister system will be implemented to handle certificates.
4 Likes
I’m the one who registered ic.app 
3 Likes