Description of problem: When I query my internal domain name using dig no addresses return using nslookup they do Version-Release number of selected component (if applicable): DiG 9.11.2-P1-RedHat-9.11.2-1.P1.fc27 How reproducible: Only if you have a Windows 2008r2 server And it needs to be in a domain and have dns service installed and be able to resolve the domain name to ip addresses of the domain controllers (typical windows 2008r2 as a dc) Steps to Reproduce: 1.have a windows 2008r2 with dns server for an active directory domain 2.query the active directory domain with dig ie: dig my_ad_domain Actual results: no returned addresses Expected results: ip addresses of all domain controllers Additional info: I have a windows 2012r2 dc and it does return ip addresses with dig I found this behavior odd. also nslookup returns ip addresses against any of my domain controllers. another possible related issue is ldapsearch with "-h my_ad_domain" fails seemingly because it doesn't get ip resolution. Since dig is by isc.org does it belong to bind? I may have selected the wrong category.
Note dig only uses DNS to query names of machines. No other mechanisms via nss would be used for resolving the domain name, dig is pure DNS tool. This might be configuration issue of your network. Dig uses by default servers in /etc/resolv.conf. There is very little I can guess about the network from description provided. In /etc/resolv.conf, there should be lines similar to: nameserver 1.2.3.4 $ dig @1.2.3.4 -t NS my_ad_domain would return name of servers handling that domain. The query is sent to specified IP address of DNS server. If that server does not know names of your AD servers and/or their IP addresses, it cannot work. This is not issue of dig, but your recursive server configuration. Because you did not specify what server it is or how it is configured, I am not able to tell anything more. Are addresses in resolv.conf (offered by DHCP I suppose) adresses of AD server or is there any other server? How is that configured? If getent hosts <hostname> gives different results than dig +short <hostname>, then there is propably another subsystem for names, that does not use DNS but another parts. Maybe names provided by Samba?
This seems to be some bad requests sent via dig. I'm going to attach the wireshark capture of the dns queries. > cat /etc/resolv.conf # Generated by NetworkManager search mind.unm.edu lobos.lrri.org nameserver 10.0.100.79 nameserver 10.0.100.78 #dig against w2k8r2 > dig mind.unm.edu. ; <<>> DiG 9.11.2-P1-RedHat-9.11.2-1.P1.fc27 <<>> mind.unm.edu. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40474 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 63645f987b470f8b (echoed) ;; QUESTION SECTION: ;mind.unm.edu. IN A ;; Query time: 0 msec ;; SERVER: 10.0.100.79#53(10.0.100.79) ;; WHEN: Thu Feb 22 09:59:16 MST 2018 ;; MSG SIZE rcvd: 53 #dig against w2k12r2 > dig mind.unm.edu. @10.0.100.80 ; <<>> DiG 9.11.2-P1-RedHat-9.11.2-1.P1.fc27 <<>> mind.unm.edu. @10.0.100.80 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19461 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ; COOKIE: 7c200a42b28d2413 (echoed) ;; QUESTION SECTION: ;mind.unm.edu. IN A ;; ANSWER SECTION: mind.unm.edu. 600 IN A 10.0.100.78 mind.unm.edu. 600 IN A 10.0.100.79 mind.unm.edu. 600 IN A 10.0.100.80 ;; Query time: 1 msec ;; SERVER: 10.0.100.80#53(10.0.100.80) ;; WHEN: Thu Feb 22 09:59:39 MST 2018 ;; MSG SIZE rcvd: 101 #nslookup against w2k8r2 > nslookup mind.unm.edu. Server: 10.0.100.79 Address: 10.0.100.79#53 Name: mind.unm.edu Address: 10.0.100.78 Name: mind.unm.edu Address: 10.0.100.79 Name: mind.unm.edu Address: 10.0.100.80 #nslookup against w2k12r2 > nslookup mind.unm.edu. 10.0.100.80 Server: 10.0.100.80 Address: 10.0.100.80#53 Name: mind.unm.edu Address: 10.0.100.79 Name: mind.unm.edu Address: 10.0.100.80 Name: mind.unm.edu Address: 10.0.100.78 > getent hosts mind.unm.edu 10.0.100.80 mind.unm.edu 10.0.100.78 mind.unm.edu 10.0.100.79 mind.unm.edu > dig +short mind.unm.edu #no result Q:Are addresses in resolv.conf (offered by DHCP I suppose) adresses of AD server or is there any other server? How is that configured? A:the two addresses listed are 2 windows 2008r2 servers they are both domain controllers I posted my resolv.conf above. 10.0.100.80 is my windows 2012r2 domain controller.
Created attachment 1399489 [details] wireshark packets related to dig query against w2k8 dc wireshark packets related to dig query against w2k8 dc you can see that the server didn't like the request.
Created attachment 1399490 [details] wireshark capture of nslookup against w2k8 dc You can see a proper answer to nslookup's request.
Created attachment 1399491 [details] wireshark capture of dig againts w2k12 dc You can see that windows 2012 is more capable than windows 2008 and understands and responds to dig's query.
I think there is something wrong with your configuration. 10.0.100.79 has not enabled recursion, but for servers in resolv.conf that is required. You may try to play with dig options. I would try +nocookie +noedns for a start.
How do you figure that 10.0.100.79 has not enabled recursion? I have no issues with any other machines on my domain except fedora 27 machines I have started adding.(Getting sick of Ubuntu bugs) > dig +nocookie +noedns mind.unm.edu ; <<>> DiG 9.11.2-P1-RedHat-9.11.2-1.P1.fc27 <<>> +nocookie +noedns mind.unm.edu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23922 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mind.unm.edu. IN A ;; ANSWER SECTION: mind.unm.edu. 600 IN A 10.0.100.79 mind.unm.edu. 600 IN A 10.0.100.80 mind.unm.edu. 600 IN A 10.0.100.78 ;; Query time: 0 msec ;; SERVER: 10.0.100.79#53(10.0.100.79) ;; WHEN: Thu Feb 22 10:28:56 MST 2018 ;; MSG SIZE rcvd: 78 That worked but, I am not understanding why? +nocookie alone works too. I'm not seeing nocookie in the man page. What is that doing?
Hmm, I found cookie and edns. It looks like my 2k8 dc's does not understand the cookie and does not know how to respond. Is that what is going on? I'm going to guess that edns wasn't introduced into 2k8 but was in 2k12 So this seems a newer feature and not supported by older dns servers. Is there a dhcp option I can send that would tell fedora not to use edns? Otherwise older servers will always fail. So, it is not really broken as I can tell dig to use an older protocol via +noedns flag? The +noedns would fix dig but what about other programs like ldapsearch which I'm seeing similar behavior?
See man resolv.conf for options of resolv.conf. By default edns is not sent by normal libresolv, that is part of libc library. You would have to use: options edns0 To enable sending edns. Usual programs use gethostbyname() or similar calls provided by libc/libresolv. That databases use nss switch. Test it by calling $ getent hosts mind.unm.edu. Disabled recursion is detected by dig output: ; <<>> DiG 9.11.2-P1-RedHat-9.11.2-1.P1.fc27 <<>> mind.unm.edu. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40474 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 *** ;; WARNING: recursion requested but not available *** ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 63645f987b470f8b (echoed) ;; QUESTION SECTION: ;mind.unm.edu. IN A ;; Query time: 0 msec ;; SERVER: 10.0.100.79#53(10.0.100.79) ;; WHEN: Thu Feb 22 09:59:16 MST 2018 ;; MSG SIZE rcvd: 53 Check that flags field is also different. On BIND that would mean you have recursion denied or disabled. I am not familiar with behaviour of Win2k8 server implementation however. But that might be the reason why other hosts do not resolve as well. Unfortunately dig can support only user ~/.digrc to change default parameters sent. You can create system wide alias alias dig="dig +noedns" in /etc/profile. Have you tried if +noedns is sufficient for it to work?
I saw that yesterday while looking at the resolv.conf man page looking for an option to disable it. Seems the default is changed for edns0 and there is no way to change back. I showed you my resolv.conf It has a search and 2 nameserver lines in it and that is all. I displayed the output of "getent hosts mind.unm.edu." in a previous reply above. It lists the dcs. I see now you are trying to reach my server. You will not be able to do that as it is an inside only server and the domain is only accessible internally. I don't even have access to the dns for mind.unm.edu this domain was setup incorrectly by modern day standards and was setup before I started. If I was starting a new one today I would use ad.mrn.org. Since my company controls the mrn.org domain. But I still would only have it queryable from only the inside. It is recursive from the inside.(from what I recall with experiments with bind I wouldn't be able to lookup anything from any server without it being recursive and that is just not the case) I'll look for more information about libresolv and nss switch maybe there are configs for them that are turning on edns. However a freshly fedora install is acting the same and I haven't touched its configs. It is also having the same resolve issues seemingly having edns enabled by default. Maybe I can install an older version of bind someplace to test against. One that does not support edns. Maybe a very old version of slackware like when I first started using linux running on a vm that I can leave the dns port open on my home network. All other linux distros running on my network do not exhibit the problem only fedora 27. I have ubuntu 14.04 and 16.04 and centos 6.7 none have this issue. I think since most dns servers now have edns support you wouldn't notice it unless like me you have some older servers. I am looking at upgrading however I have issues of DNAME resolutions that I am holding back. https://stackoverflow.com/questions/48938213/how-to-redirect-an-a-record-of-an-external-domain-to-a-dhcp-a-record Seems the one I thought might be hard is looking easier as I am able to get a zone transfer from my external dns provider. I still don't like my options if you have better options I'd love to here them. :-)
Oh and ldapsearch is unrelated some different issue.
It seems to only be dig that is using edns by default
According to ubuntu packages [1] Ubuntu still uses quite old bind by default. Since 9.11 cookies are enabled by default. EDNS is quite mature today. If your server cannot ignore it and refuses to respond with the data, you should fix your DNS implementation. That is not anything so new that it should fail completely. It might be different with +nocookie, as that is first release. Because it will be the only release with long term support, I would recommend to make your servers work with it. I found something [2] that indicates there should be support for EDNS. I am not able to support that server however. CentOS 6 have got much lower version that do not yet use cookies. Named server supports disabling ends for selected servers. Place something similar to named.conf: server 10.0.100.79 { edns no; send-cookie no; }; [1] https://packages.ubuntu.com/search?keywords=bind9 [2] https://morgansimonsen.com/2010/04/20/windows-and-extension-mechanisms-for-dns-edns/
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.