github.com
Please; easy on my go code :-). I am a total beginner with go. PRs welcome.
1. DNS means a lot of things in reality. It can be an authoritative name server, a caching resolver, a recursive resolver, any combination of those and then some. While you mentioned the type for godns here, it's missing in the readme. Without that information there, it's hard for a visitor to decide at a glance if it's something they're interested in. I suggest that the first sentence in a readme be one that conveys the technical purpose of the project in as few words as possible.
2. While not a popular opinion, naming the project after its programming language might seem unimaginative or like language zealotry - even if the author didn't intend it. Sometimes it even leads to confusion. For example, it won't be surprising if people think that goreleaser is a dev tool for the go language alone (which it was initially), though it supports more languages now. In your case, I was wondering what 'god ns' means! Try an imaginative name that projects the personality of your project. It's fine to mention the language afterwards (ProjectK made with Go). (This applies to all languages including Rust).
3. Editing /etc/hosts is not hard by any means. So it's questionable what another resolver is going to add. However, one thing I find difficult with hosts file is adding wildcard domains. I had to use dnsmasq for this. Dnsmasq is also an overkill for such use cases. You should consider that feature. Better yet, regex domains perhaps? Another idea is to have a simple API that could be served through a unix socket. That way, regular users with permission can quickly add records programmatically or using a CLI client. Perhaps there can also be an API call to discard or persist the changes (like how firewalld does it) without root permissions. This would be very useful for local web app development along with a tool like mkcert.
4. The choice to use the cloudfare resolver is reasonable. But not everyone may like it, due to privacy concerns. There should probably be a way to specify something else - perhaps from DHCP too.
5. It looks like you are serving A records. That is a very reasonable default with sufficient use cases. But other options like TXT records are not usually available for temporary local uses, unless you setup a full blown authoritative server. That would be a useful addition too.
That's it for now. Feel free to utilize these suggestions however you like. Good luck with this and your future Go projects!
1.) Agree, need to add a description to the README. Will do.
3.) Wildcard record support would be cool. Also want to support hot loading of hosts.json without needing to restart the server. Building an API is probably not going to happen (time constraints), but hot loading support allows users to use their tools of choice to simply modify the hosts.json file.
4.) Yup, the ability to override the default fallback DNS resolver is needed. Most likely will implement as an ENVAR.
5.) Serving TXT and other record types probably not going to happen (again time constraints).