Re: [Dnsmasq-discuss] MX forwarding

2012-08-31 Thread Gene Czarcinski 

On 08/31/2012 09:59 AM, Simon Kelley wrote:

On 30/08/12 17:20, Gene Czarcinski wrote:

On 08/30/2012 10:31 AM, Simon Kelley wrote:

On 30/08/12 13:11, Gene Czarcinski wrote:

The patch below has been tested and returns NXDOMAIN for A and 
plain-name queries (which stops /usr/bin/host) from doing an MX query
(domain-needed is specified).  But a "host -t DS com" and "host -t DS
org" returns the expected info.

A really simple patch:
---


diff -uNr dnsmasq-2.59.orig/src/forward.c dnsmasq-2.59/src/forward.c
--- dnsmasq-2.59.orig/src/forward.c2011-10-07 10:09:30.0
-0400
+++ dnsmasq-2.59/src/forward.c2012-08-30 07:27:33.553302341 -0400
@@ -210,7 +210,7 @@
 if (flags == 0 && !(qtype & F_QUERY) &&
 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;
+flags = F_NXDOMAIN;

 if (flags == F_NXDOMAIN && check_for_local_domain(qdomain, now))
   flags = F_NOERR;
--




But that change returns NXDOMAIN, which is an reversion of one of the
changes made to fix Debian bug 630637.

I'm happy to add MX to A and  records for special-casing, but not
the above patch.


Yes, you can add MX to the extract_request() so that for A, , ANY,
and now MX will be the "flag" will be set.  However, it is important not
to return a null response ... NXDOMAIN is the proper return ... or at
least that is what I get when I enter a bad plain-name to a bind/named
server ... sure, the query gets forwarded up the chain and rattles a lot
of other servers, but that answer of an A query will stop host.  In
Addition, you will get NXDOMAIN [reply code 3 or "no such name" as
wireshark puts it] if you specifically query MX such as "host -t MX
badname."

However, from what you are saying, I am not sure how the code is suppose
to work but with the patch above applied it seems to work just fine (at
least it gave the keys for "host com.", "host org.", and "host net.").
At the same time, NXDOMAIN is returned for plain-name A, , and ANY.
Yes, you specifically specify MX such as "host -t MX badname." the the
query will be forwarded.  The main thing is to return a NXDOMAIN
response rather than a "null" response which is what you get from
"F_NOERR".  BTW, I am not certain what the purpose of the next "if"
statement is.


The problem with returning an NXDOMAIN response for (eg) com is that it
means that the .com domain doesn't exist. Something querying say an MX
record for com which gets an NXDOMAIN response is at liberty to cache
that, and assume that com doesn't exist, and that a query for
_any_query_type_ will also return NXDOMAIN. A sufficiently complete
recursive resolver will get the information that .com is NXDOMAIN, and
completely correctly deduce that google.com is also NXDOMAIN. A NODATA
reply doesn't have this property.


Thanks for the patience,  Gene

No problem. To be honest, I can't remember all the details of which this
got changed, which 1) makes it difficult to reason about it, and 2)
makes me reluctant to make further changes without understanding them.

Cheers,

Simon.

Well, I believe that I just shot myself in the foot because I just 
proved to myself that NXDOMAIN was wrong.  My reference to how things 
should work (what the responses should be) is bind (named). Doing a 
"host com." A, , MX queries each with a "null" response such as you 
get from using F_NOERR and not F_NXDOMAIN.


My only objective is to not do unintentional forwarding.  Thus, adding 
T_MX to extract_request() should duplicate the responses when 
"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

