[Dnsmasq-discuss] Tag from interface name?
I'd like to be able to classify DHCP requests based on the interface they come in on. I'd like to have a tag based on the interface name (so, if the request came in over br0, I'd have a br0 tag to match on). Is there any way of accomplishing this with dnsmasq currently? My interfaces don't actually have an IP address assigned, so I can't match by IP. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Estimation of TFTP Server Load Capabilities
One option here is to use iPXE ( http://www.ipxe.org/ ) to grab the netboot files via HTTP (or some other protocol) instead of relying on TFTP. There's some extra configuration work here, but serving up the 365KB iPXE image to clients via TFTP is a lot less work then serving up the entire kernel/initrd package. On 7/23/2014 11:13 PM, Linux Luser wrote: I have a project where I use dnsmasq for netboot installs. Currently, there can be an unlimited number of installs happened at once. At what point (number of TFTP transfers happening in parallel) should I be concerned that I'm overtaxing dnsmasq's TFTP capabilities? Does dnsmasq use threads or multiprocessing for TFTP transfers? Thanks. ___ 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
[Dnsmasq-discuss] Debugging
Is there any way to get additonal debugging information out of dnsmasq? I'm running into an issue where I'm seeing 'DHCPDISCOVER(eth0) X Y no address available', but it's not particularly clear to me why this is happening. Is there a way to log the contents of the DISCOVER packet? I know I can use tcpdump, but that doesn't show me what dnsmasq actually thinks is in the packet. In my case, I should be seeing a subscriber-id in the packets. I see it in tcpdump, but I'm not clear if dnsmasq is actually parsing it. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Debugging
Sorry, should have mentioned that I already have that enabled. That gives me some extra info: Feb 11 11:14:07 x dnsmasq-dhcp[2278]: 3227716451 DHCPDISCOVER(eth0) 00:25:90:d6:ac:25 no address available Feb 11 11:14:08 x dnsmasq-dhcp[2278]: 467005255 available DHCP range: 10.x.10 -- 10.x.250 Feb 11 11:14:08 x dnsmasq-dhcp[2278]: 467005255 available DHCP range: 10.y.10 -- 10.y.250 Feb 11 11:14:08 x dnsmasq-dhcp[2278]: 467005255 available DHCP range: 10.z.10 -- 10.z.250 Feb 11 11:14:08 x dnsmasq-dhcp[2278]: 467005255 vendor class: udhcp 1.12.0 but doesn't appear to log the subscriber ID. I can't tell if its supposed to be logged in that case either. On 2/11/2014 10:50 AM, Simon Kelley wrote: On 11/02/14 15:12, Brian Rak wrote: Is there any way to get additonal debugging information out of dnsmasq? I'm running into an issue where I'm seeing 'DHCPDISCOVER(eth0) X Y no address available', but it's not particularly clear to me why this is happening. Is there a way to log the contents of the DISCOVER packet? I know I can use tcpdump, but that doesn't show me what dnsmasq actually thinks is in the packet. In my case, I should be seeing a subscriber-id in the packets. I see it in tcpdump, but I'm not clear if dnsmasq is actually parsing it. log-dhcp will help. 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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Limit DNS queries to the local subnet clients
That's how you end up with an open DNS resolver, and unwittingly DDOS other machines. On 11/28/2013 10:52 PM, Don Muller wrote: Wouldn't it be better to not define dnsmasq as the DNS resolver for the subnets you don't want handle. Sent from my iPad Don Muller On Nov 28, 2013, at 12:26 PM, Édouard Thuleau thul...@gmail.com wrote: Hi, I'm new with dnsmasq and I like to know if we can limit it to answer DNS queries only to clients of the subnet served by dnsmasq or to a defined subnet ? Regards, Édouard. ___ 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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Limit DNS queries to the local subnet clients
Your initial answer seems to assume that if you don't tell anyone about your DNS server, no one will discover it. That's pretty much wrong. Every public IP on the internet is going to be probed looking for open DNS servers to abuse multiple times a day. Also, assuming that everyone is in a trusted, internal lan is not a valid assumption. With various virtualization platforms using dnsmasq for DNS/DHCP, I'd say it's increasingly being used in places where it's directly exposed to the internet. On 11/29/2013 10:34 AM, Don Muller wrote: Yes if dmsmasq was open to internet but that would not prevent the request from coming in, just from it being answered. The question was how limit dnsmasq to answer DNS queries only to clients of the subnet served by dnsmasq or to a defined subnet. So assuming it is in a controlled environment (internal lan) if you don't setup the other subnets to send requests to dnamasq then it would only receive requests on the subnets you do want to service. Besides why would you want to set up the dns resolver on subnets you were not going to answer? I think the answer to this is better network set up on the client subnets and also at the routers and firewalls. Don -Original Message- From: Brian Rak [mailto:b...@gameservers.com] Sent: Friday, November 29, 2013 9:45 AM To: Don Muller; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Limit DNS queries to the local subnet clients That's how you end up with an open DNS resolver, and unwittingly DDOS other machines. On 11/28/2013 10:52 PM, Don Muller wrote: Wouldn't it be better to not define dnsmasq as the DNS resolver for the subnets you don't want handle. Sent from my iPad Don Muller On Nov 28, 2013, at 12:26 PM, Édouard Thuleau thul...@gmail.com wrote: Hi, I'm new with dnsmasq and I like to know if we can limit it to answer DNS queries only to clients of the subnet served by dnsmasq or to a defined subnet ? Regards, Édouard. ___ 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 ___ 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] Limit DNS queries to the local subnet clients
You seem to be a bit confused about how the attack works. It's not directed at the dnsmasq server. The attacker uses Spode's traffic to trick dnsmasq into attacking a remote server. DNS replies proceed amplification and anonymity to the attacks. Dropping outgoing DNS replies will prevent the server from being abused. On a daily basis I deal with mis configured servers that are attacking my machines. While perimiter defenses are great in theory defense in depth is what you want for real networks Don Muller d...@djmuller.com wrote: I agree with what you are saying but I think you are missing the point of the question. The poster only wanted dnsmasq to respond to certain subnets. The place to do that is not in dnsmasq but at the perimeter. Setting up dnsmasq to not respond does not stop the traffic from coming in, it just stops it from responding. The place to stop any type of attack is at the perimeter and not someplace inside the network. For internal networks don't set up dnsmasq as your DNS resolver and you don't have to tell dnsmasq to not respond. Sent from my iPad Don Muller On Nov 29, 2013, at 2:03 PM, Brian Rak b...@gameservers.com wrote: Your initial answer seems to assume that if you don't tell anyone about your DNS server, no one will discover it. That's pretty much wrong. Every public IP on the internet is going to be probed looking for open DNS servers to abuse multiple times a day. Also, assuming that everyone is in a trusted, internal lan is not a valid assumption. With various virtualization platforms using dnsmasq for DNS/DHCP, I'd say it's increasingly being used in places where it's directly exposed to the internet. On 11/29/2013 10:34 AM, Don Muller wrote: Yes if dmsmasq was open to internet but that would not prevent the request from coming in, just from it being answered. The question was how limit dnsmasq to answer DNS queries only to clients of the subnet served by dnsmasq or to a defined subnet. So assuming it is in a controlled environment (internal lan) if you don't setup the other subnets to send requests to dnamasq then it would only receive requests on the subnets you do want to service. Besides why would you want to set up the dns resolver on subnets you were not going to answer? I think the answer to this is better network set up on the client subnets and also at the routers and firewalls. Don -Original Message- From: Brian Rak [mailto:b...@gameservers.com] Sent: Friday, November 29, 2013 9:45 AM To: Don Muller; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Limit DNS queries to the local subnet clients That's how you end up with an open DNS resolver, and unwittingly DDOS other machines. On 11/28/2013 10:52 PM, Don Muller wrote: Wouldn't it be better to not define dnsmasq as the DNS resolver for the subnets you don't want handle. Sent from my iPad Don Muller On Nov 28, 2013, at 12:26 PM, Édouard Thuleau thul...@gmail.com wrote: Hi, I'm new with dnsmasq and I like to know if we can limit it to answer DNS queries only to clients of the subnet served by dnsmasq or to a defined subnet ? Regards, Édouard. ___ 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 ___ 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] timing of dhcp-script for tftp downloads
On 11/16/2013 10:01 AM, Simon Kelley wrote: Also, is there any way to know when a tftp download starts vs.ends? No, I don't think so. You could always chainload iPXE, and use HTTP instead of TFTP. You'd be able to use any server side language to do actions when a download starts/ends. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DNSMasq and DNS reflection attacks
We've recently undertaken a project to clean up our network, and lock down all the open DNS resolvers. As you may know, these are very frequently used for DDOS attacks: http://openresolverproject.org/ , http://www.team-cymru.org/Services/Resolvers/ . I haven't been able to find any sort of configuration option that would prevent DNSMasq from being abused like this, and I've had to resort to iptables rules instead. Is there a configuration option that that would disable responding to DNS queries from certain interfaces? The other option that seems handy would be one to only reply to DNS queries from hosts that have a configured DHCP lease. Are there any features of DNSMasq that would prevent it from being abused to conduct attacks? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
On 10/24/2013 12:28 PM, Simon Kelley wrote: On 24/10/13 17:03, Brian Rak wrote: We've recently undertaken a project to clean up our network, and lock down all the open DNS resolvers. As you may know, these are very frequently used for DDOS attacks: http://openresolverproject.org/ , http://www.team-cymru.org/Services/Resolvers/ . I haven't been able to find any sort of configuration option that would prevent DNSMasq from being abused like this, and I've had to resort to iptables rules instead. Is there a configuration option that that would disable responding to DNS queries from certain interfaces? The other option that seems handy would be one to only reply to DNS queries from hosts that have a configured DHCP lease. Are there any features of DNSMasq that would prevent it from being abused to conduct attacks? This is an important topic, and quite difficult to understand, so I'm going to take this opportunity to try and put a definitive statement on the record. First the simple stuff. Dnsmasq has --interface --except-interface and --listen-address configuration options that disable response to DNS queries from certain interfaces. The first thing that has to be done is to use these. Mostly it's the only thing that needs to done. Now, the complicated stuff. Under certain circumstances, --interface=interface degrades to mean the same as --listen-address=address on interface. For instance if eth0 has address 192.168.0.1 and dnsmasq is configured with --interface=eth0, then dnsmasq will reply to any query which is sent to 192.168.0.1, no matter what interface it actually arrives at. The circumstance under which happens is when the --bind-interfaces flag is used. Now, in the above example, this isn't a problem, since a botnet can't direct traffic to an RFC-1918 address. If, on the other hand, the address of an internal interface (ie one configured to accept DNS queries) is globally routable, then queries which arrive via another interface (ie one linked to the internet) with the destination address of the internal interface _will_ be replied to, and a DNS reflection attack is possible. This has mainly been seen in libvirt and OpenStack installations which use dnsmasq, since sometimes they are provisioned with real addresses. I'd expect to see problems in the future with IPv6, since far more people will be using globally routable addresses with IPv6. The reason that this happens is that --bind-interfaces uses the bare-minimum BSD sockets API only. Detecting which interface a packet arrived on, rather than the address to which it was sent, needs non-portable API, and is impossible on some platforms (openBSD, for instance) --bind-interfaces is a works everywhere least common denominator. It's also useful when you're running multiple instances of dnsmasq on one host, which is why most people use it. The fix is to use either the default listening mode, or if running multiple instances, the new --bind-dynamic mode. --bind-dynamic is only available on Linux, and --bind-interfaces is the only mode available on openBSD, so BSD users have rather more problems here. Summary. There's a problem is you want to accept queries in an internal interface with a globally routable address and use --bind-interfaces. The fix is to remove --bind-interfaces and, if necessary, replace it with --bind-dynamic. This fix is not applicable on all platforms, The Real Soon Now 2.67 release logs a very prominent warning if the dangerous combination is configured. Cheers, Simon. Thanks for the detailed explanation! It seems that for some of my servers I can resolve the issue by using --interface and --except-interface. I do however have some DNSMasq instances that are providing public, globally routable IP addresses via DHCP. In order to do this, DNSMasq must be listening on an interface with a public IP, so it ends up providing DNS on that IP as well. I'm not sure if this is a common use case or not. For this setup, would there be any other option aside from iptables rules? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
On 10/24/2013 1:00 PM, Simon Kelley wrote: On 24/10/13 17:46, Brian Rak wrote: On 10/24/2013 12:28 PM, Simon Kelley wrote: On 24/10/13 17:03, Brian Rak wrote: We've recently undertaken a project to clean up our network, and lock down all the open DNS resolvers. As you may know, these are very frequently used for DDOS attacks: http://openresolverproject.org/ , http://www.team-cymru.org/Services/Resolvers/ . I haven't been able to find any sort of configuration option that would prevent DNSMasq from being abused like this, and I've had to resort to iptables rules instead. Is there a configuration option that that would disable responding to DNS queries from certain interfaces? The other option that seems handy would be one to only reply to DNS queries from hosts that have a configured DHCP lease. Are there any features of DNSMasq that would prevent it from being abused to conduct attacks? This is an important topic, and quite difficult to understand, so I'm going to take this opportunity to try and put a definitive statement on the record. First the simple stuff. Dnsmasq has --interface --except-interface and --listen-address configuration options that disable response to DNS queries from certain interfaces. The first thing that has to be done is to use these. Mostly it's the only thing that needs to done. Now, the complicated stuff. Under certain circumstances, --interface=interface degrades to mean the same as --listen-address=address on interface. For instance if eth0 has address 192.168.0.1 and dnsmasq is configured with --interface=eth0, then dnsmasq will reply to any query which is sent to 192.168.0.1, no matter what interface it actually arrives at. The circumstance under which happens is when the --bind-interfaces flag is used. Now, in the above example, this isn't a problem, since a botnet can't direct traffic to an RFC-1918 address. If, on the other hand, the address of an internal interface (ie one configured to accept DNS queries) is globally routable, then queries which arrive via another interface (ie one linked to the internet) with the destination address of the internal interface _will_ be replied to, and a DNS reflection attack is possible. This has mainly been seen in libvirt and OpenStack installations which use dnsmasq, since sometimes they are provisioned with real addresses. I'd expect to see problems in the future with IPv6, since far more people will be using globally routable addresses with IPv6. The reason that this happens is that --bind-interfaces uses the bare-minimum BSD sockets API only. Detecting which interface a packet arrived on, rather than the address to which it was sent, needs non-portable API, and is impossible on some platforms (openBSD, for instance) --bind-interfaces is a works everywhere least common denominator. It's also useful when you're running multiple instances of dnsmasq on one host, which is why most people use it. The fix is to use either the default listening mode, or if running multiple instances, the new --bind-dynamic mode. --bind-dynamic is only available on Linux, and --bind-interfaces is the only mode available on openBSD, so BSD users have rather more problems here. Summary. There's a problem is you want to accept queries in an internal interface with a globally routable address and use --bind-interfaces. The fix is to remove --bind-interfaces and, if necessary, replace it with --bind-dynamic. This fix is not applicable on all platforms, The Real Soon Now 2.67 release logs a very prominent warning if the dangerous combination is configured. Cheers, Simon. Thanks for the detailed explanation! It seems that for some of my servers I can resolve the issue by using --interface and --except-interface. I do however have some DNSMasq instances that are providing public, globally routable IP addresses via DHCP. In order to do this, DNSMasq must be listening on an interface with a public IP, so it ends up providing DNS on that IP as well. I'm not sure if this is a common use case or not. For this setup, would there be any other option aside from iptables rules? Yes, use --interface to enable that interface for DNS and DHCP, and DON'T use --bind-interfaces. As long as you're not using bind interfaces, DNS requests which arrive via other interfaces won't be answered, even if they have destination addresses for the enabled interface. An example: You have a router with two interfaces, internal and external. Internal is where you're doing DHCP and DNS: it's connected to an ethernet with a load of hosts. Internal has a globally routable address (and so, presumably do the hosts on the ethernet). External also has a globally routeable address and is connected to internet. Attack packets therefore arrive on external. Setting --interface=internal means that attack packets which arrive via external will NOT be answered, ever. The exception to this if they are addressed to the IP address of internal AND --bind
Re: [Dnsmasq-discuss] DNSMasq and DNS reflection attacks
On 10/24/2013 4:40 PM, richardvo...@gmail.com wrote: Sorry, I should mention only drop packets in state NEW, you don't want to drop replies to your own queries. On Thu, Oct 24, 2013 at 3:39 PM, richardvo...@gmail.com mailto:richardvo...@gmail.com richardvo...@gmail.com mailto:richardvo...@gmail.com wrote: Your case should be easy to stop with a firewall rule. Just block all packets matching the dns listen port (53 usually) in the INPUT chain, where the source address is outside your block. Optionally (this prevents reflection attacks against your own network which you said is not required), configure your router to drop packets arriving on its external interface where the source IP is within your internal network. This is called a reverse route check. On Thu, Oct 24, 2013 at 12:11 PM, Brian Rak b...@gameservers.com mailto:b...@gameservers.com wrote: On 10/24/2013 1:00 PM, Simon Kelley wrote: On 24/10/13 17:46, Brian Rak wrote: On 10/24/2013 12:28 PM, Simon Kelley wrote: On 24/10/13 17:03, Brian Rak wrote: We've recently undertaken a project to clean up our network, and lock down all the open DNS resolvers. As you may know, these are very frequently used for DDOS attacks: http://openresolverproject.org/ , http://www.team-cymru.org/Services/Resolvers/ . I haven't been able to find any sort of configuration option that would prevent DNSMasq from being abused like this, and I've had to resort to iptables rules instead. Is there a configuration option that that would disable responding to DNS queries from certain interfaces? The other option that seems handy would be one to only reply to DNS queries from hosts that have a configured DHCP lease. Are there any features of DNSMasq that would prevent it from being abused to conduct attacks? This is an important topic, and quite difficult to understand, so I'm going to take this opportunity to try and put a definitive statement on the record. First the simple stuff. Dnsmasq has --interface --except-interface and --listen-address configuration options that disable response to DNS queries from certain interfaces. The first thing that has to be done is to use these. Mostly it's the only thing that needs to done. Now, the complicated stuff. Under certain circumstances, --interface=interface degrades to mean the same as --listen-address=address on interface. For instance if eth0 has address 192.168.0.1 and dnsmasq is configured with --interface=eth0, then dnsmasq will reply to any query which is sent to 192.168.0.1, no matter what interface it actually arrives at. The circumstance under which happens is when the --bind-interfaces flag is used. Now, in the above example, this isn't a problem, since a botnet can't direct traffic to an RFC-1918 address. If, on the other hand, the address of an internal interface (ie one configured to accept DNS queries) is globally routable, then queries which arrive via another interface (ie one linked to the internet) with the destination address of the internal interface _will_ be replied to, and a DNS reflection attack is possible. This has mainly been seen in libvirt and OpenStack installations which use dnsmasq, since sometimes they are provisioned with real addresses. I'd expect to see problems in the future with IPv6, since far more people will be using globally routable addresses with IPv6. The reason that this happens
[Dnsmasq-discuss] Multiple subnets without IP aliases
I have a layer 2 vlan (all hosts in the same broadcast domain), that has multiple subnets active on it. For example: interface ve 906 ip address 10.0.5.113 255.255.255.248 ip address 10.0.6.105 255.255.255.248 I have a machine with this configuration: br0 inet addr:10.0.6.110 Bcast:10.0.6.111 Mask:255.255.255.248 I'd like to serve addresses from both subnets from this machine I've found that I can do this if the machine running DNSMasq has an IP address in both subnets, but this is somewhat of a waste of IP addresses. Is it possible to serve DHCP to both subnets without having an IP address on the machine in both subnets? Before I added the IP alias, I was seeing this: dnsmasq-dhcp[5848]: 3598047279 available DHCP subnet: 10.0.6.104/255.255.255.248 DNSMasq wasn't even seeing the other subnet as being available. Once I added the alias, it did work properly: dnsmasq-dhcp[5952]: 1867860253 available DHCP subnet: 10.0.5.112/255.255.255.248 dnsmasq-dhcp[5952]: 1867860253 available DHCP subnet: 10.0.6.104/255.255.255.248 Renumbering the network isn't an option. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Pulling DHCP leases from an external script?
I'm trying to set up a DHCP server so that on any request for a new lease I can execute a script and have the script return an IP address (and other information). Is this something that is currently possible with dnsmasq? From reading the man page, I can't tell if I will get this behaviour with --dhcp-script --leasefile-ro. Basically, it would be impossible for me to specify all the possible DHCP leases at startup, but when a lease request is received I would be able to determine what IP to assign. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Pulling DHCP leases from an external script?
I'm trying to assign addresses via DHCP for a number of different networks (using ip-helper and option 82 on the switches). It's going to be tough for me to come up with a predefined list of what leases belong to what port, but it's definitely something I should be able to figure out when the lease is coming in. There's also the fact that the config file would end up being quite large if I pregenerate it for every possible combination. On 10/3/2012 3:47 PM, Jay Imerman wrote: I'm not 100% certain, but the way I read the man page, the script is triggered after the dnsmasq event occurs, so you can pass some custom behavior to a script after dnsmasq has managed the lease. However, it sounds like you want to customize dnsmasq behavior and insert your own algorithm for allocating IP addresses? Just out of curiosity, why? You can specify quite a complex set of allocation rules using tags and more, why would you need to have anything other than that? ___ Jay Imerman T (248) 230-4373 | F (952) 255-2056 4067 Highview Court Waterford, MI 48329-4712 http://twitter.com/#%21/jimerman http://www.linkedin.com/profile/view?id=15203444trk=tab_pro http://www.facebook.com/jay.imerman On Wed, Oct 3, 2012 at 3:14 PM, Brian Rak b...@gameservers.com mailto:b...@gameservers.com wrote: I'm trying to set up a DHCP server so that on any request for a new lease I can execute a script and have the script return an IP address (and other information). Is this something that is currently possible with dnsmasq? From reading the man page, I can't tell if I will get this behaviour with --dhcp-script --leasefile-ro. Basically, it would be impossible for me to specify all the possible DHCP leases at startup, but when a lease request is received I would be able to determine what IP to assign. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk mailto: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
