BIND DNS lookup shows a wrong IP for the domain name

Question

I have a BIND DNS server in a LAN with

hostname --short : server
hostname --domain : unisof.com
hostname --fqdn : server.unisof.com
hostname --ip-address : 192.168.1.100

/etc/bind/named.conf.interna

view "interna" {

    match-clients {
        localhost;
        192.168.1.0/24;
    };

    zone "unisof.com" {
        type master;
        file "/etc/bind/unisof.lan";
        allow-update { none; };
    };

    zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/1.168.192.db";
        allow-update { none; };
    };
    include "/etc/bind/named.conf.default-zones";
};

My forward zone

$TTL 86400
@    IN    SOA    server.unisof.com. root.unisof.com. (
                   0            ;Serial
                   3600         ;Refresh
                   1800         ;Retry
                   604800       ;Expire
                   86400        ;Minimum TTL
)
    IN    NS     server.unisof.com.
    IN    A      192.168.1.100
server  IN  A   192.168.1.100

The zone file is OK

$ named-checkzone unisof.com unisof.lan
  zone unisof.com/IN: loaded serial 0
  OK

Running dig: dig server.unisof.com

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> server.unisof.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60993
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;server.unisof.com.     IN  A

;; ANSWER SECTION:
server.unisof.com.  0   IN  A   192.168.1.100

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 22 04:16:39 CST 2019
;; MSG SIZE  rcvd: 62

Running dig: dig -x 192.168.1.100

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44936
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;100.1.168.192.in-addr.arpa.    IN  PTR

;; ANSWER SECTION:
100.1.168.192.in-addr.arpa. 0   IN  PTR server.unisof.com.
100.1.168.192.in-addr.arpa. 0   IN  PTR server.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 22 04:31:01 CST 2019
;; MSG SIZE  rcvd: 106

Running dig: dig unisof.com

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> unisof.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56116
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;unisof.com.            IN  A

;; ANSWER SECTION:
unisof.com.     870 IN  A   81.2.194.128

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 22 04:24:07 CST 2019
;; MSG SIZE  rcvd: 55

This IP address 81.2.194.128 is wrong and it produces postfix connection timed out:

postfix/smtp[3891]: connect to unisof.com[81.2.194.128]:25: Connection timed out

Any help will be appreciated.

When troubleshooting with dig, **always** specify which nameserver you query with `@`. Normal troubleshooting setup is first to ask the authoritiative nameservers to check they do indeed publish the result you expect and only after that you can try to ask resolvers, either internal/local ones or public ones. Doing things differently will just make the troubleshooting longer and more complicated. — Patrick Mevzek, Apr 07 '19 at 03:27

score 1 · Answer 1 · answered Mar 22 '19 at 13:01

The odd TTL of 870 seconds in the output of dig unisof.com

;; ANSWER SECTION:
unisof.com.     870 IN  A   81.2.194.128

seems to indicate that you get a cached response and not the most up to date one. (The fact that you don't seem to increment the SOA serial number (in your zone file you use 0 ;Serial) does not help in that regard either, BTW)

Depending on what your local resolver is you may need to either clear the cache before you see effects of changes you make in your DNS server or you simply need to wait until the TTL counts down to 0 and and the cached response expires.

The debug info:

;; SERVER: 127.0.0.53#53(127.0.0.53)

to me gives the suggestion that you run a Linux distribution which uses systemd-resolve and you could try if sudo systemd-resolve --flush-caches will clear the cache for you and then test again.

By the way: The fact that dig -x 192.168.1.100 returns multiple records (round-robin) is not a recommended setup.

BIND DNS lookup shows a wrong IP for the domain name

1 Answers1