Bonjour, Le Thu, 31 Mar 2016 08:31:08 -0500 /dev/rob0 <r...@gmx.co.uk> a écrit:
> On Thu, Mar 31, 2016 at 10:10:37AM +0200, Albert ARIBAUD wrote: > > Le Wed, 30 Mar 2016 16:59:07 -0400 > > Jeff Weber <jwe...@cofront.net> a écrit: > > > > > The behavior I'm seeing it that any host with dnsmasq in it's > > > query path when running dig returns an A record the response is > > > NOERROR and the answer section has an A record which looks like > > > > > > 192.168.100.100. 0 IN A 192.168.100.100 > > > > > > If I perform a dig against the upstream server directly I receive > > > an NXDOMAIN. > > > > > > I made the assumption that dnsmasq was creating this response > > > was coming from dnsmasq. I'll do a more detailed investigation > > > to validate that is true. > > > > I can confirm this behavior on a dnsmasq v2.62 configured with > > Sorry Jeff and Albert, I should have been more explicit. Yes, these > zero-TTL A records for "ip.add.re.ss." are indeed coming from > dnsmasq. I was only pointing out that to see them means that you're > misusing "dig". If by that you mean "calling dig without the -x option and with an argument that looks like an IP address", I agree. My point that since there is technically no domain "192.168.0.1", dnsmasq should never repond to a "dig 192.168.0.1" with a NOERROR response. > So Jeff's question was valid and his observation was correct. The > question remains, how to control this feature of dnsmasq. I went > through the man page just now and did not see anything which looked > likely to do it. > > > static leases plus a static list of local hosts (so that name > > resolution works even when host is down). Running dig from the > > server itself, thus asking dnsmasq directly, yields the following: > > > > $ dig jdoe > > ... > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25422 > > ... > > ;; ANSWER SECTION: > > jdoe. 0 IN A 192.168.0.1 > > ... > > $ dig -x 192.168.0.1 > > ... > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5779 > > ... > > 192.168.0.1. 0 IN A 192.168.0.1 > > ... > > Um, I think you had a copy/paste error/omission here, Albert. As I > mentioned, -x changes the query type to PTR and the query name to > <here.reversed.are.elements>.in-addr.arpa. Yes, I did a copy-paste mistake in that I put "dig -x 192.168.0.1" as the pasted command where the actual, executed, command was "dig 192.168.0.1". So, just tested again and triple-checked, here is what I do and see: $ dig 192.168.0.1 ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43022 ... 192.168.0.1. 0 IN A 192.168.0.1 ... > dig -x elements.are.reversed.here > > Try it, it's really not very smart. :) > > dig's BIND brother host(1) is a bit more user-friendly in this > regard, because it acts on a dotted quad as you might expect, not > requiring the "-x" to do the reversal and query for PTR. > > > Its local upstream is an unbound server on the same machine and > > on port: > > > > $ dig -p 1234 192.168.0.1 > > ... > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61710 > > ... > > Here without the -x the query is for an A record for "192.168.0.1." > in the "1" top-level domain. Indeed. So, to be clear, the issue is that when one does a "dig 192.168.0.1", dig *correctly* considers "192.168.0.1" as a potential domain name and sends an A request with that name to dnsmasq; the problem is that dnsmasq returns a NOERROR and an A record with value "192.168.0.1" (identical to the name) despite there being no FQDN "192.168.0.1" (and in fact no TLD "1"). Note that the same happens with a "dig 192.168.42.1", where absolutely no subnet exists at all on the LAN where dnsmasq runs. In fact, any IPv4 address causes the same behavior (but if there are less or more than 4 numbers separated by dots (e.G. "1.2.3" or "1.2.3.4.5"), then dsnmasq returns NXDOMAIN. Amicalement, -- Albert. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
