Re: [Dnsmasq-discuss] Overlapping/duplicate subnets

2017-02-22 Thread S. M. Hossein Hamidi 
Hi,

While it might seem weird, it is a valid scenario. There might be reasons
to let reusing IP addresses.

To answer your question about deployment of NAT devices, it shouldn't be
just a NAT device. Each LAN segment can have its own NAT gateway.

Regards,

On Wed, Feb 22, 2017 at 4:07 PM, /dev/rob0  wrote:

> On Wed, Feb 22, 2017 at 02:55:30PM +0100, S. M. Hossein Hamidi wrote:
> > I am new to dnsmasq and my mind is busy with a DHCP scenario that I
> > would like to consult with you before getting my hands dirty.
> >
> > Suppose that we have several subnets which are behind a NAT device
> > which additionally acts as a DHCP relay agent. I know that using
> > DHCP relay agent information option, I can distinguish between
> > different subnets. However, the additional constraint is to use
> > duplicate or overlapping subnets instead of distinct subnets.
>
> That is a very strange constraint.  RFC 1918 is quite large enough;
> it's not necessary to share your netblocks.  And how will your NAT
> device distinguish one segment with a shared netblock from another
> segment using the same netblock?
>
> Sounds like broken IP networking to me.  Compliant IP stacks do
> routing based on IP address blocks.
>
> > Since, the traffic comes from each segment goes through NAT, it
> > wouldn't be any problem to use duplicate IP addresses, knowing
> > that each segment has its own autonomy.
>
> But again, how does the NAT device do this?
>
> > So, may I know if can I exploit tagging feature of dnsmasq so
> > that it can handle separate potentially overlapping leases for
> > each subnet?
>
> I'm pretty sure this would not be possible in dnsmasq nor in ISC
> dhcpd.  Either one could do a single netblock shared among many
> distinct segments, but each would only be able to give out any one
> address to only one client.
>
> But wait and see what Simon says. :)
> --
>   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] Support of labels in --interface

2017-02-22 Thread Petr Menšík 
Simon Kelley píše v Út 21. 02. 2017 v 18:50 +:
> > Labels are now supported and dnsmasq is able to bind only to
> > secondary IPv4 interface with different address. (Since 2.67!) It
> > works well with --bind-interfaces. However it has inconsistent
> > behavior with and without that option.
> > 
> > Let's say my configuration is: 4: virbr0:
> >  mtu 1500 qdisc noqueue state UP
> > group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> > ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> > global virbr0 valid_lft forever preferred_lft forever inet
> > 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> > forever preferred_lft forever
> > 
> > 
> > $ dnsmasq -i virbr0 will respond to queries to both addresses. It
> > might be useful backward compatibility feature. However $ dnsmasq
> > -i virbr0:1 Will respond only on address 192.168.122.254. Ok, call
> > it a feature.
> > 
> > Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
> > 192.168.122.1, as I would expect.
> > 
> > $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
> > 
> > I think different behavior is an error. It might be a feature, but
> > even then, it has to be documented. Opinions?
> 
> The different behavior is certainly undesirable, and can be fixed.
> Unfortunately, I can only see how to easily fix it so that the
> --bind-interfaces case works the same way as the default.
I would suggest a new option then. For example --bind-interfaces-exact. 
It would listen just like --bind-interfaces, but would allow you to
listen only on virbr0, when ignoring any addresses with labels. Current
behavior in other words, but documented as a new feature. It would
allow previous behavior at the same time also.
> 
> The problem is that the sockets API tells you the interface that the
> packet arrived on, and that's what's checked with -i. In your
> example,
> queries send to 192.168.122.1 and 192.168.122.254 both arrive at
> interface virbr0, so there's no easy way to tell them apart, except
> by
> looking at the address they were sent to and correlating that with
> the
> list of interfaces and their addresses .
> 
> That requires an up-to-date list of all interfaces, which means, if
> you're going to behave well in the face of interfaces and addresses
> coming and going, enumerating the list for every packet received,
> which will likely kill performance.
I think this already happens if you listen on virbr0:1.

Another option might be getting interface address of by index. If they
would not match with destination of packet, return failure from
iface_check (and let it be accepted by label_exception). You would not
have to enumerate all addresses of all interfaces, only one for current
interface. It adds one more syscall, but it should be faster than
getifaddrs(). ioctl SIOCGIFADDR is already used in dhcp.c.
> 
> My feeling is that consistency is good, so I'll certainly make a
> change, the question is, is the current behaviour of -i  name> as encompassing _all_ addresses associated with the interface
> OK?
I think it is unexpected and should be mentioned in manual page. But it
acted like that before, so it would be not break backward compatibility
at least. If it is fixed in default wild mode, we should note that -i
virbr0,virbr0:* is now required for previous behavior in manual.
> 
> 
> 
> Cheers,
> 
> Simon.
> 
Cheers,
Petr
> 
> 
> 
> > 
> > [1]
> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42
> > c4d
> 
> 7e7dba32b6e64a3687d43928bc8e
> > 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


