Bonjour,
Le Thu, 31 Mar 2016 08:31:08 -0500
Post by /dev/rob0Post by Albert ARIBAUDLe Wed, 30 Mar 2016 16:59:07 -0400
Post by Jeff WeberThe 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.
Post by /dev/rob0So 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.
Post by Albert ARIBAUDstatic leases plus a static list of local hosts (so that name
resolution works even when host is down). Running dig from the
$ dig jdoe
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25422
...
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
...
Post by /dev/rob0dig -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.
Post by Albert ARIBAUDIts local upstream is an unbound server on the same machine and
$ 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.