[nsd-users] Getting Refused from stub-zone authoritative query record

info at mail.jeaholding.com info at mail.jeaholding.com
Sat Dec 10 19:01:44 UTC 2022


2 Unbound
  [dns1 with separate VPS||VM port 53 ]
  and
  [dns2 with separate VPS||VM port 53]

  Both dns1 & dns2 have global IPs with a local alias on the same 
interface igb0 and local IP subnet is on same as the 2 NSD.

unbound access-control: allow_snoop = I changed it from allow for 
testing neither works and access-control I added local IP. (DID not 
help)

  2 NSD
  [ns1 with separate VPS||VM port 53]
  and
  [ns2 with separate VPS||VM port 53]

  ns1 (Master) sockstat -l
  USER    COMMAND   PID  FD PROTO LOCAL ADDRESS        FOREIGN ADDRESS
  nsd      nsd        40026 5  udp4   192.168.200.200:53    *:*
  nsd      nsd        40026 6  tcp4   192.168.200.200:53    *:*
  nsd      nsd        40026 7  udp4   192.168.2.136:53      *:*
  nsd      nsd        40026 8  tcp4   192.168.2.136:53      *:*
  nsd      nsd        40026 10 tcp4   127.0.0.1:8952        *:*
  nsd      nsd        10706 10 tcp4   127.0.0.1:8952        *:*

  ns2 (Slave) sockstat -l
  USER    COMMAND   PID  FD PROTO LOCAL ADDRESS        FOREIGN ADDRESS
  nsd      nsd        33332 5  udp4   192.168.200.220:53    *:*
  nsd      nsd        33332 6  tcp4   192.168.200.220:53    *:*
  nsd      nsd        33332 7  udp4   192.168.2.147:53      *:*
  nsd      nsd        33332 8  tcp4   192.168.2.147:53      *:*
  nsd      nsd        33332 10 tcp4   127.0.0.1:8952        *:*
  nsd      nsd        24639 10 tcp4   127.0.0.1:8952        *:*


  I am using stub-zone on the unbounds (dns1 & dns2) to connect to the 
ns1 (master) and while all the zone-file (ns1/ns2) seems to be 
working/no error via nsd-checkzone I can't get a reply of the records. 
Below are the logs from unbound.log.

  Dec 07 23:29:49 unbound[495:0] debug: Incoming reply addr = ip4 
192.168.200.200 port 53 (len 16)
  Dec 07 23:29:49 unbound[495:0] debug: lookup size is 1 entries
  Dec 07 23:29:49 unbound[495:0] debug: received udp reply.
  Dec 07 23:29:49 unbound[495:0] debug: udp message[53:0] 
46F380050001000000000001036E73310A6A6541686F6C64496E6703634F4D000006000100002904D0000080000006000F00020014
  Dec 07 23:29:49 unbound[495:0] debug: outnet handle udp reply
  Dec 07 23:29:49 unbound[495:0] debug: measured roundtrip at 2 msec
  Dec 07 23:29:49 unbound[495:0] debug: svcd callbacks start
  Dec 07 23:29:49 unbound[495:0] debug: good 0x20-ID in reply qname
  Dec 07 23:29:49 unbound[495:0] debug: worker svcd callback for qstate 
0x804ae7150
  Dec 07 23:29:49 unbound[495:0] debug: mesh_run: start
  Dec 07 23:29:49 unbound[495:0] debug: iterator[module 1] operate: 
extstate:module_wait_reply event:module_event_reply
  Dec 07 23:29:49 unbound[495:0] info: iterator operate: query 
example.com. SOA IN
  Dec 07 23:29:49 unbound[495:0] debug: process_response: new external 
response event
  Dec 07 23:29:49 unbound[495:0] info: scrub for example.com. NS IN
  Dec 07 23:29:49 unbound[495:0] info: response for example.com. SOA IN
  Dec 07 23:29:49 unbound[495:0] info: reply from <example.com.> 
192.168.200.200#53
  Dec 07 23:29:49 unbound[495:0] info: incoming scrubbed packet: ;; 
