Documentation for how to set up Windows DNS?

[petemounce]

I had a look and didn't find any recommendations for setting up Windows (Server) to make DNS queries against consul (and, if no match, pass them upstream).

I found the recursor configuration parameter, which sounds like what I want.

Should I then configure my Windows NIC settings to consul as DNS server? If so, then what if the agent is not running (I'm intending for all hosts (mostly Windows) that use consul for anything to also be running an agent) - set consul as primary, and non-consul as backup? That sounds like it would work (although I don't know Windows' DNS behaviour - whether it queries both and takes the quickest thing to respond, or what)...? It doesn't sound as good a solution as dnsmasq, though - but I don't think that exists for Windows.

Just hoping there are some recommendations that I missed, otherwise I'll dig in and report back what I did...?

[armon]

@petemounce I think what you suggest should work! DNSMasq is useful to avoid running Consul as root to bind to port 53. I'm not sure if Windows lets you specify a custom port, if not you may need to run with elevated privileges to bind to that port. Using a non-Consul node as a backup DNS also makes sense, should be fine!

Sorry I can't be of more use, I haven't worked with Windows in a while and am not quite sure what the best way would be.

[petemounce]

I've fallen at the first hurdle - I don't see an option to make Windows DNS use a non-standard port (and, being a windows guy, I don't know how to run consul with elevated privileges yet).

[petemounce]

I'm going to experiment with netsh portproxy on windows to forward 53 -> 8600.

I may be some time.

[armon]

It may be easier to just run Consul with higher privileges and bind to 53. I'm not sure if there is BIND for windows, but that is an alternative as well to do forwarding.

[petemounce]

So (for posterity, as I go...), windows has out of the box support for TCP port forwarding via

# show rules
netsh interface portproxy show all

# add tcp rule for consul - this persists between reboots
netsh interface portproxy add v4tov4 listenport=53 listenaddress=0.0.0.0 connectport=8600 connectaddress=127.0.0.1 protocol=tcp

# remove rule
netsh interface portproxy delete v4tov4 listenport=53 listenaddress=0.0.0.0

... but that doesn't support port 53.

[petemounce]

I ended up not forwarding ports, but:

• run consul so dns is port 53

{
  "ports": { "dns": 53 }
}

• add consul as a DNS server netsh interface ipv4 add dnsserver \"Ethernet\" address=127.0.0.1 index=1
• use AWS VPC DNS server (that was findable with either netsh interface ipv4 show dnsservers or ipconfig /all) as consul's recursor configuration option.

[mynkow]

@petemounce I am in exactly the same situation as you. Could you please share what setup do you use 2.5 years later.

10x

[highlyunavailable]

@mynkow When I used Consul on windows I ran it as a service with NSSM and set the AWS VPC DNS servers are recursors just like Pete, without using port forwarding.

[mynkow]

10x @highlyunavailable. I guess that to discover a service you hit explicitly consul's dns with this setup.

BTW, any reason to not use consul as a service discovery?

[highlyunavailable]

I'm unsure as to what you mean by "why not to use it as service discovery". I explicitly used it for service discovery and it's a great service discovery tool. If you mean "did I use the HTTP discovery APIs?" the answer was no because I was using it explicitly for the DNS resolution so I didn't need to make code changes for discovery.

The setup was like this: AWS VPC Cluster of 3 Consul servers (Linux at the time since Windows was not a supported server) Each Windows Server box had a Consul Agent set up to listen for DNS on port 53. Since this was before the AWS EC2 discovery code was even in Consul (this was back in the 0.5.0 days) I used another script to populate the retry_join server list with the Consul Servers. Nowadays use the EC2 discovery to look them up. Upon Windows Server after Consul install/join, I set the DNS IPs and restarted the Dnscache service. Each Windows Server box had DNS set up to point to 127.0.0.1 and 10.x.x.x (The AWS VPC DNS server) as primary/secondary respectively. Consul itself had 10.x.x.x as a recursor.

Each box was "its own" local DNS server in this topology, using the Consul Agent as the DNS proxy/recursor for everything. It would fall back to AWS DNS if Consul had not started yet or if it had died and could not be restarted.

So yes, if I wanted to look up a service, I'd look up myservice.service.consul or something.