phelix wrote:With a proxy solution it should be very easy to implement something like this:
mysite.bit ---> whateverlengthydomain.org/somepath/moarpath/
Is "alias" or "translate" from the d/ spec ok to use (what is the difference between these btw?)?
Neither alias nor translate are the right thing to use here; those are for CNAME and DNAME DNS records.
There are 3 application-level redirect methods that have been suggested in the past:
1. HTTP redirect code (I don't recall what error code this would be). This will result in the URL bar showing the target website instead of the .bit website. Many ICANN DNS registrars already support this. It's trivial to implement using DNS and an HTTP server.
2. HTML iframe. This will result in the URL bar being stuck at whatever the first .bit URL is visited. I think some ICANN DNS registrars support this, but it seems less common than HTTP redirects. It's trivial to implement using DNS and an HTTP server.
3. Proxy rewrite/redirect. This will result in the URL bar showing the .bit URL, and links properly change the URL bar. I'm unaware of any ICANN DNS registrars that allow this, probably because it means that all the HTTP traffic goes through the registrar, which is a scalability and privacy issue. It's possible to implement using DNS and an HTTP server that supports proxying with rewrites and redirects; I think this is roughly what would be needed: https://serverfault.com/questions/58658 ... eserve-url
The first two are somewhat simpler, but have worse UX, and I don't think it's feasible to do TLS with them, because the web browser handles the TLS as per ICANN CA rules. (DNS registrars don't use TLS with them either, for cost reasons.) The third is more annoying to implement properly, and rolling our own implementation is likely to cause issues. Nginx is possibly a decent way to do it, if we can get Nginx to grab rewrite rules from ncdns/NMControl (which I believe is possible, but it's been a while since I looked at this). I don't know if TLS can be done safely here. The web browser will see the TLS cert of the local Nginx (and we can make the browser accept only that cert, same as for other .bit HTTPS sites), so Nginx would have to do the cert validation for us based on what's in the blockchain. I have no idea how customizable Nginx's cert validation is for proxying, nor do I have any idea how well-tested those code paths are. I'd want feedback from Ryan on safety before supporting doing TLS for this. Also, I'm pretty sure doing this will break TLS client certs. Other than that, it is not at all clear to me that this is useful behavior in the first place. If you have control of your server, you can do this by configuring the server, in which case you don't need this. If you don't have control of your server, it is unclear to me why you're using a high-security DNS system like Namecoin when you probably have bigger problems.