I have two DNS resolvers in /etc/resolv.conf file. The top one is Windows DNS server, and the bottom one is my wi-fi router. Please see below. nameserver 192.168.1.126 nameserver 192.168.1.1
In Windows DNS server, the sole "Forward Lookup Zone" is biman.net
When I query for host in the zone (biman.net) the Windows DNS server works fine-- either it returns the IP or NXDOMAIN. But when I query for anything for non-existing zone it returns SERVFAIL. But the wifi router returns NXDOMAIN even when zone name is bogus.
How can I get NXDOMAIN response from Windows DNS server when zone does not exist?
Below are the queries and the responses.
root@VDIkali:~# nslookup -q=A kali2.biman.net Server: 192.168.1.126 Address: 192.168.1.126#53
Name: kali2.biman.net Address: 192.168.1.122
root@VDIkali:~# nslookup -q=A NOHOST.biman.net Server: 192.168.1.126 Address: 192.168.1.126#53
** server can't find NOHOST.biman.net: NXDOMAIN
root@VDIkali:~# nslookup -q=A kali2.NONEXTING.net ;; Got SERVFAIL reply from 192.168.1.126, trying next server Server: 192.168.1.1 Address: 192.168.1.1#53
** server can't find kali2.NONEXTING.net: NXDOMAIN
That's a secret that nobody could solve in over a decade. Why do Windows DNS servers return SERVFAIL rather than NXDOMAIN?
IMHO a severe bug. Effectively it disables the caching of an unsuccessful host lookup; makes a performance difference, especially with a thousand DNS clients that run buggy software. But the customer insisted on Windows DNS.
Perhaps somebody here has a solution by chance. Otherwise this is a question for a Windows forum...
Okay, a mitigation I can offer: have the non-Windows nameserver first in /etc/resolv. conf
Quire right, only many big enterprises use MS... for the active directory, and while at it let MS... rule the DNS also for "security" purpose with MS proxies...
This leads to many fancy bugs when there are misunderstandings between Windows standards and Unix standards...
Is this yet another case?
In our company, we had a big service outage because of secondary DNS server going down. At the first thought we were surprised why requests were even trying to go to the secondary. Then we found out it was because a lot of SERVFAIL in the primary one even in normal circumstances. I wonder how the companies handle Windows DNS servers.
I realize that if Windows DNS server is set up to forward the query to another DNS server (tested in non-windows one) one then SERVAIL does not happen
Hi,
Here you nail pin the problem of big structures, the lack of communication between the different responsibilities:
We Unix people never get clear answers from security team or network team, it is you that have to show the others the issue, and its cause before they take into account, mainly because in the case of DNS and proxies e.g they see no problems with Window servers when you are trying something on your lan that is not working as expected it becomes a nightmare having to test things that are not in your hands like the network it goes with trying a similar config on 2 other servers, if it works there, try to figure out what can be the culprit... In other words you have to suggest ( because never a good idea to blame the others for not doing their work seriously...) by showing the case that works and the one that doesnt that it may be a misconfiguration of a port in a switch as you have already changed the cabling with new and not more success... or are you filtered? etc...
I suggest you look with the Windows server team to see if they also have the same issue, and work together to try to explain at the Network team the issue
Just asking for another help, if you can. I was analysing my DNS traffic using tcpdump (not verbose mode) in a AIX client. I found that a lot of repeat of transaction IDs over matter of hours. Is it expected?
22:39:52.301965 IP 192.168.1.119.56880 > 192.168.1.126.53: 49968+ A? shavar.services.mozilla.com. (45)