Change default tld to .test

[DanielSousa]

According to RFC 2606

".test" is recommended for use in testing of current or new DNS related code.

and

The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.

.localhost has conflicts with Chrome and MacOS https://bugs.chromium.org/p/chromium/issues/detail?id=455825

If approved I can create a PR.

[JeroenBoersma]

@DanielSousa thanks for bringing this up... We had the same before on the hijacked .dev domain by Google...

dev setup let's you choose a tld or if you already ran this command, change .env DOMAINSUFFIX to whatever you want...

Changing this default behavior could result in unexpected behavior on existing installation.

I even know users which use a shared valid signed and shared wildcard on a whole other .tld(or domain)...

Please discuss a little more.

[DanielSousa]

What I was suggesting was for new installations not on current installations. When the user runs bin/dev setup, the system asks if he wants to use a custom TLD otherwise it will use .localhost https://github.com/JeroenBoersma/docker-compose-development/blob/1f62c24ee487ceec2f3671971671111cfa728c76/bin/dev_command/setup#L70

[JeroenBoersma]

So, related to https://github.com/JeroenBoersma/docker-compose-development/issues/37

I've put a lot of thinking in this after struggles with colleagues/people having trouble setting up DNSMASQ on Ubuntu machine for instance.

Because the .localhost translates so well to localhost there is a big change that even without running a DNS server locally everything will work right away, so no DNSMASQ needed.

That's why I think we should stick with the current default which serves less struggle for most.

[RenanLazarotto]

I really don't want to get in the middle of anything, but I've found an easy solution to deal with DNSMASQ: https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq-and-systemd-resolved/516808#516808

This helped me a lot when I was first trying your containers. Might help someone else, too. :)

[JeroenBoersma]

@RenanLazarotto that's helpful information which resolves the problem for existing systemd users, but not a out-of-the-box solution...

In the past when first setting this up I really loved the .dev extension Google hijacked, but when the project started serving a bigger audience keeping it without additional services is the better default.

Still think this information is helpful for people if they run into such things, so thanks.

Out-of-the-box: I played with the thought of providing browsers via docker containers which already have the correct dns: dev browser chrome or dev browser firefox or dev browser edge This way you could isolate the problem into containers which could just have the correct tld's. Also a easy way to start all over...

You could also use proxies for instance.

Of coarse there are a lot of downsides to this too, working with your favorite tools. Working in your daily extensions, etcetera.

This is why I never started working out that idea.