Re: [Dnsmasq-discuss] SOA and NS lookup forwarding
On 21/08/12 22:46, Michael Firth wrote: Hi, I seem to have a problem with the way dnsmasq handles requests for SOA and NS records for domains I've defined with "server" lines. I'm based in a satellite office of an international company, and I'm using dnsmasq to split the DNS requests from our computers between local Internet DNS servers for general Internet requests, and the company Active Directory DNS servers for internal lookups. The two main reasons for doing this are for resiliency if our connectivity to the rest of the company fails, and speed because an in-country Internet lookup seems to be significantly quicker than the international lookup via the AD servers. However, if I use "nslookup" to query NS and SOA records for things handled by the AD servers, which are filtered using "server=" lines in the config, then the results don't match what is returned if I point "nslookup" directly at an AD server. Things usually seem to be OK for the "forward" domains, but always just give negative results for the "reverse" domains. This wouldn't be an issue for most applications, but PowerBroker Identity Services (formerly Likewise) has a DNS update tool that (in the standard build) relies entirely on being able to get a valid SOA record for the AD domains, and this breaks with the current dnsmasq behaviour. Some Google searching turned up this post http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2009q4/003405.html from 2009, but nothing more recent. I'm running dnsmasq V2.57, in case the behaviour has changed recently. Thanks in advance for any advice / assistance. Michael Firth Do you have --filterwin2k set? That would cause problems with SOA records. It would be useful to have some examples of exactly what the queries are that fail. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] MX forwarding
On 08/29/2012 02:58 PM, Gene Czarcinski wrote: I am going to take a deeper look at the debian bug report and try to see just what "bounds" is trying to do. OK, I ran some additional tests for "host -t DS com" and used wireshark to monitor the interface directly to my ISP on the Internet. Yup, it sure is valid and returns a real answer. I think I will be satisfied with just A, , and MX getting F_NXDOMAIN if "domain-needed" is specified. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] MX forwarding
On 08/29/2012 10:47 AM, Simon Kelley wrote: On 25/08/12 21:23, Gene Czarcinski wrote: On 08/25/2012 03:07 PM, Gene Czarcinski wrote: On 08/24/2012 03:26 PM, Gene Czarcinski wrote: On 08/23/2012 10:26 AM, Gene Czarcinski wrote: For a query from test2 of "host xxx", the response were: query[A]: config xxx.tst is NXDOMAIN-IPv6 query[A]: config xxx is NODATA-IPv4 query[]: config xxx is NODATA-IPv6 query[MX]: forwarded xxx to 192.168.122.1 << In the interest in moving this along, I took a look at the code. Unfortunately, I not quite sure where an actual fix should be done. I did a little "test" and added two lines to extract_request() in rfc1035.c .. I duplicated the T_ANY test and changed ANY to MX. The result was what I had hoped ... from the syslog: query[MX]: config xxx is NODATA-IPv4 However, as I said in a previous message, I believe that no plain-names should be forwarded is "--domain-needed" is specified ... regardless of what "--local=" is. OK, here is a little patch which seems to make thing work the way I believe they should ... that does not make it right or the correct thing to do. Gene --- --- dnsmasq-2.59/src/forward.c2011-10-07 10:09:30.0 -0400 +++ dnsmasq-2.59/src/forward-new.c2012-08-25 16:08:40.932797667 -0400 @@ -207,7 +207,8 @@ } } - if (flags == 0 && !(qtype & F_QUERY) && +// if (flags == 0 && !(qtype & F_QUERY) && + if (flags == 0 && option_bool(OPT_NODOTS_LOCAL) && !strchr(qdomain, '.') && namelen != 0) /* don't forward A or queries for simple names, except the empty name */ flags = F_NOERR; Simon here: I wrote this code originally. and I'm just catching on the is thread, having been out of contact for a couple of weeks. Thanks to magic of git, I found where that code got added: it turns out that it was in 2.58, and there's even a CHANGELOG entry: Tweak the behaviour of --domain-needed, to avoid problems with recursive nameservers downstream of dnsmasq. The new behaviour only stops A and queries, and returns NODATA rather than NXDOMAIN replies. Having trawled the list and my personal email archive didn't find any more. Then I remembered that it was a Debian bug report. Voila: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630637 Executive summary. The existing behaviour has a good reason for existing, It might be possible to make MX records behave like A and records, but doing it for all record types has consequences. Cheers, Simon. OK, it would scratch my itch if when domain-needed is specified that the response to plain-name A, , and MX queries would be NXDOMAIN [which sets the flags to be "No such name". However, I am not that sure just what query types for plain-names [no domain specified] should be forwarded. If a name is specified which includes a domain specification then, by all means, it should be forwarded unless "we" manage that domain. I have a bunch of qemu-kvm virtual guests defined ... three pairs to be specific. For each pair, one is a guest on a private virtual network and the other has two NICs: one connected to an Internet connection and the other to the private virtual network. This second system provides DNS and dhcp services. Pair1: named and dhcpd provide the services. Pair2: dnsmasq provides the services and local=// is specified. Pair3: dnsmasq provides the services and both domain=tst and local=/tst/ are specified. I use wireshark on the "gateway server" to monitor all interfaces. From the first of each pair (the user system), I issue commands such as "host pluto" [which exists], "host badhost" and "host badhost." On the named/dhcpd pair, there is a lot of "chatter" from named but the responses are respectively , "Host: host badhost not found 3(NXDOMAIN)", and "Host: host badhost not found 3(NXDOMAIN)". During my testing, I believe I may have a better suggested solution than what I submitted [although I still believe I am correct] -- the only change would be leave the if statement as is but instead of "flags = F_NOERR" change it to be "flags = F_'NXDOMAIN" This causes the host command to stop querying for this name whereas F_NOERR responds will a "null" answer and it continues with the and MX queries. I am going to take a deeper look at the debian bug report and try to see just what "bounds" is trying to do. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] MX forwarding
On 25/08/12 21:23, Gene Czarcinski wrote: > On 08/25/2012 03:07 PM, Gene Czarcinski wrote: >> On 08/24/2012 03:26 PM, Gene Czarcinski wrote: >>> On 08/23/2012 10:26 AM, Gene Czarcinski wrote: For a query from test2 of "host xxx", the response were: query[A]: config xxx.tst is NXDOMAIN-IPv6 query[A]: config xxx is NODATA-IPv4 query[]: config xxx is NODATA-IPv6 query[MX]: forwarded xxx to 192.168.122.1 << >> In the interest in moving this along, I took a look at the code. >> Unfortunately, I not quite sure where an actual fix should be done. I >> did a little "test" and added two lines to extract_request() in >> rfc1035.c .. I duplicated the T_ANY test and changed ANY to MX. >> >> The result was what I had hoped ... from the syslog: >> query[MX]: config xxx is NODATA-IPv4 >> >> However, as I said in a previous message, I believe that no >> plain-names should be forwarded is "--domain-needed" is specified ... >> regardless of what "--local=" is. >> > > OK, here is a little patch which seems to make thing work the way I > believe they should ... that does not make it right or the correct thing > to do. > > Gene > > --- > > --- dnsmasq-2.59/src/forward.c2011-10-07 10:09:30.0 -0400 > +++ dnsmasq-2.59/src/forward-new.c2012-08-25 16:08:40.932797667 -0400 > @@ -207,7 +207,8 @@ >} >} > > - if (flags == 0 && !(qtype & F_QUERY) && > +// if (flags == 0 && !(qtype & F_QUERY) && > + if (flags == 0 && >option_bool(OPT_NODOTS_LOCAL) && !strchr(qdomain, '.') && namelen > != 0) > /* don't forward A or queries for simple names, except the > empty name */ > flags = F_NOERR; > > Simon here: I wrote this code originally. and I'm just catching on the is thread, having been out of contact for a couple of weeks. Thanks to magic of git, I found where that code got added: it turns out that it was in 2.58, and there's even a CHANGELOG entry: Tweak the behaviour of --domain-needed, to avoid problems with recursive nameservers downstream of dnsmasq. The new behaviour only stops A and queries, and returns NODATA rather than NXDOMAIN replies. Having trawled the list and my personal email archive didn't find any more. Then I remembered that it was a Debian bug report. Voila: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630637 Executive summary. The existing behaviour has a good reason for existing, It might be possible to make MX records behave like A and records, but doing it for all record types has consequences. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
