Bug 12464 - NXDOMAIN not returned from forwarded query
NXDOMAIN not returned from forwarded query
Status: ASSIGNED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DNS server
4.5.1
All All
: P5 normal
: ---
Assigned To: Kai Blin
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-12-07 20:10 UTC by Brendan Fidgeon
Modified: 2016-12-14 17:08 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brendan Fidgeon 2016-12-07 20:10:26 UTC
When the samba internal DNS server forwards a query to an external DNS server the internal server does not return NXDOMAIN when it should. It returns "No answer" 


Using the internal DNS with forwarder:

nslookup beef.burger
Server:         10.0.0.196
Address:        10.0.0.196#53

Non-authoritative answer:
*** Can't find beef.burger: No answer

Using the external DNS server directly:

nslookup
> server 8.8.4.4
Default server: 8.8.4.4
Address: 8.8.4.4#53
> beef.burger
Server:         8.8.4.4
Address:        8.8.4.4#53

** server can't find beef.burger: NXDOMAIN

smb.conf reporduced below.

[global]
        netbios name = REALM
        realm = REALM.COM
        workgroup = REALM
        dns forwarder = 8.8.4.4
        server role = active directory domain controller

[netlogon]
        path = /usr/local/samba/var/locks/sysvol/relam.com/scripts
        read only = No

[sysvol]
        path = /usr/local/samba/var/locks/sysvol
        read only = No
Comment 1 Jeremy Allison 2016-12-13 21:39:40 UTC
Absolutely correct. Looks like we drop on the floor any forwarder reply that doesn't contain reply records. Let me look into the code here..
Comment 2 Kai Blin 2016-12-14 10:50:48 UTC
Hm, on a first glance over the code, we should be setting state->dns_err for forwarded calls the same was as we set errors for internal lookups, where we certainly handle NXDOMAIN correctly.

That said, I don't think the current DNS tests test the forwarder code path.
Comment 3 Jeremy Allison 2016-12-14 16:47:46 UTC
Yes, that's how to return the error. However I'm looking at how to return that
up the stack correctly but still return the authority and additional resource records, as bind seems to do. If we just set a werr on the tevent_req then it's treated as a call fail and won't return.

Should have a patch to look at sometime soon(ish). Then I'll work on adding a test for this.