->>HEADER<<- opcode: QUERY, rcode: REFUSED, id: 0
  ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
  ;; QUESTION SECTION:
  example.com.     IN      SOA

  ;; ANSWER SECTION:

  ;; AUTHORITY SECTION:

  ;; ADDITIONAL SECTION:
  ;; MSG SIZE  rcvd: 36

  Dec 07 23:29:49 unbound[495:0] debug: iter_handle processing q with 
state QUERY RESPONSE STATE
  Dec 07 23:29:49 unbound[495:0] info: query response was THROWAWAY
  Dec 07 23:29:49 unbound[495:0] debug: iter_handle processing q with 
state QUERY TARGETS STATE
  Dec 07 23:29:49 unbound[495:0] info: processQueryTargets: example.com. 
SOA IN
  Dec 07 23:29:49 unbound[495:0] debug: processQueryTargets: 
targetqueries 0, currentqueries 0 sentcount 5
  Dec 07 23:29:49 unbound[495:0] info: DelegationPoint<example.com.>: 0 
names (0 missing), 1 addrs (0 result, 0 avail) parentNS
  Dec 07 23:29:49 unbound[495:0] debug:   ip4 192.168.200.200 port 53 
(len 16)
  Dec 07 23:29:49 unbound[495:0] debug: rpz: iterator module callback: 
have_rpz=0
  Dec 07 23:29:49 unbound[495:0] debug: No more query targets, attempting 
last resort
  Dec 07 23:29:49 unbound[495:0] debug: configured stub or forward 
servers failed -- returning SERVFAIL
  Dec 07 23:29:49 unbound[495:0] debug: store error response in message 
cache
  Dec 07 23:29:49 unbound[495:0] debug: return error response SERVFAIL
  Dec 07 23:29:49 unbound[495:0] debug: mesh_run: iterator module exit 
state is module_finished
  Dec 07 23:29:49 unbound[495:0] debug: validator[module 0] operate: 
extstate:module_wait_module event:module_event_moddone
  Dec 07 23:29:49 unbound[495:0] info: validator operate: query 
example.com. SOA IN
  Dec 07 23:29:49 unbound[495:0] debug: validator: nextmodule returned
  Dec 07 23:29:49 unbound[495:0] debug: cannot validate non-answer, rcode 
SERVFAIL
  Dec 07 23:29:49 unbound[495:0] debug: mesh_run: validator module exit 
state is module_finished
  Dec 07 23:29:49 unbound[495:0] error: SERVFAIL <example.com. SOA IN>: 
all the configured stub or forward servers failed, at zone example.com. 
from 192.168.200.200 got REFUSED
  Dec 07 23:29:49 unbound[495:0] debug: comm point stop listening 27
  Dec 07 23:29:49 unbound[495:0] debug: comm point start listening 27 
(30000 msec)
  Dec 07 23:29:49 unbound[495:0] debug: startlistening 27 mode w
  Dec 07 23:29:49 unbound[495:0] debug: query took 1.336436 sec
  Dec 07 23:29:49 unbound[495:0] reply: 192.168.200.162 example.com. SOA 
IN SERVFAIL 1.336436 0 36
  Dec 07 23:29:49 unbound[495:0] info: mesh_run: end 0 recursion states 
(0 with reply, 0 detached), 0 waiting replies, 1 recursion replies sent, 
0 replies dropped, 0 states jostled out

  I am also using dnstop to get some statistics in NSD (ns1 =master), 
query seems to me like is coming into the stub-zones / ns1 (master)... 
The unbound works for zones outside of my stub-zones for example drill 
-A google.com works fine with DNSSEC via forward-addr.

Someone in the unbound user group suggested I ask in the NSD user 
mailing list and implied that it could be an issue with allow-query 
option in the NSD.conf.

After reading the sample nsd.conf pattern section a statement in it 
standout...
         # If no master and slave access control elements are provided,
         # this zone will not be served to/from other servers.

Does this mean that if I don't properly configure a pattern / 
allow-query (aka access control) in nsd.conf I won't be able to query 
zones outside of the ns1 & ns2 in my case?

Can someone provide some sample of how a properly configured pattern in 
nsd.conf server could be done in my particular case with 2 unbound 
VM/VPS and 2 NSD VM/VPS (I'll continue to play with this section in the 
meantime just want to double check with an existing/working pattern).

Any help will be greatly appreciated.


More information about the nsd-users mailing list