Re: [Dnsmasq-discuss] dig for an ip address returns A record instead of NXDOMAIN

[Albert ARIBAUD]

Bonjour,

Le Thu, 31 Mar 2016 08:31:08 -0500
/dev/rob0  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  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
> .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

Re: [Dnsmasq-discuss] dig for an ip address returns A record instead of NXDOMAIN

[/dev/rob0]

On Thu, Mar 31, 2016 at 10:10:37AM +0200, Albert ARIBAUD wrote:
> Le Wed, 30 Mar 2016 16:59:07 -0400
> Jeff Weber  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".

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
.in-addr.arpa.

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.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Disable caching for some hostname

[Fabio Venturi]

Hello to anyone,
I've setup dnsmasq on several machine, mostly to avoid the limitation of 3
NS in resolv.conf ,
as a bonus now I have a nice caching for name resolution (no DHCP needed).
The problem arise with a single hostname (a CNAME really) that is updated
automatically
under certain circumstances.

Is there a way to disable caching only for some names?

I've found a workaround, but i don't know if it's a bug:
if I put in /etc/hosts all the real hostname to which the CNAME could refer
to (but NOT the CNAME itself),
the CNAME is never cached and all requests for that CNAME are always sent
to the upstream DNS.

For example, in /etc/hosts:
srv1.mynet.lan  1.1.1.1
srv2.mynet.lan  2.2.2.2
srv3.mynet.lan  3.3.3.3

(logging the queries sent to dnsmasq, i can see the following request is
always forwarded)
# host service.mynet.lan
service.mynet.lan is an alias for srv2.mynet.lan.
srv2.mynet.lan has address 2.2.2.2

I hope i've explained clearly the problem,
thank you in advance for any hint.

My kindest regards,
Fabio
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss