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

2016-04-04 Thread Simon Kelley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This behaviour isn't configurable (though it perhaps should be). If
you look for the string "A for A" in src/rfc1035.c you'll find where
it's implemented, if just patching it out is good enough.


Cheers,

Simon.


On 30/03/16 18:05, Jeff Weber wrote:
> I'm using dnsmasq as a local dns cache on some servers and I've
> noticed recently (due to some buggy software) that if you dig for
> an ip address you get an A record back which is set to that ip
> address. I went through the manual and wasn't able to find an
> option which seems like it could make this configurable. Is there a
> way to turn this response into an NXDOMAIN instead of returning the
> synthesized A record?
> 
> I'm using dnsmasq verision 2.66 on a Centos 7 machine.
> 
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJXApPMAAoJEBXN2mrhkTWiLMkP/jlmgxVFLTw3m/Z64EpmS4Z2
ARJjmHwe6Hmf7obF6aKWgIKoBBg6S+IdU+LHXv6qo8EfhCUPG4VQG7CaxFY4UinO
l3bTSlGUdsXlWFJUaEdNFez6Sa5r/TeSG0qinnaYAhBiTA++EALhD13oMABu6wIc
XbvfNPoOfdgSzVggqyvptuuP7CoNpop+Nqud7cALGffV+dZG7xUjSIE+6pSpLX9x
WLclQs29ssbZfbTn44PjVYH84Wxltsnx+GEeURx3kwI6mliz2rXJJMu+U8cJEspv
IvtpNPfO0wjl4beGJ/bWzvgTiJatEvbf1kT6iU08Tc8H0LCrnaGlsiX+BWecR0iQ
tmh/s/omKgS63eOg1aSzxOkBa9nSccO69H3swL/boSvLObLS0OKWBPQvuzgi2DGQ
SLUimlh2hBQVRY7DjiVSdL4cK+vcbd71eQbCidj38gkhDbJEgra75WTsv5Xc1ZFW
ger7Y2c63YbMyEqJUPhSLqcg/zN7sZHbtH4SnZol0m0Ysv0lPXGktKYi2SYg2jem
8pWFEeIpR1HWcL0RioXhkJs9qLpe4JXE1ZHC9pRP5UaiCmyjw/kDNp5ZCEbN3/wV
5ulLo5F35jS0Ut2RlMTwWXdOoPEj8qLrr8fDClX5n/oEekSu8SKIYGT+Q836Wbbh
cZmp+ZYeLzB00Wfosc9y
=z/VO
-END PGP SIGNATURE-

___
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

2016-03-31 Thread 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

2016-03-31 Thread /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


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

2016-03-30 Thread Jeff Weber
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.

On Wed, Mar 30, 2016 at 3:15 PM, /dev/rob0  wrote:

> On Wed, Mar 30, 2016 at 01:05:32PM -0400, Jeff Weber wrote:
> > I'm using dnsmasq as a local dns cache on some servers and I've
> > noticed recently (due to some buggy software) that if you dig for
> > an ip address you get an A record back which is set to that ip
>
> The proper use of dig of an IP address (for example, 192.0.2.53) is
> "dig -x 192.0.2.53".  This changes the query to a type PTR for
> 53.2.0.192.in-addr.arpa.
>
> By default dig queries for A, and "dig 192.0.2.53" will cause a
> recursive server to ask the root servers for a "53" top-level domain.
> The fact that ICANN has not yet tried to turn all-numeric TLDs into
> money makers notwithstanding, there is no protocol reason why it
> cannot be done.
>
> > address. I went through the manual and wasn't able to find an
> > option which seems like it could make this configurable. Is there a
> > way to turn this response into an NXDOMAIN instead of returning the
> > synthesized A record?
> >
> > I'm using dnsmasq verision 2.66 on a Centos 7 machine.
> --
>   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 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

2016-03-30 Thread /dev/rob0
On Wed, Mar 30, 2016 at 01:05:32PM -0400, Jeff Weber wrote:
> I'm using dnsmasq as a local dns cache on some servers and I've 
> noticed recently (due to some buggy software) that if you dig for 
> an ip address you get an A record back which is set to that ip 

The proper use of dig of an IP address (for example, 192.0.2.53) is 
"dig -x 192.0.2.53".  This changes the query to a type PTR for
53.2.0.192.in-addr.arpa.

By default dig queries for A, and "dig 192.0.2.53" will cause a 
recursive server to ask the root servers for a "53" top-level domain.
The fact that ICANN has not yet tried to turn all-numeric TLDs into 
money makers notwithstanding, there is no protocol reason why it 
cannot be done.

> address. I went through the manual and wasn't able to find an 
> option which seems like it could make this configurable. Is there a 
> way to turn this response into an NXDOMAIN instead of returning the 
> synthesized A record?
> 
> I'm using dnsmasq verision 2.66 on a Centos 7 machine.
-- 
  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] dig for an ip address returns A record instead of NXDOMAIN

2016-03-30 Thread Jeff Weber
I'm using dnsmasq as a local dns cache on some servers and I've noticed
recently (due to some buggy software) that if you dig for an ip address you
get an A record back which is set to that ip address. I went through the
manual and wasn't able to find an option which seems like it could make
this configurable. Is there a way to turn this response into an NXDOMAIN
instead of returning the synthesized A record?

I'm using dnsmasq verision 2.66 on a Centos 7 machine.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss