NXDOMAIN for internal hosts after being offline

[datamorgana]

Hi all -

Environment: IPFire 2.25 (x86_64) - Core Update 147
IPFire has been setup totally from scratch to core 146, it has had only 1 update since then.

Problem: If a host in my network has been offline for an unspecific amount of time (5 min, 24 hours, whatever), after it is back on-line (has got an IP address per DHCP), its hostname cannot be found by unbound, which returns NXDOMAIN for that specific host. Restarting unbound works only until the specific host is off-line again (no network link).

So: as long as a host is online, unbound returns its name, it also answers recursive queries, like in this example, “ipfire” being the IPFire host itself:

[root@ipfire ~]# host ipfire.green.myredacteddomain.net
ipfire.green.myredacteddomain.net has address 192.168.0.1

This host-a has been offline for 24 hours and is back online again, when doing this query:

[root@ipfire ~]# host host-a.green.myredacteddomain.net
Host host-a.green.myredacteddomain.net not found: 3(NXDOMAIN)

The same for reverse queries of the same host:

[root@ipfire ~]# host 192.168.0.101
Host 101.0.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

Below is the “grep unbound /var/log/messages”:

Aug  4 18:07:57 ipfire unbound: [1833:0] info: service stopped (unbound 1.10.1).
Aug  4 18:07:57 ipfire unbound: [1833:0] info: server stats for thread 0: 10588 queries, 9697 answers from cache, 891 recursions, 1 prefetch, 0 rejected by ip ratelimiting
Aug  4 18:07:57 ipfire unbound: [1833:0] info: server stats for thread 0: requestlist max 13 avg 2.81839 exceeded 0 jostled 0
Aug  4 18:07:57 ipfire unbound: [1833:0] info: average recursion processing time 8.230782 sec
Aug  4 18:07:57 ipfire unbound: [1833:0] info: histogram of recursion processing times
Aug  4 18:07:57 ipfire unbound: [1833:0] info: [25%]=0.0556762 median[50%]=0.11022 [75%]=0.357927
Aug  4 18:07:57 ipfire unbound: [1833:0] info: lower(secs) upper(secs) recursions
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.000000    0.000001 79
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.008192    0.016384 1
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.016384    0.032768 26
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.032768    0.065536 167
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.065536    0.131072 253
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.131072    0.262144 128
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.262144    0.524288 39
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    0.524288    1.000000 72
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    1.000000    2.000000 39
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    2.000000    4.000000 9
Aug  4 18:07:57 ipfire unbound: [1833:0] info:    8.000000   16.000000 4
Aug  4 18:07:57 ipfire unbound: [1833:0] info:   16.000000   32.000000 6
Aug  4 18:07:57 ipfire unbound: [1833:0] info:   32.000000   64.000000 16
Aug  4 18:07:57 ipfire unbound: [1833:0] info:   64.000000  128.000000 31
Aug  4 18:07:57 ipfire unbound: [1833:0] info:  128.000000  256.000000 21
Aug  4 18:07:57 ipfire unbound: [1833:0] notice: Restart of unbound 1.10.1.
Aug  4 18:07:57 ipfire unbound: [1833:0] notice: init module 0: validator
Aug  4 18:07:57 ipfire unbound: [1833:0] notice: init module 1: iterator
Aug  4 18:07:57 ipfire unbound: [1833:0] info: start of service (unbound 1.10.1).
Aug  4 18:07:57 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  4 18:21:04 ipfire unbound: [1833:0] error: SERVFAIL <te.technical-service.net. A IN>: all the configured stub or forward servers failed, at zone .
Aug  4 18:21:54 ipfire unbound: [1833:0] error: SERVFAIL <te.technical-service.net. AAAA IN>: all the configured stub or forward servers failed, at zone .
Aug  4 19:08:52 ipfire unbound: [1833:0] error: SERVFAIL <te.technical-service.net. AAAA IN>: all the configured stub or forward servers failed, at zone .
Aug  4 20:18:14 ipfire unbound: [1833:0] error: SERVFAIL <support.mozilla.org. A IN>: all the configured stub or forward servers failed, at zone .
Aug  4 20:18:41 ipfire unbound: [1833:0] error: SERVFAIL <rtc.dymatrix.cloud. A IN>: all the configured stub or forward servers failed, at zone .
Aug  4 20:18:47 ipfire unbound: [1833:0] error: SERVFAIL <rtc.dymatrix.cloud. AAAA IN>: all the configured stub or forward servers failed, at zone .
Aug  4 20:24:40 ipfire unbound: [1833:0] error: SERVFAIL <support.mozilla.org. AAAA IN>: all the configured stub or forward servers failed, at zone .
Aug  4 20:25:03 ipfire unbound: [1833:0] error: SERVFAIL <support.mozilla.org. A IN>: all the configured stub or forward servers failed, at zone .
Aug  4 21:02:34 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  5 08:06:58 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  5 14:06:44 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  5 18:07:59 ipfire unbound: [1833:0] info: server stats for thread 0: 19010 queries, 14133 answers from cache, 4877 recursions, 5 prefetch, 0 rejected by ip ratelimiting
Aug  5 18:07:59 ipfire unbound: [1833:0] info: server stats for thread 0: requestlist max 22 avg 1.37054 exceeded 0 jostled 0
Aug  5 18:07:59 ipfire unbound: [1833:0] info: average recursion processing time 3.473484 sec
Aug  5 18:07:59 ipfire unbound: [1833:0] info: histogram of recursion processing times
Aug  5 18:07:59 ipfire unbound: [1833:0] info: [25%]=0.0413856 median[50%]=0.0548566 [75%]=0.085027
Aug  5 18:07:59 ipfire unbound: [1833:0] info: lower(secs) upper(secs) recursions
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.000000    0.000001 66
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.002048    0.004096 1
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.004096    0.008192 1
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.016384    0.032768 371
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.032768    0.065536 2964
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.065536    0.131072 849
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.131072    0.262144 238
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.262144    0.524288 87
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    0.524288    1.000000 65
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    1.000000    2.000000 19
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    2.000000    4.000000 11
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    4.000000    8.000000 27
Aug  5 18:07:59 ipfire unbound: [1833:0] info:    8.000000   16.000000 27
Aug  5 18:07:59 ipfire unbound: [1833:0] info:   16.000000   32.000000 29
Aug  5 18:07:59 ipfire unbound: [1833:0] info:   32.000000   64.000000 51
Aug  5 18:07:59 ipfire unbound: [1833:0] info:   64.000000  128.000000 44
Aug  5 18:07:59 ipfire unbound: [1833:0] info:  256.000000  512.000000 24
Aug  5 20:37:33 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  5 22:17:53 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  6 01:03:20 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  6 09:53:44 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Aug  6 15:08:53 ipfire unbound: [1833:0] info: generate keytag query _ta-4a5c-4f66. NULL IN

