Change TLD for test sites

[pento]

As Google has applied for control of the .dev TLD, there's the potential for all sorts of weirdness to occur if their application is accepted.

Per RFC 2608, Section 2, .test, .example, .invalid and .localhost are the only TLDs guaranteed to never be allocated.

[westonruter]

.localhost seems particularly appropriate among these options. But what about .local?

[zamoose]

That has too many overloaded meanings in a Bonjour environment. Unless specifically going for such a la VIP QuickStart, it may be more trouble than it's worth.

Doug Stewart

On Feb 28, 2015, at 9:00 PM, Weston Ruter notifications@github.com wrote:

.localhost seems particularly appropriate among these options. But what about .local?

— Reply to this email directly or view it on GitHub.

[michaelbeil]

.test would seem to be the better of the options.

[jeremyfelt]

I'm up for .test as well. We can probably introduce the new TLD in the configs while continuing to support old .dev installations.

[cfoellmann]

I would vote for .localhost since it would make the most sense to me. .local can not be used because it would clash with directory and other services.

We need to reach some kind of consensus here and can add the tld to the configs of the sites while keeping the current domain endings for the time being.

[jeremyfelt]

Ok, feedback time.

Options:

• .localhost
• .test
• .local

I excluded .example and .invalid because they don't seem right. Decisions. :)

Please leave a comment, this is super serious stuff.

[raulillana]

Short is best. I would go for dot test.

[richardtape]

Edit (after finding out that local is avail.): Could it not be a choice on provision? If not, I'd prefer .local over the other options

[jeremyfelt]

Per @rmccue, .local is a valid option too. IMO, better than .localhost. https://twitter.com/rmccue/status/701526969008062465

[johnbillion]

.local

[morganestes]

.test

I'd like to avoid potential problems with Apple and .local.

[lucyllewy]

if we opt for .local, can I suggest that some work be put towards setting-up avahi/zeroconf/mdns/bonjour support so that we don't need to utilise the hostsupdater plugin (which doesn't seem to be working for me atm)

[rmccue]

