Getting Refused from stub-zone authoritative query record

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


Yorgos appreciate the reply I was not sure if it was an unbound or nsd 
issue; having said that, after your comment, I read NSD pattern sample 
section and statements under the pattern section stand out.

    # The allow-query allows an access control list to be specified
         # for a zone to be queried. Without an allow-query option, any
         # IP address is allowed to send queries for the zone.
         # This could be useful for example to not leak content from a 
zone
         # which is only offered for transfer to secondaries over TLS.
         #allow-query: 192.0.2.0/24 NOKEY
my issue# If no master and slave access control elements are provided,
it seems# this zone will not be served to/from other servers.

So I think you're pointing in the right direction it seems to me most 
samples on the web/search/mailing-list may have unbound and nsd 
installed/configured on the same VM with different ports that's why 
maybe the pattern section is not needed.

Thank you.

On 2022-12-09 10:40, George (Yorgos) Thessalonikefs via Unbound-users 
wrote:
> Hi,
> 
> I don't see this as an Unbound issue; NSD just returns REFUSED to such 
> queries.
> There seems to be something off with your NSD configuration. Maybe an
> 'allow-query:' option or the zone you are requesting is not loaded in
> NSD.
> I would first try to solve that issue with just 'dig' from the same
> Unbound machine. When you manage to get an answer with dig, try then
> with Unbound.
> 
> But as I see this may only be related to NSD, asking in that mailing
> list may get you further
> (https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users).
> 
> Best regards,
> -- Yorgos
> 
> 
> On 08/12/2022 14:08, info--- via Unbound-users wrote:
>> 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.
>> 
>> access-control: allow_snoop = I changed it from allow for testing 
>> neither works and access-control I added local IP.
>> 
>> 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)... 
>> yet the reply getting refused in unbound. The unbound works for zones 
>> outside of my stub-zones for example drill -A google.com works fine 
>> with DNSSEC via forward-addr.
>> 
>> I can't get the stub-zones authoritative to work.
>> 
>> Any help will be greatly appreciated, I am using OS FreeBSD.


More information about the Unbound-users mailing list