2012-08-31 Thread Simon Kelley 
On 30/08/12 17:20, Gene Czarcinski wrote:
> On 08/30/2012 10:31 AM, Simon Kelley wrote:
>> On 30/08/12 13:11, Gene Czarcinski wrote:
>>> The patch below has been tested and returns NXDOMAIN for A and 
>>> plain-name queries (which stops /usr/bin/host) from doing an MX query
>>> (domain-needed is specified).  But a "host -t DS com" and "host -t DS
>>> org" returns the expected info.
>>>
>>> A really simple patch:
>>> ---
>>>
>>>
>>> diff -uNr dnsmasq-2.59.orig/src/forward.c dnsmasq-2.59/src/forward.c
>>> --- dnsmasq-2.59.orig/src/forward.c2011-10-07 10:09:30.0
>>> -0400
>>> +++ dnsmasq-2.59/src/forward.c2012-08-30 07:27:33.553302341 -0400
>>> @@ -210,7 +210,7 @@
>>> if (flags == 0 && !(qtype & F_QUERY) &&
>>> 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;
>>> +flags = F_NXDOMAIN;
>>>
>>> if (flags == F_NXDOMAIN && check_for_local_domain(qdomain, now))
>>>   flags = F_NOERR;
>>> --
>>>
>>>
>>>
>> But that change returns NXDOMAIN, which is an reversion of one of the
>> changes made to fix Debian bug 630637.
>>
>> I'm happy to add MX to A and  records for special-casing, but not
>> the above patch.
>>
> Yes, you can add MX to the extract_request() so that for A, , ANY,
> and now MX will be the "flag" will be set.  However, it is important not
> to return a null response ... NXDOMAIN is the proper return ... or at
> least that is what I get when I enter a bad plain-name to a bind/named
> server ... sure, the query gets forwarded up the chain and rattles a lot
> of other servers, but that answer of an A query will stop host.  In
> Addition, you will get NXDOMAIN [reply code 3 or "no such name" as
> wireshark puts it] if you specifically query MX such as "host -t MX
> badname."
> 
> However, from what you are saying, I am not sure how the code is suppose
> to work but with the patch above applied it seems to work just fine (at
> least it gave the keys for "host com.", "host org.", and "host net."). 
> At the same time, NXDOMAIN is returned for plain-name A, , and ANY. 
> Yes, you specifically specify MX such as "host -t MX badname." the the
> query will be forwarded.  The main thing is to return a NXDOMAIN
> response rather than a "null" response which is what you get from
> "F_NOERR".  BTW, I am not certain what the purpose of the next "if"
> statement is.
> 

The problem with returning an NXDOMAIN response for (eg) com is that it
means that the .com domain doesn't exist. Something querying say an MX
record for com which gets an NXDOMAIN response is at liberty to cache
that, and assume that com doesn't exist, and that a query for
_any_query_type_ will also return NXDOMAIN. A sufficiently complete
recursive resolver will get the information that .com is NXDOMAIN, and
completely correctly deduce that google.com is also NXDOMAIN. A NODATA
reply doesn't have this property.

> Thanks for the patience,  Gene

No problem. To be honest, I can't remember all the details of which this
got changed, which 1) makes it difficult to reason about it, and 2)
makes me reluctant to make further changes without understanding them.

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

2012-08-30 Thread Gene Czarcinski 

On 08/30/2012 10:31 AM, Simon Kelley wrote:

On 30/08/12 13:11, Gene Czarcinski wrote:

The patch below has been tested and returns NXDOMAIN for A and 
plain-name queries (which stops /usr/bin/host) from doing an MX query
(domain-needed is specified).  But a "host -t DS com" and "host -t DS
org" returns the expected info.

A really simple patch:
---