Unbound-status message:

[root@ipfire ~]# unbound-control status
version: 1.10.1
verbosity: 1
threads: 1
modules: 2 [ validator iterator ]
uptime: 252456 seconds
options: reuseport control
unbound (pid 1833) is running...

After a restart of unbound, it works until one of the queried and registeres hosts goes off- and on-line again. It remains unknown after that.

Puzzled…
datamorgana

– EDIT
I forgot to mention:

[root@ipfire ~]# grep host-a /etc/unbound/hosts.conf 
local-data: "host-a.green.myredacteddomain.net 60 IN A 192.168.0.101"
local-data: "101.0.168.192.in-addr.arpa 60 IN PTR host-a.green.myredacteddomain.net"

And I also applied the patch in /etc/init.d/unbound line 84 and changed this line

echo "local-zone: ${domainname} typetransparent"

to read

echo "local-zone: ${domainname} transparent"

[datamorgana]

After some days of monitoring this behaviour I noticed that unbound stops resolving internal addresses after I have made some changes in the GUI, e.g. adding a new host in “Network > Edit Hosts” or adding a host in “Network > DHCP Server”.

[makrie (Martin Krieger)]

Hello,

I can confirm that unbound is “unstable” causing intermittent NXDOMAIN replies to nslookup queries in local domain.

After changing echo “local-zone: ${domainname} typetransparent” to echo “local-zone: \”${domainname}\" transparent" in /etc/init.d/unbound the system seems to be working as desired (nslookup queries on IPFire- or Client-Console showed success).

Please recognize the double \" added in the line to ensure the correct syntax in /etc/unbound/hosts.conf.

Regards,

makrie

[redneckmother]

I searched the “community” for “typetransparent”, as I remembered running across it before. I haven’t examined your issue, but I found another reference:

DNS issue causing loss of sanity and hair

Ok, I have a DNS issue causing loss of sanity (and hair). I have one single entry in the Hosts configuration, and DHCP server, that does not want to work right. DNS lookup, is the specific issue. Every other entry in my DNS configuration seems to work fine. but for this single entry, nslookup from any device fails. Device is on the network/wire, can ping ip address fine. But neither forward nor reverse lookup works. This device has two network interfaces, first one is wired ethernet, secon…

Might the two issues be related?

[makrie (Martin Krieger)]

Hello RedneckMother,

yes you are right. This topic was also discussed in Local DNS problems after update to core 144 - #4 by db5589. A patch were provided and confirmed to use transparent instead of typetransparent but I found no information when this patch came to action.

My system based on IPFire 2.25 (x86_64) - Core Update 153 still had typetransparent. Maybe this is a update issue. How could I check (and fix) that?

Regards,

makrie

[jschlag (Jonatan Schlag)]

Hi,

first please add such information as always to bugzilla. A lot of Core Developers read in this community somehow irregular (although there are some very busy readers like Peter Mueller). This has nothing to do with ignorance just with a lake of time. We cannot monitor a handful of platforms for important information and so important information like the one which you posted here gets somehow lost.

Therefore please post this information in the bug report, that it gets recognized.

Second to as you have found the patch in out patchwork you can see a “state” attribute which is set to “new”. This patch never made it into production! This can happen when we overlook a patch for example. Also, the bug report is not closed, so the bug was not resolved.

Greetings Jonatan

[makrie (Martin Krieger)]

…OK, I will collect my observations and attach it to 12391 – NXDOMAIN replies by unbound when querying local hosts after Core Update 143. Regards makrie

[anon42188109]

I’m on core 152, /etc/unbound/hosts.conf has typetransparent and I get NXDOMAIN for hosts in my network. I added myself to the cc list in that bug (12391).

[root@ipfire init.d]# host  fx
fx.lan has address 10.0.0.21
Host fx.lan not found: 3(NXDOMAIN)
Host fx.lan not found: 3(NXDOMAIN)