Announcements
This site is in read only until July 22 as we migrate to a new platform; refer to this community post for more details.
Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Cloud DNS server only resolves on loopback and not on primary internal ip address

Hi,

Having some issues getting my GCP DNS server vm up and running (debian).

Local queries work but it uses the loopback address of 127.0.0.53 so when I query it from another vm in same subnet I get a "communications error to 10.128.0.2#53: connection refused" error message.

I found that in the /etc/resolv.conf file it only has this loopback address and not its internal which is 10.128.0.2 and have tried adding it there but linux erases it after a restart.

How do I get my vm to resolve on its primary internal address?

Thanks,

AA

0 5 303
5 REPLIES 5

Anyone?

Hi @andres_fastweb ,

Welcome to Google Cloud Community.

The DNS service is intentionally bound only to the local loopback interface (127.0.0.53). This means it will only process queries originating from the VM itself and will not accept connections from any external network interface, which is why your other VM gets refused. You need to configure your DNS server software to listen on its internal network interface (10.128.0.2). for the most common ones on Debian (BIND9, dnsmasq).

For BIND9:

  1. Locate the named.conf file: This file is usually located in /etc/bind9/named.conf.
  2. Edit the named.conf file: Open the file with a text editor (e.g., sudo nano /etc/bind9/named.conf).
  3. Find the listen-on directive: Search for the listen-on directive within the options section of the file. It probably looks like this: listen-on { 127.0.0.1; };
  4. Change it to listen on your internal IP and localhost:  listen-on { 10.128.0.2; 127.0.0.1; };
  5. Restart BIND9. sudo systemctl restart bind9

For dnsmasq:

  1.  Edit the configuration file: sudo nano/etc/dnsmasq.conf
  2. Find the listen-address and add you internal IP and localhost: listen-address=10.128.0.2, 127.0.0.1
  3. Restart dnsmasq:  sudo systemctl restart dnsmasq

If your VM is listening, but the network itself is blocking the connection. You must configure the Google Cloud firewall to create an exception, allowing other VMs in your subnet to access your DNS server.

  1. Go to the GCP Console: Navigate to VPC network > Firewall.
  2. Click Create Firewall Rule.
  3. Fill in the details:
    1. Name: allow-internal-dns.
    2. Network: Select the VPC network your VMs are in.
    3. Direction of traffic: Ingress (incoming).
    4. Action on match: Allow.
    5. Targets: The most flexible option is Specified target tags.
      1. In the Target tags box, enter a new tag, for example, dns-server.
    6. Source filter: IPv4 ranges.
      1. In the Source IPv4 ranges box, enter the CIDR block for your subnet. This ensures only VMs from your subnet can query the server.
    7. Protocols and ports:
      1. Select Specified protocols and ports.
      2. Check the box for UDP and enter 53 in the port box.
      3. Click Add another protocol, check the box for TCP, and enter 53. (DNS uses UDP for most queries and TCP for larger queries and zone transfers).
  4. Click Create.
  5. Tag your VM: Go to your VM Instances list, click on your DNS server VM, click Edit, and in the Network tags section, add the dns-server tag you just created. Click Save.

 

Was this helpful? If so, please accept this answer as “Solution”. If you need additional assistance, reply here within 2 business days and I’ll be happy to help.

Hi Kensan,

Thank you for your detailed explanation. This is turning out to be more challenging than I expected.

The firewall is not an issue since I am testing locally by changing "server 10.128.0.5" in NSLOOKUP but I anyways created the ingress rule for future use.

I first looked at the named.conf file which displayed the following:
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

So I checked named.conf.options and found the following file:
options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

// forwarders {
// 0.0.0.0;
// };

//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;

listen-on-v6 { any; };
};

I followed your instructions exactly and modified /etc/bind/named.conf.options file by adding "listen-on { 10.128.0.2; 127.0.0.1; };" but it still only resolves on the 127.0.0.53, which is btw the default ip it uses when the OS starts (where is it getting it from?).

BTW I am using NSLOOKUP to test if it resolves or not by setting "server 10.128.0.2" but still only resolves on 127.0.0.53. I did restart the service and checked its status to make sure it was running. I Also tried "dig andy.test.com @10.128.0.2" but doesn't resolve either.

I then replaced "listen-on { 10.128.0.2; 127.0.0.1; };" with "listen-on { any };" but still got the same result.

Could there be another configuration file limiting resolution only to 127.0.0.53?

Thanks again for you help,
Andres

Hi Kensan,

As an option, I installed dnsmasque and it resolves on the local ip perfectly.

However, it is only using the zones configured in the VM, while i would like to use the zones defined under Cloud DNS in ghte GCP.

How can I link Cloud DNS to my new dns server 10.128.06?

This might be a better option, what do you think?

Cheers,

Hi, any comments?