[Question] Caddy on windows - dns for .local and .localdomain

[rahulmr]

Thanks for the wonderful server.

I need some help or rather guidance on how I can configure servers for .local and .localdomain on my windows machine. My caddy file is simple see below

{
    auto_https disable_redirects
}
localhost {
    respond "Caddy server is running "
}

localhost:2016 {
    respond "Hello World !!! !!!"
}

mywww.local {
    bind 127.0.0.2
    respond "testing mywww.local domain"
}

I have 2 problems here, 1st I need to use the auto_https disable_redirects or else it throws error. 2nd I cannot test the mywww.local url unless I modify the drivers\etc\hosts file in windows.

Is there any plugin or utility which can help to configure this local domains automatically? I tried coredns but seems I am not able to understand it.

I don't want to bind any internal IP. Just a simple configuration like below.

mywww.local {
    respond "testing mywww.local domain"
}

Kindly suggest alternatives.

[rahulmr]

Got a different solution, please close the issue if you want. I was able to work with below configuration.

{
    auto_https disable_redirects
}
localhost {
    respond "Caddy server is running "
}

localhost:2016 {
    respond "Hello World !!! !!!"
}

test.localhost {
    respond "testing test.localhost domain" 
}

myserver-127-0-0-6.sslip.io {
    respond "checking sslipio for local sites"
    tls internal
}

[mholt]

1st I need to use the auto_https disable_redirects or else it throws error.

What error?

Is there any plugin or utility which can help to configure this local domains automatically?

I've often thought this would make a great Caddy plugin :) If anyone wants to build it!

But for now I've found that editing a hosts file is not a bad way to go.

[rahulmr]

There is a good npm package which does this - https://www.npmjs.com/package/hotel

I am not so good yet in developing something on my own like the plugin you said. But yes if this kind of plugin is there, it will boon for developers to test an app locally. Also, a good use case could be creating MVPs for client, where they can actually mock the website locally. But again as you said, modifying hosts file in windows is also a good option but the problem with it is we cannot configure wildcard domains. like below

127.0.0.4 *.test.local

something like hotel can be incredible addon (plugin) for local development.

Anyways, thanks again for your wonderful work and quick responses.

[polarathene]

Just chiming in to point out you should not use .local. That has been reserved for mDNS since 2012. Prior it was documented by Microsoft as an example TLD for ActiveDirectory where it had wide adoption and that continued.

There are several special-use domains that are available instead, which will not be resolved by public DNS, nor will ICANN permit them to ever become public TLDs that can be registered (as happened with .dev and .fritz.box in the past). You may not have problems with .local, but it's not fun when you do encounter them so I strongly discourage that choice. .localdomain is also to my knowledge not valid, but like the risk with any unofficial TLD choice it is not as bad as choosing .local.

In Aug 2024, ICANN make .internal available as a new private TLD. This is often nicer aesthetically than .example / .invalid / .test / .home.arpa options, but you should also keep in mind potential conflict with DNS may exist. In Docker containers .internal is used for a special FQDN to reach the Docker host, while AWS and Google both use .internal within their services too.

.localhost will typically resolve to 127.0.0.1 specifically IIRC, bypassing any DNS / hosts mapping. So it's useful when you need to have different FQDNs on the same host, but would be useless in the context of a container trying to reach other containers for example. No custom DNS or modification of hosts is required which does make it convenient for local testing/development 👍

---

Also, a good use case could be creating MVPs for client, where they can actually mock the website locally.

Just use .localhost for that. Do note this will be treated differently in a browser than localhost (which has exceptions for not requiring HTTPS for sending secure flagged cookies for example).

Just adjust the ports with reverse_proxy if you have a need for routing to other services from Caddy, or consider adopting containers (Docker Compose makes this quite easy, each container has it's own IP and there is embedded DNS, no need for instructions to add custom DNS or modify the host system beyond having Docker Desktop installed).