signature.asc
Description: This is a digitally signed message part
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] can't get multiple domains to work

2017-02-22 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

You can have multiple domains, but you need to associate subnets with
them, so dnsmasq can determine which one to use.


Cheers,

Simon.



On 21/02/17 03:35, Spike wrote:
> I didn't because it seemed wrong, generally speaking the last entry
> for a given keyword should override former if dups are allowed at
> all. In any case I just tried and that's what happened, with
> 
> domain=good domain=better
> 
> host.better started to resolve and host.good no longer resolved.
> 
> that said it's true that the most recent hit on the ML for
> "multiple domain" did mention a similar setup with two domain lines
> altho it had two diff ranges.
> 
> thanks,
> 
> Spike
> 
> On Mon, Feb 20, 2017 at 6:55 PM richardvo...@gmail.com 
>   > wrote:
> 
> Have you tried using more than one domain= line?
> 
> On Mon, Feb 20, 2017 at 6:57 PM, Spike  > wrote:
> 
> Dear all,
> 
> first time poster here so first things first, thanks to all of you
> that have worked on dnsmasq, all of us here have greatly benefited
> for years from this great piece of software.
> 
> Second, my google-fu and manpage reading are failing me and I can't
> seem to find a way to have dnsmasq resolve queries for multiple
> domains. I've found some posts from 2008 about introducing the
> feature and a recent one about multiple domains, but for different
> ranges.
> 
> What I'm dealing with is a change of domain, so right now 
> dnsmasq.conf has domain=good and eventually it will be 
> domain=better , but during the transition phase it would be useful
> if it could be domain=good,better so that queries for host.good and
> host.better resolve to the same dhcp-host definition.
> 
> is that possible? what's the actual syntax? The manual mentions 
> "domainS", plural, but not if there is a particular syntax to 
> specify them and comma does not work (for example for local it 
> specifically mentions /domain/domain/).
> 
> I guess the alternative if the above isn't possible would be to 
> allow any kind of domain to basically be ignored so that entries 
> are returned as long as the host path matches (this is just during
> the transition phase so it would be ok)
> 
> thanks,
> 
> Spike
> 
> ___ 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrf++AAoJEBXN2mrhkTWixi0P/A9xPahfW1hRbC2jtCnu+Cpb
v7AWBRRE81jkAdEMiawVfS/kinEku4BFFMVKbslw6q+R9HvrKoTHpi+CUGhAmEx2
4JEnsqfAS6yhqjfdu4pk7n2ZcmL7SDaiEdPCKFCd2ORaI05J+2ivfCqeKgwV+98Y
vjdXBnBrn8BO1yfijfVv0MqQDl8BYMcygzY0mfgVrC/4Ef7fKv7EV4DHrQ1TZkAD
9l5hyq17JpYc8VVJZRpB5hRO9QT6H4WR0RT8u5W0EodlilTOSEBygBbJm7LBXb7H
tTgxJ0+/H3BpX1uyJ7Y+xYdOnK+m/mpnivWGjaSVtrPRZ8k0ZdN/r5lGJ5sOpbhn
GRiwEJs0d+XgRUr8C6FkirJ91WN/V5Ka+ODwY9YMVt4o8o2X3uFC+fIV3I1/4RVd
b30+EnU9dXzeAxZ2jzs88pxX0R+wSpa7/Kj/wSHgFDn3YsMEiGVQtLqPVYnLxcNR
As0DbM5nwG6eSTxK5Bstgxs4IcUUu1VtG2hvnyMCfNSQDkh6b7o9t7FAn95DqBCN
rcAs3xdf4EO5cStIWXa3iBT/IsTBVuOh/+nZHgX/I1oXZkDTZU/pG9XAUBl0MuQ/
oj3yRZNVSCZ3QzQK78NrA9KmCTbuZvqMwDtlfJIvHom1wErpSz9fdUfaxpYYlYs3
+g5jhwh/nPcrgQS3wVX4
=t+QV
-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] Support of labels in --interface

2017-02-22 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> You can get the destination address for datagrams from the
> IP_PTKINFO auxiliary data:
> 
> man 7 ip IP_PKTINFO (since Linux 2.2) Pass an IP_PKTINFO ancillary
> message that contains a pktinfo structure that supplies some
> information about the incoming packet. This only works for datagram
> oriented sockets.  The argument is a flag that tells the socket
> whether the IP_PKTINFO message should be passed or not. The message
> itself can only be sent/retrieved as control message with a packet
> using recvmsg(2) or sendmsg(2).
> 
> struct in_pktinfo { unsigned int   ipi_ifindex;  /* Interface index
> */ struct in_addr ipi_spec_dst; /* Local address */ struct in_addr
> ipi_addr; /* Header Destination address */ };
> 