diff -uNr dnsmasq-2.59.orig/src/forward.c dnsmasq-2.59/src/forward.c
--- dnsmasq-2.59.orig/src/forward.c2011-10-07 10:09:30.0 -0400
+++ dnsmasq-2.59/src/forward.c2012-08-30 07:27:33.553302341 -0400
@@ -210,7 +210,7 @@
if (flags == 0 && !(qtype & F_QUERY) &&
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;
+flags = F_NXDOMAIN;

if (flags == F_NXDOMAIN && check_for_local_domain(qdomain, now))
  flags = F_NOERR;
--



But that change returns NXDOMAIN, which is an reversion of one of the
changes made to fix Debian bug 630637.

I'm happy to add MX to A and  records for special-casing, but not
the above patch.

Yes, you can add MX to the extract_request() so that for A, , ANY, 
and now MX will be the "flag" will be set.  However, it is important not 
to return a null response ... NXDOMAIN is the proper return ... or at 
least that is what I get when I enter a bad plain-name to a bind/named 
server ... sure, the query gets forwarded up the chain and rattles a lot 
of other servers, but that answer of an A query will stop host.  In 
Addition, you will get NXDOMAIN [reply code 3 or "no such name" as 
wireshark puts it] if you specifically query MX such as "host -t MX 
badname."


However, from what you are saying, I am not sure how the code is suppose 
to work but with the patch above applied it seems to work just fine (at 
least it gave the keys for "host com.", "host org.", and "host net.").  
At the same time, NXDOMAIN is returned for plain-name A, , and ANY.  
Yes, you specifically specify MX such as "host -t MX badname." the the 
query will be forwarded.  The main thing is to return a NXDOMAIN 
response rather than a "null" response which is what you get from 
"F_NOERR".  BTW, I am not certain what the purpose of the next "if" 
statement is.


Thanks for the patience,  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

2012-08-30 Thread Simon Kelley 
On 30/08/12 13:11, Gene Czarcinski wrote:
> The patch below has been tested and returns NXDOMAIN for A and 
> plain-name queries (which stops /usr/bin/host) from doing an MX query
> (domain-needed is specified).  But a "host -t DS com" and "host -t DS
> org" returns the expected info.
> 
> A really simple patch:
> ---
> 
> diff -uNr dnsmasq-2.59.orig/src/forward.c dnsmasq-2.59/src/forward.c
> --- dnsmasq-2.59.orig/src/forward.c2011-10-07 10:09:30.0 -0400
> +++ dnsmasq-2.59/src/forward.c2012-08-30 07:27:33.553302341 -0400
> @@ -210,7 +210,7 @@
>if (flags == 0 && !(qtype & F_QUERY) &&
>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;
> +flags = F_NXDOMAIN;
> 
>if (flags == F_NXDOMAIN && check_for_local_domain(qdomain, now))
>  flags = F_NOERR;
> --
> 
> 

But that change returns NXDOMAIN, which is an reversion of one of the
changes made to fix Debian bug 630637.

I'm happy to add MX to A and  records for special-casing, but not
the above patch.

Simon.



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

[Dnsmasq-discuss] MX forwarding

2012-08-30 Thread Gene Czarcinski 
The patch below has been tested and returns NXDOMAIN for A and  
plain-name queries (which stops /usr/bin/host) from doing an MX query 
(domain-needed is specified).  But a "host -t DS com" and "host -t DS 
org" returns the expected info.


A really simple patch:
---
diff -uNr dnsmasq-2.59.orig/src/forward.c dnsmasq-2.59/src/forward.c
--- dnsmasq-2.59.orig/src/forward.c2011-10-07 10:09:30.0 -0400
+++ dnsmasq-2.59/src/forward.c2012-08-30 07:27:33.553302341 -0400
@@ -210,7 +210,7 @@
   if (flags == 0 && !(qtype & F_QUERY) &&
   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;
+flags = F_NXDOMAIN;

   if (flags == F_NXDOMAIN && check_for_local_domain(qdomain, now))
 flags = F_NOERR;
--

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

2012-08-29 Thread Gene Czarcinski 

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

2012-08-29 Thread Gene Czarcinski 

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

2012-08-29 Thread Simon Kelley 
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

Re: [Dnsmasq-discuss] MX forwarding

2012-08-27 Thread Gene Czarcinski 

On 08/25/2012 04:23 PM, 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. 
More refining the patch.  This is essentially the same as the previous 
patch except that I fixed up the comments.


Essentially but not really the same.  The significant difference is the 
flags is not set to "F_NXDOMAIN" rather then "F_NOERR".  As a result, 
the /usr/bin/host command is doing the right thing and gives a 
reasonable response to the user for a badhost query.


I believe that the patch changes the way dnsmasq response but I am not 
certain that this is the "right" thing to do ... even if it makes sense 
to me.


As usual, the patch is inline below as well as being attached.

Gene

---
diff -uNr dnsmasq-2.59.orig/src/forward.c dnsmasq-2.59/src/forward.c
--- dnsmasq-2.59.orig/src/forward.c2011-10-07 10:09:30.0 -0400
+++ dnsmasq-2.59/src/forward.c2012-08-27 14:11:06.581948635 -0400
@@ -207,10 +207,11 @@
   }
   }

-  if (flags == 0 && !(qtype & F_QUERY) &&
+  /* if domain-needed is specified, don't forward queries for
+simple names (not just A or ), except the empty name */
+  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;
+flags = F_NXDOMAIN;

   if (flags == F_NXDOMAIN && check_for_local_domain(qdomain, now))
 flags = F_NOERR;

diff -uNr libvirt-0.9.11.4.orig/src/network/bridge_driver.c libvirt-0.9.11.4/src/network/bridge_driver.c
--- libvirt-0.9.11.4.orig/src/network/bridge_driver.c	2012-06-15 14:23:21.0 -0400
+++ libvirt-0.9.11.4/src/network/bridge_driver.c	2012-08-22 12:16:45.263488789 -0400
@@ -490,8 +490,15 @@
  */
 virCommandAddArgList(cmd, "--strict-order", "--bind-interfaces", NULL);
 
-if (network->def->domain)
+if (network->def->domain) {
 virCommandAddArgList(cmd, "--domain", network->def->domain, NULL);
+virCommandAddArgFormat(cmd, "--local=/%s/", network->def->domain);
+virCommandAddArgList(cmd, "--domain-needed", "--filterwin2k", NULL);
+}
+else { /* need to specify local even if no domain specified */
+virCommandAddArg(cmd, "--local=//");
+virCommandAddArgList(cmd, "--domain-needed", "--filterwin2k", NULL);
+}
 
 if (pidfile)
 virCommandAddArgPair(cmd, "--pid-file", pidfile);
diff -uNr libvirt-0.9.11.4.orig/tests/networkxml2argvdata/isolated-network.argv libvirt-0.9.11.4/tests/networkxml2argvdata/isolated-network.argv
--- libvirt-0.9.11.4.orig/tests/networkxml2argvdata/isolated-network.argv	2012-06-15 14:21:54.0 -0400
+++ libvirt-0.9.11.4/tests/networkxml2argvdata/isolated-network.argv	2012-08-22 12:20:37.700995728 -0400
@@ -1,4 +1,5 @@
-@DNSMASQ@ --strict-order --bind-interfaces --conf-file= \
+@DNSMASQ@ --strict-order --bind-interfaces \
+--local=// --domain-needed --filterwin2k --conf-file= \
 --except-interface lo --dhcp-option=3 --no-resolv \
 --listen-address 192.168.152.1 \
 --dhcp-range 192.168.152.2,192.168.152.254 \
diff -uNr libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network.argv libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network.argv
--- libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network.argv	2012-06-15 14:21:54.0 -0400
+++ libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network.argv	2012-08-22 12:21:24.481703184 -0400
@@ -1,4 +1,5 @@
-@DNSMASQ@ --strict-order --bind-interfaces --conf-file= \
+@DNSMASQ@ --strict-order --bind-interfaces \
+--local=// --domain-needed --filterwin2k --conf-file= \
 --except-interface lo --listen-address 192.168.122.1 \
 --listen-address 192.168.123.1 --listen-address 2001:db8:ac10:fe01::1 \
 --listen-address 2001:db8:ac10:fd01::1 --listen-address 10.24.10.1 \
diff -uNr libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network-dns-hosts.argv libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network-dns-hosts.argv
--- libvirt-0.9.11.4.o

Re: [Dnsmasq-discuss] MX forwarding

2012-08-25 Thread Gene Czarcinski 

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;

diff -uNr libvirt-0.9.11.4.orig/src/network/bridge_driver.c libvirt-0.9.11.4/src/network/bridge_driver.c
--- libvirt-0.9.11.4.orig/src/network/bridge_driver.c	2012-06-15 14:23:21.0 -0400
+++ libvirt-0.9.11.4/src/network/bridge_driver.c	2012-08-22 12:16:45.263488789 -0400
@@ -490,8 +490,15 @@
  */
 virCommandAddArgList(cmd, "--strict-order", "--bind-interfaces", NULL);
 
-if (network->def->domain)
+if (network->def->domain) {
 virCommandAddArgList(cmd, "--domain", network->def->domain, NULL);
+virCommandAddArgFormat(cmd, "--local=/%s/", network->def->domain);
+virCommandAddArgList(cmd, "--domain-needed", "--filterwin2k", NULL);
+}
+else { /* need to specify local even if no domain specified */
+virCommandAddArg(cmd, "--local=//");
+virCommandAddArgList(cmd, "--domain-needed", "--filterwin2k", NULL);
+}
 
 if (pidfile)
 virCommandAddArgPair(cmd, "--pid-file", pidfile);
diff -uNr libvirt-0.9.11.4.orig/tests/networkxml2argvdata/isolated-network.argv libvirt-0.9.11.4/tests/networkxml2argvdata/isolated-network.argv
--- libvirt-0.9.11.4.orig/tests/networkxml2argvdata/isolated-network.argv	2012-06-15 14:21:54.0 -0400
+++ libvirt-0.9.11.4/tests/networkxml2argvdata/isolated-network.argv	2012-08-22 12:20:37.700995728 -0400
@@ -1,4 +1,5 @@
-@DNSMASQ@ --strict-order --bind-interfaces --conf-file= \
+@DNSMASQ@ --strict-order --bind-interfaces \
+--local=// --domain-needed --filterwin2k --conf-file= \
 --except-interface lo --dhcp-option=3 --no-resolv \
 --listen-address 192.168.152.1 \
 --dhcp-range 192.168.152.2,192.168.152.254 \
diff -uNr libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network.argv libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network.argv
--- libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network.argv	2012-06-15 14:21:54.0 -0400
+++ libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network.argv	2012-08-22 12:21:24.481703184 -0400
@@ -1,4 +1,5 @@
-@DNSMASQ@ --strict-order --bind-interfaces --conf-file= \
+@DNSMASQ@ --strict-order --bind-interfaces \
+--local=// --domain-needed --filterwin2k --conf-file= \
 --except-interface lo --listen-address 192.168.122.1 \
 --listen-address 192.168.123.1 --listen-address 2001:db8:ac10:fe01::1 \
 --listen-address 2001:db8:ac10:fd01::1 --listen-address 10.24.10.1 \
diff -uNr libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network-dns-hosts.argv libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network-dns-hosts.argv
--- libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network-dns-hosts.argv	2012-06-15 14:21:54.0 -0400
+++ libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network-dns-hosts.argv	2012-08-22 12:25:30.378218203 -0400
@@ -1,3 +1,4 @@
 @DNSMASQ@ --strict-order --bind-interfaces --domain example.com \
+--local=/example.com/ --domain-needed --filterwin2k \
 --conf-file= --except-interface lo --listen-address 192.168.122.1 \
 --expand-hosts --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts\
diff -uNr libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network-dns-srv-record.argv libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network-dns-srv-record.argv
--- libvirt-0.9.11.4.orig/tests/networkxml2argvdata/nat-network-dns-srv-record.argv	2012-06-15 14:21:54.0 -0400
+++ libvirt-0.9.11.4/tests/networkxml2argvdata/nat-network-dns-srv-record.argv	2012-08-22 12:22:35.471268869 -0400
@@ -1,7 +1,7 @@
 @DNSMASQ@ \
 --

Re: [Dnsmasq-discuss] MX forwarding

2012-08-25 Thread Gene Czarcinski 

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.


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

2012-08-24 Thread Gene Czarcinski 

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<<
I have been looking at the code.  I really do not want to spend the time 
to figure out everything about how dnsmasq works and, thus, I may be 
misunderstanding something.


This whole deal came up because I realized that, by default, 
/usr/bin/host will query for A, , and MX records.


First of all, let me expand on questions.  If "domain-needed" is 
specified in the conf file or on the command line, then I believe that 
NO (repeat NO), query requests should be forwarded for any query types 
... not just A or .


Does anyone have a reason that the above should not be the case (that is 
some plain-name queries should be forwarded even if domain-needed is 
specified?


OK, in the little looking at the code, I believe that some changes are 
needed in forward.c around line 212 or at least somewhere in the 
search_servers routine.


In my testing, I have come up with yet another corner-case: if you use 
"host ." then, sure enough all the queries are forwarded.  I cannot see 
why this should be done.


All of these "problems" are really corner-cases ... I can see myself, if 
I was writing the code, think why worry about that, that type of query 
will never be issued.  Yeah, right.


Any comments are appreciated.

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

2012-08-23 Thread /dev/rob0 
On Thu, Aug 23, 2012 at 11:41:17AM -0400, Gene Czarcinski wrote:
> On 08/23/2012 10:44 AM, /dev/rob0 wrote:
> >On Thu, Aug 23, 2012 at 10:26:25AM -0400, Gene Czarcinski wrote:
> >>I checked my dnsmasq.conf and I have "local=/xxx/", "domain xxx",
> >"XXX" is a valid top-level domain, so it might not be a good 
> >choice for your internal domain. That said, it was chosen to be 
> >easy to block, because many sites will want to do that.

> Actually, that was just for the example.  With the "real" testing
> I used domain names such as test, bigboy, and thisisit.

Ah, I just figured it was the actual domain because I could think of 
no reason why you'd want to mung names like "test", "bigboy", and 
"thisisit". :)
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  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] MX forwarding

2012-08-23 Thread Gene Czarcinski 

On 08/23/2012 10:44 AM, /dev/rob0 wrote:

Simon is on holiday and might not be able to answer very soon. The
only other nugget I can toss out is this one:

On Thu, Aug 23, 2012 at 10:26:25AM -0400, Gene Czarcinski wrote:

I checked my dnsmasq.conf and I have "local=/xxx/", "domain xxx",

"XXX" is a valid top-level domain, so it might not be a good choice
for your internal domain. That said, it was chosen to be easy to
block, because many sites will want to do that.
Actually, that was just for the example.  With the "real" testing I used 
domain names such as test, bigboy, and thisisit.


All this started with a lot more stuff getting forwarded from the 
virtual systems.  It seems that libvirt needed to add some parameters 
when it started dnsmasq.  There is a patch submitted to libvirt to 
address that.  But, after getting that working, there was still the MX 
queries that were getting forwarded.


Gene

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

2012-08-23 Thread /dev/rob0 
Simon is on holiday and might not be able to answer very soon. The 
only other nugget I can toss out is this one:

On Thu, Aug 23, 2012 at 10:26:25AM -0400, Gene Czarcinski wrote:
> I checked my dnsmasq.conf and I have "local=/xxx/", "domain xxx",

"XXX" is a valid top-level domain, so it might not be a good choice 
for your internal domain. That said, it was chosen to be easy to 
block, because many sites will want to do that.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  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] MX forwarding

