Strange DNS problem

Jukka Pakkanen jukka.pakkanen at qnet.fi
Mon Jun 10 14:28:46 UTC 2019


We have a strange problem related to DNS services, maybe someone here have a clue what could be the problem.

We are running BIND 9.14.2 in several servers, ns1.qnet.fi, ns2.qnet.fi etc.  Everything else works fine, but with one small operator (actually a mediahouse), we can not get any replies to DNS queries from them.   First thought it is a routing problem somewhere, but inquiring those servers with IP works, so can not be.

An example, the client domain is raimoasikainenoy.fi.

; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi raimoasikainenoy.fi ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15578
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 55ba199a6d905273458bc2065cfe655462f150936d882603 (good)
;; QUESTION SECTION:
;raimoasikainenoy.fi.                                             IN                        NS

;; Query time: 4999 msec
;; SERVER: 62.142.220.5#53(62.142.220.5)
;; WHEN: Mon Jun 10 17:12:36 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 76


>From our own providers nameservers it works however, also tested ok from a couple other operators:

; <<>> DiG 9.14.2 <<>> @8.8.8.8 raimoasikainenoy.fi ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47848
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;raimoasikainenoy.fi.                                             IN                        NS

;; ANSWER SECTION:
raimoasikainenoy.fi.                 3599                    IN                        NS                       ns.kpk.fi.
raimoasikainenoy.fi.                 3599                    IN                        NS                       ns.datatower.fi.

;; Query time: 78 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jun 10 17:14:11 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 96


Then testing from our network again, inquiring from ns.kpk.fi or ns.datatower.fi not working, our server cannot resolve those names.  But when inquiring with IP 193.184.54.212 (ns.datatower.fi):

;; Warning: Client COOKIE mismatch

; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a0ff0c014f65b471e0b8b271ffffffffe7bab2718129c071 (bad)
;; QUESTION SECTION:
;raimoasikainenoy.fi.                                             IN                        NS

;; ANSWER SECTION:
raimoasikainenoy.fi.                 3600                    IN                        NS                       ns.datatower.fi.
raimoasikainenoy.fi.                 3600                    IN                        NS                       ns.kpk.fi.
;; ADDITIONAL SECTION:
ns.kpk.fi.                                       600                      IN                        A                          192.130.183.74
ns.datatower.fi.                         3600                    IN                        A                          193.184.54.212

;; Query time: 15 msec
;; SERVER: 193.184.54.212#53(193.184.54.212)
;; WHEN: Mon Jun 10 17:17:50 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 156


So what can it be??   To every other operator/network our inquiries work fine, have been working 25 years :)  But only to this "operator" not.  Our servers cannot resolve the name of their servers, even it can do it when inquiring their servers directly by servers IP addresses.  Their NS records in the fi-root look little suspicious, like some of the servers lacked glue records, but not sure about that.

Jukka Pakkanen
Q-Net Oy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190610/a563a624/attachment.html>


More information about the bind-users mailing list