.local is super neat, since it's very easy to use with Avahi. Just install avahi-daemon via apt-get, and you're basically done. No messing about with hosts files, no installing vagrant-hostsmanager/etc, just done. Works automatically on all OSX systems, most Linux desktops automatically (or install avahi-dnsconfd on Ubuntu), and Windows systems with Bonjour installed (i.e. iTunes, Bonjour Print Services, Adobe CS3+ installed, or install manually. (Check the Chassis instructions.)

That is: intentionally use Zeroconf/Avahi. You can also use the dbus interface to avahi to automatically add subdomains if you want, although it's tricky.

[jeremyfelt]

Other .local reading material (I haven't parsed it yet): http://www.justincarmony.com/blog/2011/07/27/mac-os-x-lion-etc-hosts-bugs-and-dns-resolution/

[rmccue]

Other .local reading material (I haven't parsed it yet):

This stuff only applies if you're using the hosts file, by the way. Zeroconf itself is pretty flawless (although Avahi not so much).

[cfoellmann]

.local providing zeroconf sounds excellent

[GaryJones]

Not .test. Local sites are not necessarily test sites.

[frozzare]

.local

[ntwb]

Today I learned statistics for the L root name DNS server operated by ICANN

"As of August 14, 2015, that server has received approximately 1331 .local queries per second, third in frequency after .com (4355 queries per second), and .net (2481 queries per second)"

[iandunn]

The anal-retentive perfectionist in my head strongly prefers .localhost over .local, since it's more descriptive, but if .local makes configuration easier and removes a point of failure -- especially given https://github.com/cogitatio/vagrant-hostsupdater/issues/92 (cc @diddledan) -- then that's more important.

I agree with Gary that .test doesn't really describe what VVV sites are typically used for.

[mikesprague]

.local

[bradp]

.dev for life

Nevertheless, vv will adopt whatever VVV adopts.

[Viper007Bond]

@iandunn's comment sums up my thoughts exactly. .localhost is more correct and "better", but if .local brings more things to the table than just less characters, then it probably makes more sense to go that direction.

[rclilly]

I think that as long as VVV is using the hosts file on the local computer for name resolution, even if Google gets the TLD .dev, the local hosts file will override any potential conflict. Having said that, I echo @iandunn's and @Viper007Bond's sentiments: .localhost is more accurate but if .local makes things easier that works too.

[morganestes]

I originally voted for .test because of my concerns for how .local is handled by mDNS. After some additional research, I don't feel that .test is really the appropriate TLD, but I still feel that .local isn't appropriate, either.

Since we rely on local hosts files to manage DNS, .localhost seems to be the most appropriate for our use. RFC2606 lists four internal TLDs with descriptions; RFC6761 goes into even more detail about the TLDs. Based on these docs, it seems that .localhost is the most likely candidate to replace .dev, based on how VVV uses domains and how its use is defined.

[raulillana]

If the point is to make sense, this should go a bit more specific like .dev was.

I update my vote from .test to .vvv (and .vv for @bradp :stuck_out_tongue_winking_eye: ).

[iandunn]

I think .vvv was rejected as an option because it's not a reserved TLD. ICANN could issue .vvv to a registrar at any point in the future, and then we'd be right back in this same situation.

[raulillana]

I don't think Vietnamese Viagra Vendors request that TLD, but ok. :_)

Anyway .local and .localhost feels like out of the (virtual) box.

[dnblankedelman]

I don't want to rain on the "naming the band" discussion, but the testing I was doing to deal with #810 leads me to be concerned that the /etc/hosts approach may not be long for this world. If indeed one has to go to a dynamic DNS based-approach, the suffix may be determined for us.

That being said, if indeed I'm confused and /etc/hosts still remains a bright and vibrant future, I support @morganestes rationale for .localhost. There's lots to be said for using a name blessed by the RFCs.

At the very least, maybe make the domain suffix be easily changeable in the Vagrantfile or a known config file? (right now, there's a partial implementation of this idea using www/vvv-hosts) Then it could say "We recommend .localhost, but you should choose a suffix not in use in the real world." If you want to be really cool and impress your friends, the provisioning could do a quick lookup and say "hey, I can resolve vvv.something already, that seems bad and is likely to cause you strife, are you sure you want to do this? (y/n)".

[ntwb]

@FYI: .local is a reserved multicast DNS domain see https://tools.ietf.org/html/rfc6762

i.e. We can use .local as it is reserved and with the extra benefits noted here I think its win-win

[rclilly]

I guess that leaves us with .localhost.

[raamdev]

My vote is for .localhost.

I'm partial to .dev (given my name) but given the above options and the fact that .local is a reserved multicast DNS domain and may introduce some as-of-yet-unforeseen confusion and gotcha's around configuration of VVV, I'd say that .localhost makes the most sense here.

[ottok]

I've used .local (with the Zeroconf benefits) on our company standardized Vagrant box for WordPress development for some time and it works great. I really hope VVV would use .local out-of-the-box.

[smcjones]

As long as you don't mind being inundated with issues relating to link-local collisions, this is a solution. I strongly suggest there be a way to choose TLD in configuration. That also lets someone use their own private domain, which is even better. local.wordpress.[example].[com]

[cgrymala]

FYI, I encountered this on Windows (where I'm running VVV inside of Hyper-V instead of VirtualBox, and where I've never been able to get the automatic vagrant-hostsupdater plugin to work, so I have to manually edit my hosts file), and found that the issue appeared to be related to how many domain names were defined on each line of my hosts file (or, possibly, the number of characters).

For me, once I added a 10th host name to a single line, I started getting the ERR_ICANN_NAME_COLLISION error in Chrome, but once I split those host definitions onto two separate lines, the error went away.

Just a possible troubleshooting suggestion for those that might be running into this issue.

[jeremyfelt]

As #1282 says, it's time to get rolling on this. :)

[morganestes]

I've been using some other local dev environments that still use a local hosts file with custom TLDs instead of zeroconf. In that vein, if VVV moves to a zeroconf system, then it makes sense now to implement it with .local, else use .localhost since it conveys better what VVV is used for.

[cgrymala]

Implementing with .local would be extremely problematic, especially if it wasn't easily configurable. The .local extension is used pretty extensively within enterprise to represent everything inside the corporate firewall (including, but not limited to, anything related to LDAP/Active Directory).

[raamdev]

Relevant to the discussion here, it sounds like Chrome is going to start forcing .dev domains to HTTPS via preloaded HSTS (Google owns the .dev TLD).

There's also a proposal to add the .localhost domain as a new standard, so it sounds like using .localhost for test sites is the best option at this time.

[benlk]

Copying in @leewillis77's comment from Laravel's valet, which has the same problem: https://github.com/laravel/valet/pull/436#issuecomment-330578317

Just for reference .localhost is defined to have some non-standard behaviour. Of relevance, it's defined to always resolve to the local loopback address, so using it precludes you from mapping anything under the TLD to an address other than 127.0.0.1. The TLD also specifies (same RFC) that any DNS request other than an address query should fail which again may cause issues somewhere (think querying for TXT, or MX records etc.)

.test would seem more flexible as it's defined to act "normally".

[tomjn]

I've created PR's for the dashboard and the default stable WP install. I've also added warnings on the new dashboard for sites that have .dev TLD's so that people are aware:

New installs will get the .test domains, and existing installs will accept them but WP internally will have .dev in its DB, I'm evaluating options as to wether a search replace will work, or if it's as simple as just changing the site URL. I don't want to break everybodies local environments doing the change

[rmurillo21]

We use a WP site URL migration script. Would that be useful here to migrate an install to a new TLD?

[tomjn]

@rmurillo21 a WP CLI search replace should be enough, it's more the risk involved that's concerning

[grappler]

Could we add some documentation what is required to migrate to .test? Even just adding a comment that one needs to do a search and replace on the DB would help.

[fumikito]

As @cgrymala mentioned, I also don't recommend .local domain for default. In some networks like a big enterprise's intranet, you may be redirect to unknown IIS server. It requires hard googling.

[rmurillo21]

@grappler I think the process is still being tested, to determine best route.

I did a quick search for local.wordpress.dev in project folders, and a global search/replace to local.wordpress.test looks pretty straight forward, with no unintended replacements.

For the DB, others have suggested a DB level search/replace: wp search-replace 'local.wordpress.dev' 'local.wordpress.test'

Follow that by a vagrant reload --provision

This should work but I have not yet tested. YMMV - Just wanted to outline a possible process.

For my custom sites, I have moved to the .test TLD. All good.

NOTE: The codex also suggests these two options for changing site url:

wp option update home 'http://example.com'
wp option update siteurl 'http://example.com'

[tomjn]

.test is the way forward, and the PR's so far stick to that, dashboard works well on .test here, and .local and .localhost were also added for good measure, but all references to the dashboard use .test as the preferred TLD

@grappler I'd have implemented automated migration but I was hoping other people would advise on the best approach to migrating, be it:

• an automated full search replace based migration in the provisioner ( would do the trick, some potential risk of data damage or accidental changes )
• a prompt in the dashboard with the CLI command ( safest option, but potentially user hostile )
• switching the site URL via wp option ( results in a mixture of URLs, has the least risk )

This also doesn't solve the issue of people who used the custom site template and chose a .dev domain.

For now, I see the PR's as mergeable without the automated migration, as those can be implemented via follow up PR's

As for documentation, I'm happy for a PR with a stub to be created, I'd prefer to have https://github.com/Varying-Vagrant-Vagrants/varyingvagrantvagrants.org/pull/23 merged first though to avoid conflicts and make sure no editorial work is needed so it makes sense in the new format

[tomjn]

PR's exist for all the relevant repos to set the new default to .test, once those are approved I'll work on automatic migration PR's for the 2 bundled site provisioners

[tomjn]

All the relevant PR's have been merged save for https://github.com/Varying-Vagrant-Vagrants/custom-site-template/pull/6 so brand new installs of VVV should be impervious to this issue

I'm going to vote against adding automated migration to the custom site template repo as it's a lot more generic and the risk is substantially higher, but the 2 defaults could use it. I'll work on follow up PR's later this week

[shakefu]

FWIW I just installed on OS X using VirtualBox 5.1.28, Vagrant 2.0.0, and the VVV master (commit SHA 70e9bc4486cf369445c7935407576cd65a90ae1b), and the install is broken - the Vagrant /etc/hosts entry is for "local.wordpress.dev" but all the asset requests go to "local.wordpress.test" which cannot be found. Manually adding the entry for the ".test" domain fixed this.

Let me know if you'd like me to open a separate issue for this (and if this is the correct repository for doing so.)