2012-08-23 Thread Gene Czarcinski 
I am a recent convert to dnsmasq.  Previously, I was using bind(named) 
and dhcpd to support my small research network.  I also run 
libvirt/qemu/kvm virtualization and noticed its use of dnsmasq ... I was 
impressed.  In fact, since every system upgrade results in a bind(named) 
and dhcpd  "adventure", I thought I would give dnsmasq a try.


Much to my amazement, a couple of hours of reading and creating a 
dnsmasq.conf for my networks plus another couple of hours of testing 
with virtual guest systems and I had a working dnsmasq.  To say the 
least, I was pleased.


Naturally, since I was new to dnsmasq, I turned on query logging and 
kept an eye on it.  Much to my amazement, I saw MX queries from virtual 
guests as well as MX queries for the systems on my local networks 
(dnsmasq was handling both dns and dhcp services for these system) being 
FORWARDED up to my ISP on the Internet.


I checked my dnsmasq.conf and I have "local=/xxx/", "domain xxx", and 
"domain-needed" specified.  According to what I read, this should not be 
happening.  I added "selfmx" so that this would not happen for the local 
systems.  However, if i did a "host test.", the responses were  
NXDOMAIN-IPv4, NXDOMAIN-IPv6, MX forwarded to the Internet.


I did more testing and set up two virtual systems: test1 and test2. 
Test1 has two networks defined: a connection to the default network with 
connects to the local network and on to the Internet and second 
connection to a private virtual network.  Test1 uses dnsmasq to provide 
dns and dhcp services on the private network.  Test2 has one network 
connection to the private network and uses test1 to get dns and dhcp 
services.  With these two systems, I can "play" with the dnsmasq 
parameters and use test2 to issue queries.  Although I have not tried 
every possible combination, these are the two I concentrated on:


--domain-needed --local=//

For a query from test2 of "host test2", the responses were:

query[A]: DHCP test2 is 192.168.100.173
query[]: config test2 is NODATA-IPv6
query[MX]: config test2 is NODATA

For a query from test2 of "host xxx", the response were:
query[A] config xxx is NXDOMAIN-IPv4

This is what I expected and this is what I wanted to see. Naturally, any 
query with a qualified name specified (good or bad) was forwarded up the 
the next server in the chain.


--domain-needed --domain tst --local=/tst/

For a query from test2 of "host test2", the responses were:

query[A]: DHCP test2.tst is 192.168.100.173
query[]: config test2.tst is NODATA-IPv6
query[MX]: config test2.tst is NODATA

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<<


Everything looks like it is mostly working the way I wanted except for 
the query[MX} handling.


I can see no reason that this "should" be happening but it is. Besides 
fixing this (or if there is areason that some users might need it), it 
might be nice if there was a "no-mx"/"mx=no" option besides "selfmx" and 
"localmx".


The system is Fedora 17.  The version of the dnsmasq is 2.59.

If you need any other info or some testing on my part, this is 
relatively easy to do with the virtual setup I have.


Gene


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