1

I am currently configuring the DNS on Ubuntu servers for an assignment, and am encountering issues with reverse lookups. Below are the details from the configuration files and the results of the commands I've run:

p04ldns1.pod04.lan = master server [10.4.30.4]

  • Can resolve client1.pod04.lan to 10.4.30.10
  • Can resolve p04ldns2.pd04.lan to 10.4.30.5
  • Cannot resolve 10.4.30.10 to client1.pod04.lan
  • Cannot resolve 10.4.30.5 to p04ldns2.pd04.lan

p04ldns2.pod04.lan = slave server [10.4.30.5]

  • Can resolve p04ldns1.pd04.lan to 10.4.30.4
  • Cannot resolve client1.pod04.lan to 10.4.30.10
  • Cannot resolve 10.4.30.4 to p04ldns1.pd04.lan
  • Cannot resolve 10.4.30.10 to client1.pod04.lan

client1.pod04.lan = client [10.4.30.10]

  • Can ping 10.4.30.4 & 10.4.30.5
  • Can get out to the internet using 10.4.30.4 & 10.4.30.5 as DNS servers

Forward Lookup Zone Configuration on Master (/etc/bind/named.conf.local)

// Forward Lookup Zone zone "pod04.lan" { type master; // Confirmed as master file "/etc/bind/db.pod04.lan"; // Correct file path }; // Reverse Lookup Zone zone "30.4.10.in-addr.arpa" { type master; // Confirmed as master file "/etc/bind/30.4.10.in-addr.arpa"; // Correct file path }; 

Zone File for pod04.lan on Master (/etc/bind/db.pod04.lan)

$TTL 604800 $ORIGIN pod04.lan. @ IN SOA p04ldns1.pod04.lan. admin.pod04.lan. ( 2023100805 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS p04ldns1.pod04.lan. @ IN NS p04ldns2.pod04.lan. p04ldns1 IN A 10.4.30.4 p04ldns2 IN A 10.4.30.5 client1 IN A 10.4.30.10 

Zone File for Reverse Lookup on Master (/etc/bind/30.4.10.in-addr.arpa)

$TTL 604800 $ORIGIN 30.4.10.in-addr.arpa. @ IN SOA p04ldns1.pod04.lan. admin.pod04.lan. ( 2023100805 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS p04ldns1.pod04.lan. @ IN NS p04ldns2.pod04.lan. 10 IN PTR client1.pod04.lan. 

Slave zone file The slave cannot resolve client1.pod04.lan to 10.4.30.10

// FORWARD LOOKUP ZONE zone "pod04.lan" { type slave; file "/var/cache/bind/db.pod04.lan"; masters { 10.4.30.4; }; # P04LDNS1's IP Address }; // REVERSE LOOKUP ZONE zone "30.4.10.in-addr.arpa" { type slave; file "/var/cache/bind/30.4.10.in-addr.arpa"; masters { 10.4.30.4; }; # P04LDNS1's IP Address }; 

I have set the permissions for the reverse zone file as follows:

sudo chown bind:bind /etc/bind/30.4.10.in-addr.arpa sudo chmod 644 /etc/bind/30.4.10.in-addr.arpa 

Testing Commands and Results

Forward Lookup:

dig @10.4.30.4 client1.pod04.lan 

Result: Successfully resolves to 10.4.30.10.

Reverse Lookup:

dig -x 10.4.30.10 

Result: NXDOMAIN, indicating the reverse lookup is not resolving.

dig -x 10.4.30.10 @10.4.30.4 

Result: Also returns NXDOMAIN.

sudo ufw status Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 53 ALLOW Anywhere 22/tcp (v6) ALLOW Anywhere (v6) 53 (v6) ALLOW Anywhere (v6) 

Have tried sudo systemctl restart bind9 many times on master and slave dns servers

dig @10.4.30.4 pod04.lan AXFR on SLAVE

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @10.4.30.4 pod04.lan AXFR ; (1 server found) ;; global options: +cmd pod04.lan. 604800 IN SOA p04ldns1.pod04.lan. admin.pod04.lan. 2023100805 604800 86400 2419200 604800 pod04.lan. 604800 IN NS p04ldns1.pod04.lan. pod04.lan. 604800 IN NS p04ldns2.pod04.lan. client1.pod04.lan. 604800 IN A 10.4.30.10 p04ldns1.pod04.lan. 604800 IN A 10.4.30.4 p04ldns2.pod04.lan. 604800 IN A 10.4.30.5 pod04.lan. 604800 IN SOA p04ldns1.pod04.lan. admin.pod04.lan. 2023100805 60480 
3
  • 1
    First thing is to look at the error logs (syslog or systemd, depending on how you've got it set up) to see where it's objecting because you missed a semicolon Commented Oct 12, 2024 at 17:31
  • Can I ask how you know it's a semicolon issue? Commented Oct 12, 2024 at 18:16
  • 1
    I don't. The important part is to check for errors to identify why it's not serving your rDNS. In my experience it's usually something small that causes the zone to get skipped - probably not a semicolon in this instance because the configuration must be syntactically accurate Commented Oct 12, 2024 at 23:58

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.