Indeed. And that gives you, in one hand, the destination address of
the datagram, and in the other hand, a whitelist of interface labels.
The only way to compare the two is to enumerate all the interfaces
using the netlink interface, which gives you all the addresses of each
interface and their associated labels. If the interface set and
configuration can change arbitrarily, you need to do that for every
datagram, which gets expensive.


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrfngAAoJEBXN2mrhkTWi4GsP/ApliVfiOsVguaMMAfY7MmJX
Q6ieWcPgNrQHXLgKjiJZpof2m9ZOvHKnR37rXNXW6v2x5J3vnRAaigil0j0wEb/u
3R733QI2eNkCOnzAmpO+zKDpkq/KjReEary6znOKp33U1B8kCMpPcJDDx3QZEkjS
qwAMgpsz3IKA+ezNgYbI/311B3RpMGt2XdvUNkHG9JDL2FAroS9/G0/vrmFKaDMZ
1+R09AtJBHvu/fOEbNcnl4r7mwwdMqd6ONPc6oqrah+gOkjdLWQe3M50fZ1aJC0y
r5HH+hp/MobyAxkF7gzbzt4VLG+fGU17ZanJZHRQgKnqsvj1e4pLdCP5wJ/4D1ya
ZlYQ6i3IjCVMXLS+y/tpJtPksnw49soHVOGObIpaT6lEEqX7BgTVvbFPv876aUn/
xkNvE83XzKPJ4LkKTR3cbXi5oJiglmDaClLgq+CRDdgu8cK41o/q6Fbv/gTs7X6N
AHurx+5X7AzArdJdF/cDrt7a7qA5GT7wonUgNZt8xXzW/WWlkMQ878aK2ij2kBFy
AYzeCpqyMyKZ0hEt3VgGo2p5k/cr/Wik5IaaXbrJZC33dRrVAWB6OdAXqmVED9ei
GavpRz+YYwHJaBQoo8ZFjDCEZHqWkFZszMO+B2DuDWYenB/QOCBUYWTEVgfPnPVw
w03CB2ZmjqWfZEHzfiW0
=QPnP
-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] Overlapping/duplicate subnets

2017-02-22 Thread /dev/rob0 
On Wed, Feb 22, 2017 at 02:55:30PM +0100, S. M. Hossein Hamidi wrote:
> I am new to dnsmasq and my mind is busy with a DHCP scenario that I 
> would like to consult with you before getting my hands dirty.
> 
> Suppose that we have several subnets which are behind a NAT device 
> which additionally acts as a DHCP relay agent. I know that using 
> DHCP relay agent information option, I can distinguish between 
> different subnets. However, the additional constraint is to use 
> duplicate or overlapping subnets instead of distinct subnets.

That is a very strange constraint.  RFC 1918 is quite large enough; 
it's not necessary to share your netblocks.  And how will your NAT 
device distinguish one segment with a shared netblock from another 
segment using the same netblock?

Sounds like broken IP networking to me.  Compliant IP stacks do 
routing based on IP address blocks.

> Since, the traffic comes from each segment goes through NAT, it 
> wouldn't be any problem to use duplicate IP addresses, knowing
> that each segment has its own autonomy.

But again, how does the NAT device do this?

> So, may I know if can I exploit tagging feature of dnsmasq so
> that it can handle separate potentially overlapping leases for
> each subnet?

I'm pretty sure this would not be possible in dnsmasq nor in ISC 
dhcpd.  Either one could do a single netblock shared among many 
distinct segments, but each would only be able to give out any one 
address to only one client.

But wait and see what Simon says. :)
-- 
  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] Overlapping/duplicate subnets

2017-02-22 Thread S. M. Hossein Hamidi 
Hi all,

I am new to dnsmasq and my mind is busy with a DHCP scenario that I would
like to consult with you before getting my hands dirty.

Suppose that we have several subnets which are behind a NAT device which
additionally acts as a DHCP relay agent. I know that using DHCP relay agent
information option, I can distinguish between different subnets. However,
the additional constraint is to use duplicate or overlapping subnets
instead of distinct subnets. Since, the traffic comes from each segment
goes through NAT, it wouldn't be any problem to use duplicate IP addresses,
knowing that each segment has its own autonomy.

So, may I know if can I exploit tagging feature of dnsmasq so that it can
handle separate potentially overlapping leases for each subnet?


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