By default, DNS is served from port 53 which requires root privileges. Instead of running Consul as root, it is possible to instead run Bind and forward queries to Consul as appropriate.
By default, DNS is served from port 53. On most operating systems, this requires elevated privileges. Instead of running Consul with an administrative or root account, it is possible to instead forward appropriate queries to Consul, running on an unprivileged port, from another DNS server.
---
---
# Forwarding DNS
# Forwarding DNS
By default, DNS is served from port 53 which requires root privileges.
By default, DNS is served from port 53. On most operating systems, this
Instead of running Consul as root, it is possible to instead run Bind
requires elevated privileges. Instead of running Consul with an administrative
and forward queries to Consul as appropriate.
or root account, it is possible to instead forward appropriate queries to Consul,
running on an unprivileged port, from another DNS server.
In this example, Bind and Consul are running on the same machine for
In this guide, we will demonstrate forwarding from [BIND](https://www.isc.org/downloads/bind/).
simplicity but this is not required.
For the sake of simplicity, BIND and Consul are running on the same machine in this example,
but this is not required.
### Bind Setup
### BIND Setup
First, you have to disable DNSSEC so that Consul and Bind can communicate.
First, you have to disable DNSSEC so that Consul and BIND can communicate.
This is an example configuration:
Here is an example of such a configuration:
```text
```text
options {
options {
@ -55,7 +57,7 @@ zone "consul" IN {
};
};
```
```
Here we assume Consul is running with default settings, and is serving
Here we assume Consul is running with default settings and is serving
DNS on port 8600.
DNS on port 8600.
### Testing
### Testing
@ -84,7 +86,7 @@ master.redis.service.dc-1.consul. 0 IN A 172.31.3.234
;; MSG SIZE rcvd: 76
;; MSG SIZE rcvd: 76
```
```
Then run the same query against your Bind instance and make sure you get a result:
Then run the same query against your BIND instance and make sure you get a result:
```text
```text
[root@localhost ~]# dig @localhost -p 53 master.redis.service.dc-1.consul. A
[root@localhost ~]# dig @localhost -p 53 master.redis.service.dc-1.consul. A
@ -110,21 +112,22 @@ master.redis.service.dc-1.consul. 0 IN A 172.31.3.234
### Troubleshooting
### Troubleshooting
If you don't get an answer from Bind but you do get an answer from Consul then your
If you don't get an answer from BIND but you do get an answer from Consul, your
best bet is to turn on the query log to see what's going on:
best bet is to turn on BIND's query log to see what's happening:
```text
```text
[root@localhost ~]# rndc querylog
[root@localhost ~]# rndc querylog
[root@localhost ~]# tail -f /var/log/messages
[root@localhost ~]# tail -f /var/log/messages
```
```
In there if you see errors like this:
The log may show errors like this:
```text
```text
error (no valid RRSIG) resolving
error (no valid RRSIG) resolving
error (no valid DS) resolving
error (no valid DS) resolving
```
```
Then DNSSEC is not disabled properly. If you see errors about network connections
This indicates that DNSSEC is not disabled properly.
then verify that there are no firewall or routing problems between the servers
running Bind and Consul.
If you see errors about network connections, verify that there are no firewall
or routing problems between the servers running BIND and Consul.