Ask HN: What TLD do you use for local development?
27 comments
I use a subdomain and run it in the form of dev.<myactualdomain>.com . I add a record to my /etc/hosts file to redirect it to 127.0.0.1. This also means for https stuff I have a valid certificate to use as well. One more note. I almost never run anything on any port other than port 80/443. Any application I work on generally has nginx sitting in front of it with a simple proxy_pass rule.
I have historically used .local despite its use with the Multicast DNS Standard. I have not encountered any technical issues with its use.
If my devices were on a network accessible from the outside world, I would have used my ghostfreeman.net domain and submasked all of those projects. However, these resources can't leave the network.
If my devices were on a network accessible from the outside world, I would have used my ghostfreeman.net domain and submasked all of those projects. However, these resources can't leave the network.
Since no one has mentioned this one yet, I use '.loc' throught /etc/hosts
Each dev on the team use the same .loc domains but the IP may be different depending on the IP the Docker interface is assigned.
Each dev on the team use the same .loc domains but the IP may be different depending on the IP the Docker interface is assigned.
I use dev.projectname.com
192.168.1.2 FTW!
IP address are NOT TLD's.
the OP asked " or do you just forgo the domain all together and use your local IP"
A digit is allowed to be a TLD, and is easy to type[1]. UIs will probably treat an all-numeric address as an IP though.
[1] https://cr.yp.to/djbdns/dot-local.html
[1] https://cr.yp.to/djbdns/dot-local.html
[deleted]
I just use a subdomain of a domain I own
Do you actually set the A record for it, or do you just set it up in /etc/hosts? Seems risky if it's the first.
I set a hostname on my router's dnsmasq service usually
Why risky?
You're needlessly exposing private information about your system to the public, which an attacker can use to learn about the structure of your setup, or to appear more credible during a social engineering attack.
And if the IP of the development system happens to be publicly routed, attackers might reach and infiltrate a probably insecure development system.
And if the IP of the development system happens to be publicly routed, attackers might reach and infiltrate a probably insecure development system.
Ah yes I would agree. However, you're best off using a local dns server to route to a private subdomain. It is handy to use a public facing IP to also point towards your service though, if, and only if, you want it web accessible.
I remember a tile back in early the 2000s when we had a quite nice setup of local dns servers that had internal only zonefiles that resolved names like service.company.local to the internal/dev versions of service.company.com.
Worked quite nicely until the Mac users upgraded to a version of OS X which included Bonjour...
There days Mac OS X does a pretty nice job here all on it's own - this machine I'm typing on here happily answers as Iain.local to the internal network... (For some not-worth-my-time-to-debug reason, our Netgear NAS is a whole lot less reliable with it's Bonjour/zeroconf .local name...)
Worked quite nicely until the Mac users upgraded to a version of OS X which included Bonjour...
There days Mac OS X does a pretty nice job here all on it's own - this machine I'm typing on here happily answers as Iain.local to the internal network... (For some not-worth-my-time-to-debug reason, our Netgear NAS is a whole lot less reliable with it's Bonjour/zeroconf .local name...)
Yeah I heard that bonjour messed up .local, although isn't that meant to be reserved for actual local nets or something?
It's reserved for multicast DNS, which is what Bonjour uses.
I use .lan
local.<mydomain> set it in my hosts file.
I use a subdomain of a domain I own, such as internal.example.com
I can then run a BIND instance with internal.example.com as a root, then map all my services to their own domain if need be.
This is a little overkill for a one man shop, but it's a nice little home development setup.
The one thing you need to configure, if you want it to work out of the box is that your DHCP server needs to send back the IP address of your local BIND service for DNS, else it won't work right and you'll need to manually configure it every time.
An example of where this worked well for me was when I was using one nginx instance to run snapshots of all my clients websites. With nginx, you can set up "virtual hosts" which map a hostname to a configuration block. You could also just edit your /etc/hosts file to accomplish the same thing I guess.
I can then run a BIND instance with internal.example.com as a root, then map all my services to their own domain if need be.
This is a little overkill for a one man shop, but it's a nice little home development setup.
The one thing you need to configure, if you want it to work out of the box is that your DHCP server needs to send back the IP address of your local BIND service for DNS, else it won't work right and you'll need to manually configure it every time.
An example of where this worked well for me was when I was using one nginx instance to run snapshots of all my clients websites. With nginx, you can set up "virtual hosts" which map a hostname to a configuration block. You could also just edit your /etc/hosts file to accomplish the same thing I guess.
I do something similar. My home network's recursive DNS server is a local install of Unbound. Setting local overrides there is very easy, though I don't use it in a hierarchical format. (Unbound refers to these as local-data.)
I use ".test" to respect RFC-6761 [1] which reserves four TLDs: .example, .invalid, .localhost, and .test; as many of us already know ".dev" is owned by Google [2] and both ".local" [3] and ".app" [4] are reserved for the root zone so it doesn't makes any sense to use any of them for local development. So I use ".test" for my personal projects and ".[company]" for projects related with my job.
[1] https://tools.ietf.org/html/rfc6761
[2] https://icannwiki.com/.dev
[3] https://tools.ietf.org/html/rfc6762
[4] https://icannwiki.com/.app
[1] https://tools.ietf.org/html/rfc6761
[2] https://icannwiki.com/.dev
[3] https://tools.ietf.org/html/rfc6762
[4] https://icannwiki.com/.app
.local is reserved, but not for delegation in the root zone. RFC 6762 reserves it for Multicast DNS on a local network.
.local will also cause massive delays if you have a mac on your network
Thanks for the solid information! I like me some standards, might have to start using .test from now on.
My local network has a proper domain, so I use a subdomain for any dev work.
I edit my host file and use .dev for specific domains, if you configure a web server to said domains it'll route you to the right folder as well (edit: Virtual Host). Though I typically use Vagrant or VirtualBox to test my environments off a 'remote' server.
It doesn't matter. Use anything fake/non-public.
On the contrary, it does matter. What if you used [random].com and someone registered it? Presumably you'd use a different TLD and the chances are slim, but it's still best to use a correct test URL.
The chances would not be slim. They'd be zero, because you'd be using a fake TLD.
.dev used to be a fake TLD, as did .local. Both now exist.
Don't assume what doesn't exist now won't exist in the future. ;)
Don't assume what doesn't exist now won't exist in the future. ;)
I agree that's it not really a big deal, but there are unforeseen consequences that can be mitigated by simply using the correct domain. So why not, what's to lose?
I don't know what "correct" means. There's no "correct" fake TLD. People use different things.
If you mean "correct" as in the production domain, then you're introducing a security risk for no reason. Never use a public (or potentially public) domain for testing or development.
If you mean "correct" as in the production domain, then you're introducing a security risk for no reason. Never use a public (or potentially public) domain for testing or development.
There actually are correct fake TLDs, specifically reserved for this exact use case: https://tools.ietf.org/html/rfc2606
Are there any issues with just using something like `localhost:3000`?
1) Subdomains. If you're app utilises subdomains, you need to use a TLD.
2) Integration with development tools like http://pow.cx/ or https://github.com/puma/puma-dev allow you to automatically startup and shutdown apps. This is useful when you're juggling multiple apps.
3) Security. Using a standard domain/port for local development opens you up to exploits like http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole...
2) Integration with development tools like http://pow.cx/ or https://github.com/puma/puma-dev allow you to automatically startup and shutdown apps. This is useful when you're juggling multiple apps.
3) Security. Using a standard domain/port for local development opens you up to exploits like http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole...
No, that's fine--it's only an issue if you depend upon CORS and cross-domain cookies to test browser-based applications:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
I've found the dev process to be a lot easier if the development environment mirrors the production environment. So I'll spawn jails and/or vms for the database server, for the various bits and pieces of the apps/environment. It means less things that can be forgotten about as an app gets pushed to staging/production, and that documentation becomes easier. Also, names are usually more memorable than numbers, so it helps keep things moving while you're working on things.
I work on a lot of different projects locally, so the username / password auto fill for them needs to be different. Using local host for all wouldn't work.
lvh.me
.bingo has been great.
lvh.me for non-public addresses where I want to test subdomains
ngrok.io when it needs to be public
(yeah, I know those aren't TLDs, but I rarely use any when developing TBH)
ngrok.io when it needs to be public
(yeah, I know those aren't TLDs, but I rarely use any when developing TBH)
I use .dev of course! I realize that .test is the sensible choice, but there's some odd WordPress/Serialization benefit to keeping the TLD length the same.
Google bought it up, and I've never seen it in the wild, so it works well for me.
Google bought it up, and I've never seen it in the wild, so it works well for me.
Ha I actually know what you mean, php serialized data having string length as a parameter always confused me
I use .dev as well for everything.
And as WordPress work makes up a big portion of my paycheck I understand the serialization but haven't worried about it since moving to WP CLI everywhere and adding it to project scripts/automation.
And as WordPress work makes up a big portion of my paycheck I understand the serialization but haven't worried about it since moving to WP CLI everywhere and adding it to project scripts/automation.
wp search-replace 'someproject.dev' 'someproject.dev'
wp export --add-drop-table db.sql
wp import db.sql[deleted]
You can modify your /etc/hosts to point to localhost and that does the trick without having to go through a TLD or care if the domain is taken.
Contents of /etc/hosts:
127.0.0.1 domain.com
127.0.0.1 subdomain1.domain.com
127.0.0.1 subdomain2.domain.com
Contents of /etc/hosts:
127.0.0.1 domain.com
127.0.0.1 subdomain1.domain.com
127.0.0.1 subdomain2.domain.com
I run a local dnsmasq server, and just have the resolver for the 'dev' TLD point to that. This way, any .dev URL always points to my local machine. I just configure it in Nginx and I'm good to go.
Running a local DNS resolver for local development seems like an overkill. You have to have the resolver and nginx properly setup and constantly running (not that it's a issue)
My old router, ddwrt, has this out of the box. My new router, pfsense, has override settings, tho not sure through what daemon that is configured through. I also run a windows domain with DNS. There are many ways to do it.
Same here. But I don't use a TLD. I name it after the app. So, crm_dev, app_dev, etc.
I use .docker because I use dinghy for all my development (https://github.com/codekitchen/dinghy#dns)
I use whatever domain I like + .lvh.me -> 127.0.0.1
local.<domain of site i'm working on> set in my hosts file
Or just "localhost" if it's a personal project with no domain
Or just "localhost" if it's a personal project with no domain
I still use .dev for the majority of sites, I'm pretty pissed that Google was allowed to appropriate it! It has so far bitten me on the ass once when a CDN was involved (the CDN resolved it to Googles servers so the failure wasn't detected - causing numerous invisible problems).
I think I will probably go along the route of assigning a domain to my local network
I think I will probably go along the route of assigning a domain to my local network
One trick is to use non-routable (e.g. 192.168.0.0/16) IP addresses with DNS records for subdomains of your company's domain name, e.g. devserver123.mycompany.com routes to 192.168.100.123
This gives insight to your internal network structure to the public. It's better to run a local DNS server for internal use.
What TLD do you use for local development? or do you just forgo the domain all together and use your local IP?