Re: [Dnsmasq-discuss] dns server
Maybe something like this will help: https://gist.github.com/linuxluser/cf8f967c9ec8167e6fed I tried to keep it minimal. Read the comments and change things to your liking. Again, that conf file applies to the SERVER, which should be running a standard version of dnsmasq, not the one that comes with NetworkManager. To address the other problem, NetworkManager has taken control of your /etc/resolv.conf file and will pretty much overwrite it whenever it wants (usually during DHCP renewals). There are ways to work around this, but it's going to start getting complicated. The easiest thing to do would be to turn off network-manager and configure your interfaces via /etc/network/interfaces file instead. Again, this is for the server only. For other machines (clients) on your network, network-manager would probably work just fine. Despite network-manager's insistence that it can be used for servers, there are still issues with that idea (namely, you'd have to do away with all the tried-and-true network configuration files and tools that most use on servers). On Wed, Apr 15, 2015 at 9:15 AM, Thiago Farina tfrans...@gmail.com wrote: On Tue, Apr 14, 2015 at 11:38 PM, Linux Luser linuxlu...@gmail.com wrote: I'm not sure if NetworkManager's version is better or worse for your case. My understanding was that it is specifically configured to provide DNS services to the localhost only. I think you should install the regular dnsmasq for your distro if you are using it as a core service for your whole network. On Debian-based systems, for example: $ sudo apt-get install dnsmasq After doing this, my /etc/resolv.conf contains only 127.0.0.1. I did try updating it by running the following command lines: $ sudo dpkg-reconfigure resolvconf And $ sudo resolvconf -u And nothing were able to pull the nameservers from my router now. :/ I had to manually edit it in order to get back access to internet. Why is that? What updates resolv.conf from my router's config? -- Thiago Farina -- daV.e The reasonable man adapts himself to the conditions that surround him... The unreasonable man adapts surrounding conditions to himself... All progress depends on the unreasonable man. Bernard Shaw ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dns server
Ah, yes. You will have to add the host-record=mydomain.com,192.168.0.101 line as we discussed earlier. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dns server
host-record will define a single A record for your local network. For all others, you will need to specify an upstream DNS server. Example: server=8.8.8.8 server=8.8.4.4 expand-host, domain and local should be optional (though, you probably want to specify a domain name for your local network) if we're still just talking about DNS. On Tue, Apr 14, 2015 at 4:57 PM, Thiago Farina tfrans...@gmail.com wrote: On Tue, Apr 14, 2015 at 8:45 PM, Linux Luser linuxlu...@gmail.com wrote: Wouldn't host-record work? host-record=mydomain.org,192.168.0.101 Just that? No expand-host, domain=, local, address are necessary? If the hosts on your network are configured to use your dnsmasq instance for DNS, then they will get back 192.168.0.101 when doing a lookup for mydomain.org. Will they still be able to navigate to any other site (the ones outside my network, i.e., in the internet)? -- Thiago Farina -- daV.e The reasonable man adapts himself to the conditions that surround him... The unreasonable man adapts surrounding conditions to himself... All progress depends on the unreasonable man. Bernard Shaw ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dns server
Are you running dnsmasq through NetworkManager on the server or the client? The version of dnsmasq for NetworkManager is compiled with different options than standard dnsmasq installs (those that come as a package for a distro). If the /etc/dnsmasq.conf file you showed is the one that's on your server, then you need to supply at least one more 'server' option to specify an upstream server for queries that dnsmasq doesn't know the answers to. So, in addition to server=/mydomain.org/192.168.0.101, you need to add: server=8.8.8.8 That will tell dnsmasq to forward queries it doesn't know about upstream. You can have more than one 'server=' line. On Tue, Apr 14, 2015 at 6:25 PM, Thiago Farina tfrans...@gmail.com wrote: On Tue, Apr 14, 2015 at 9:51 PM, Linux Luser linuxlu...@gmail.com wrote: host-record will define a single A record for your local network. For all others, you will need to specify an upstream DNS server. Example: server=8.8.8.8 server=8.8.4.4 expand-host, domain and local should be optional (though, you probably want to specify a domain name for your local network) if we're still just talking about DNS. I'm trying everything, but nothing is working from other machines. Sigh. $ cat /etc/dnsmasq.conf #listen-address=127.0.0.1 domain-needed bogus-priv server=/mydomain.org/192.168.0.101 local=/mydomain.org/ domain=mydomain.org $ ps ax | grep dns 17432 ?S 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus --conf-dir=/etc/NetworkManager/dnsmasq.d So I put mydomain.org.conf in dnsmasq.d $ cat /etc/NetworkManager/dnsmasq.d/mydomain.org.conf server=/mydomain.org/192.168.0.101 Chrome error's code is: DNS_PROBE_FINISHED_BAD_CONFIG -- Thiago Farina -- daV.e The reasonable man adapts himself to the conditions that surround him... The unreasonable man adapts surrounding conditions to himself... All progress depends on the unreasonable man. Bernard Shaw ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dns server
I'm not sure if NetworkManager's version is better or worse for your case. My understanding was that it is specifically configured to provide DNS services to the localhost only. I think you should install the regular dnsmasq for your distro if you are using it as a core service for your whole network. On Debian-based systems, for example: $ sudo apt-get install dnsmasq The /etc/dnsmasq.conf file for Debian contains lots of useful defaults as well as verbose comments above almost every option. On Tue, Apr 14, 2015 at 7:15 PM, Thiago Farina tfrans...@gmail.com wrote: On Tue, Apr 14, 2015 at 10:56 PM, Linux Luser linuxlu...@gmail.com wrote: Are you running dnsmasq through NetworkManager on the server or the client? Yes, I'm running it through NetworkManager on the server. :/ I have this in my NetworkManager.conf: $ cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile dns=dnsmasq no-auto-default=84:2B:2B:7C:96:69, [ifupdown] managed=false Is it better to run it standalone? How can I change this? The version of dnsmasq for NetworkManager is compiled with different options than standard dnsmasq installs (those that come as a package for a distro). If the /etc/dnsmasq.conf file you showed is the one that's on your server, then you need to supply at least one more 'server' option to specify an upstream server for queries that dnsmasq doesn't know the answers to. So, in addition to server=/mydomain.org/192.168.0.101, you need to add: server=8.8.8.8 That will tell dnsmasq to forward queries it doesn't know about upstream. You can have more than one 'server=' line. Right. I will add this line to dnsmasq.conf as well. -- Thiago Farina ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dns server
Wouldn't host-record work? host-record=mydomain.org,192.168.0.101 If the hosts on your network are configured to use your dnsmasq instance for DNS, then they will get back 192.168.0.101 when doing a lookup for mydomain.org. On Tue, Apr 14, 2015 at 4:09 PM, Thiago Farina tfrans...@gmail.com wrote: Hi, First of all, sorry for asking here in this mailing list. I tried to find the answer googling for it, but failed. I didn't find a way to search the archives of this mailing list either, so hence I'm posting here. I hope someone can help me. This was probably asked and answered many times before, so if you have points for it, please send it my way. I'm trying to configure dnsmasq as my dns server in my home network. I have a cisco dpc3825 router (ip 192.168.0.1) that connects to the internet, an Ubuntu server where I want to run dnsmasq on ip 192.168.0.101, and a bunch of other machines in the network. I know how to change the router to point to ubuntu server as a primary dns. That is not the problem. The problem is the configuration of dnsmasq.conf. I have a nginx running and serving a static site on this ubuntu server. What I want is that dnsmasq translate to the other machines in my network when they type mydomain.org to the ip address of my ubuntu server which is running nginx, so they should be able to see my site in my local network. I believe the configuration on the router should be something like: Primary DNS: 192.168.0.101 Secondary DNS: 8.8.8.8 Ternary DNS: 8.8.4.4 But what about dnsmasq.conf? How should I configure it? Currently it has the following content: $ cat /etc/dnsmasq.conf listen-address=127.0.0.1 -- Thiago Farina ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- daV.e The reasonable man adapts himself to the conditions that surround him... The unreasonable man adapts surrounding conditions to himself... All progress depends on the unreasonable man. Bernard Shaw ___ 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
Thanks guys. That gives me some good things to think about and prepare for. On Jul 31, 2014 12:33 PM, Brian Rak b...@gameservers.com wrote: 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 listdnsmasq-disc...@lists.thekelleys.org.ukhttp://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] Estimation of TFTP Server Load Capabilities
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
Re: [Dnsmasq-discuss] Changing tftp-path / file depending on tag?
If I understand you correctly, this configuration is being used on the server with 4 NICs. If so, could you simply supply the addtional *interface* parameter to the tftp-root option? Something like ... tftp-root=/opt/dmi/tftproot/gw94,eth0 tftp-root=/opt/dmi/tftproot/gw95,eth1 tftp-root=/opt/dmi/tftproot/gw96,eth2 tftp-root=/opt/dmi/tftproot/gw97,eth3 Of course, create those directories and add the correct files to each. On Tue, Jul 1, 2014 at 5:47 AM, Oliver Rath r...@mglug.de wrote: Hi list, i have a configuration here with 4 NICs. The config exports different tftp-server addresses (dhcp-Byte 128) for correct resolving: -- snip -- dhcp-range=set:gw94,192.168.94.50,192.168.94.150,255.255.255.0,12h dhcp-range=set:gw95,192.168.95.50,192.168.95.150,255.255.255.0,12h dhcp-range=set:gw96,192.168.96.50,192.168.96.150,255.255.255.0,12h dhcp-range=set:gw97,192.168.97.50,192.168.97.150,255.255.255.0,12h dhcp-option=tag:gw94,128,192.168.94.254 dhcp-option=tag:gw95,128,192.168.95.254 dhcp-option=tag:gw96,128,192.168.96.254 dhcp-option=tag:gw97,128,192.168.97.254 dhcp-boot=undionly.kkkpxe enable-tftp tftp-root=/opt/dmi/tftproot -- snap -- Now i want to offer different undionly.kkkpxe for every subnet. I think on something like dhcp-boot=tag:gw94,undionly-94.kkkpxe dhcp-boot=tag:gw95,undionly-95.kkkpxe dhcp-boot=tag:gw96,undionly-96.kkkpxe dhcp-boot=tag:gw97,undionly-97.kkkpxe Is this possible? Tfh! OLiver ___ 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] converting ISC dhcpd.conf to dnsmasq
Use the set:tagname option in your dhcp-host command. Then use that tag
in it's own dchp-boot command to send a specific boot file to a specific
host.
# PXE response for non-iPXE clients
dhcp-match=set:ipxe,175 # iPXE sends a 175 option
dhcp-boot=tag:!ipxe,ipxe.pxe
# PXE response for host 'mythbed'
dhcp-host=bc:ee:7b:25:3b:15,*set:mythbed*,mythbed
tag-if=set:mythbed-ipxe,tag:ipxe,tag:mythbed
dhcp-boot=mythbed-ipxe,http://minimyth2/conf/mythbed/mythbed.ipxe
# PXE response for host 'mythliv'
dhcp-host=38:60:77:9c:6b:1d,*set:mythliv*,mythliv
tag-if=set:mythliv-ipxe,tag:ipxe,tag:mythliv
dhcp-boot=mythliv-ipxe,http://minimyth2/conf/mythbed/mythliv.ipxe
Using the 'tag-if' command, you can effectively combine two tags into one.
But depending only your case, you might be able to omit this line and
simply send the 'filename' DHCP field (which is what dhcp-boot does) for
every DHCP request, regardless if it is during an iPXE boot or not.
On Mon, May 12, 2014 at 9:45 AM, Michael mich...@kmaclub.com wrote:
Hello,
i am trying to convert my existing isc dhcp service to dnsmasq.
The only issue I am having is with netbooting.
For isc dhcp, I have a few entries like:
host mythbed {
hardware ethernet bc:ee:7b:25:3b:15;
fixed-address mythbed;
if exists user-class and option user-class = iPXE {
#filename http://minimyth/ipxe/mythbed;;
filename http://minimyth2/conf/mythbed/mythbed.ipxe;;
} else{
filename ipxe.pxe;
}
default-lease-time 604800;
max-lease-time 1209600;
}
host mythliv {
hardware ethernet 38:60:77:9c:6b:1d;
fixed-address mythliv;
if exists user-class and option user-class = iPXE {
filename http://minimyth2/conf/mythliv/mythliv.ipxe;;
} else {
filename ipxe.pxe;
}
}
I have been trying to translate this into dnsmasq, but not having much
luck.
Something like this will let one host boot:
dhcp-match=set:ipxe,175 # iPXE sends a 175 option
dhcp-host=bc:ee:7b:25:3b:15,mythbed
dhcp-boot=tag:!ipxe,ipxe.pxe
dhcp-boot=tag:ipxe,http://minimyth2/conf/mythbed/mythbed.ipxe
But adding:
dhcp-host=bc:ee:7b:25:3b:15,mythbed
dhcp-boot=tag:!ipxe,ipxe.pxe
dhcp-boot=tag:ipxe,http://minimyth2/conf/mythbed/mythbed.ipxe
causes the options for the first to get overwritten.
Could someone give me an example of how to only supply pxe options
requested, if it is a certain host/mac, boot ipxe the first time, and then
pass a URL to ipxe on the next request?
I tried using multiple tags but either that isn't allowed or I didn't use
them correctly.
Any help would be much appreciated.
Michael
___
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] Always Ignore Client Identifier
That makes sense. I may just do that. Since /etc/ethers and /etc/dnsmasq-hosts.d would both be reread upon a SIGHUP signal, it seems that there wouldn't be much of a difference either way, other than, as you say, one way is more confusing than another. Thanks again! On Feb 11, 2014 5:36 AM, Simon Kelley si...@thekelleys.org.uk wrote: On 08/02/14 17:42, Linux Luser wrote: dhcp-ignore-clid might just work for the long-term. But I ended up playing around a bit more and I've managed to isolate the part of my config that I believe triggers the problem. Maybe this can be fixed without a dhcp-ignore-clid option? When I set a host's MAC address and IP association in /etc/ethers (with the read-ethers option on of course) and that same host's IP address to hostname association in /etc/hosts, I am able to get a consistent IP, whether or not that same host is using PXE boot, the Debian installer (where it send the vendor-id as d-i, which shouldn't matter in this case) or boots to its own image on the drive. It is consistent, that is, until I implement a trick that I wanted to use so I could whitelist hosts for PXEboot. That's when it got inconsistent and I would end up with a brand new IP address for PXE and usually another brand new one when the host boot into it's own OS. I could only get the IP that I had set in /etc/ethers if I restarted dnsmasq on the server. Otherwise the host would receive the same WRONG IP over and over for each renewal. Here's the config I had BEFORE implementing a PXEboot whitelist: domain-needed bogus-priv log-dhcp domain=mydomain local=/mydomain/ server=8.8.8.8 server=8.8.4.4 interface=eth0 except-interface=eth1 expand-hosts read-ethers dhcp-range=tag:known,set:controller,10.1.0.1,10.1.255.254,2h dhcp-range=tag:known,set:device,10.2.0.1,10.2.255.254,2h dhcp-option=option:router,10.0.0.1 enable-tftp tftp-root=/tftpboot dhcp-boot=pxelinux.0 Now, I'll add the lines which allow me to use a directory of files for dhcp-host commands: dhcp-vendorclass=pxe,PXEClient dhcp-ignore=tag:pxe,tag:!install dhcp-hostsfile=/etc/dnsmasq-hosts.d Inside of /etc/dnsmasq-hosts.d then I can put files that contain lines like this one: 01:02:03:04:05:06,set:install ... and send a SIGHUP to dnsmasq process. After this, the host with that MAC address gets the tag install and instead of ignoring PXEboot, dnsmasq will respond for that host. Wonderful! Problem: now I'm getting wildly different MAC addresses. It's like dnsmasq is reading the files in /etc/dnsmasq-hosts.d and ignoring the /etc/ethers file. Is this expected behavior? A bug? I know that specifying a DIRECTORY instead of a file for the dhcp-hostsfile is kind of a new feature. (For my purposes, I'd prefer a directory because it's possible that several processes might want to write files at the same time. It's easy to avoid concurrency problems by putting files with unique names in a directory (named after MAC or hostname or UUIDs, etc).) My guess is that dnsmasq is failing to integrate the information from /etc/ethers and the dnsmasq-host.d file into a single coherent record. There are various heuristics in the code to do that for common situations, but since there no real primary key, it difficult to do it generally. Do you merge the settings for a MAC address. for and IP address, for a hostname? The simplest solution is probably to abandon /etc/ethers, and put all the information in one place in the files in /etc/dnsmasq-hosts.d It;s fine to keep what you have and add IP addresses and/or hostnames to that. 01:02:03:04:05:06,set:install,1.2.3.4 Cheers, Simon ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Always Ignore Client Identifier
Correction: I'm getting wildly different IP addresses not wildly different MAC addresses. On Sat, Feb 8, 2014 at 9:42 AM, Linux Luser linuxlu...@gmail.com wrote: dhcp-ignore-clid might just work for the long-term. But I ended up playing around a bit more and I've managed to isolate the part of my config that I believe triggers the problem. Maybe this can be fixed without a dhcp-ignore-clid option? When I set a host's MAC address and IP association in /etc/ethers (with the read-ethers option on of course) and that same host's IP address to hostname association in /etc/hosts, I am able to get a consistent IP, whether or not that same host is using PXE boot, the Debian installer (where it send the vendor-id as d-i, which shouldn't matter in this case) or boots to its own image on the drive. It is consistent, that is, until I implement a trick that I wanted to use so I could whitelist hosts for PXEboot. That's when it got inconsistent and I would end up with a brand new IP address for PXE and usually another brand new one when the host boot into it's own OS. I could only get the IP that I had set in /etc/ethers if I restarted dnsmasq on the server. Otherwise the host would receive the same WRONG IP over and over for each renewal. Here's the config I had BEFORE implementing a PXEboot whitelist: domain-needed bogus-priv log-dhcp domain=mydomain local=/mydomain/ server=8.8.8.8 server=8.8.4.4 interface=eth0 except-interface=eth1 expand-hosts read-ethers dhcp-range=tag:known,set:controller,10.1.0.1,10.1.255.254,2h dhcp-range=tag:known,set:device,10.2.0.1,10.2.255.254,2h dhcp-option=option:router,10.0.0.1 enable-tftp tftp-root=/tftpboot dhcp-boot=pxelinux.0 Now, I'll add the lines which allow me to use a directory of files for dhcp-host commands: dhcp-vendorclass=pxe,PXEClient dhcp-ignore=tag:pxe,tag:!install dhcp-hostsfile=/etc/dnsmasq-hosts.d Inside of /etc/dnsmasq-hosts.d then I can put files that contain lines like this one: 01:02:03:04:05:06,set:install ... and send a SIGHUP to dnsmasq process. After this, the host with that MAC address gets the tag install and instead of ignoring PXEboot, dnsmasq will respond for that host. Wonderful! Problem: now I'm getting wildly different MAC addresses. It's like dnsmasq is reading the files in /etc/dnsmasq-hosts.d and ignoring the /etc/ethers file. Is this expected behavior? A bug? I know that specifying a DIRECTORY instead of a file for the dhcp-hostsfile is kind of a new feature. (For my purposes, I'd prefer a directory because it's possible that several processes might want to write files at the same time. It's easy to avoid concurrency problems by putting files with unique names in a directory (named after MAC or hostname or UUIDs, etc).) FYI, I'm using version 2.59 (comes with Debian wheezy). Thanks for any help! On Fri, Jan 31, 2014 at 1:48 PM, Simon Kelley si...@thekelleys.org.ukwrote: On 31/01/14 16:25, Linux Luser wrote: dhcp-ignore-names is concerned about the hostname, correct? I am interested in the client identifier option sent in the DHCPREQUEST. Ignoring this field would break RCF2131 (and probably some people's networks!) but in my particular case, it may spare me some problems. I understand, I'm proposing a new option, dhcp-ignore-clid, analogous to the existing dhcp-ignore-names. Maybe if I could selectively revoke leases, that would work. Could I do this? I'm sure that dnsmasq keeps an internal cache, so that would have to be flushed for a particular lease. There is a utility in contrib/wrt in the source distribution, and a binary in the Debiann package of dnsmasq, for releasing a specific lease from the command-line. On Jan 30, 2014 2:08 AM, Simon Kelley si...@thekelleys.org.uk mailto:si...@thekelleys.org.uk wrote: On 29/01/14 18:04, Linux Luser wrote: We have a pretty tightly-controlled private network environment which we've configured to have a 1-to-1-to-1 relationship between client MAC address, hostnames and IP addresses. Apart from guest IP ranges, we have control over when clients get added to the network. Thus, we can detect duplicate MAC addresses before it becomes an issue. In this setup, we can't need or want to use the client identifier option of DHCP. In fact, it becomes a problem when we start doing PXELinux installs, where a different client id gets sets during a remote install session, then when the install is complete and the new OS boots up, it gets a different IP address (because dnsmasq still knows about the lease it gave that same machine only 10 minutes ago!). To get rid of this issue, we now supply a dhcp-host option to dnsmasq each time we want to do a remote reinstall. The option looks something like
Re: [Dnsmasq-discuss] Always Ignore Client Identifier
dhcp-ignore-names is concerned about the hostname, correct? I am interested in the client identifier option sent in the DHCPREQUEST. Ignoring this field would break RCF2131 (and probably some people's networks!) but in my particular case, it may spare me some problems. Maybe if I could selectively revoke leases, that would work. Could I do this? I'm sure that dnsmasq keeps an internal cache, so that would have to be flushed for a particular lease. On Jan 30, 2014 2:08 AM, Simon Kelley si...@thekelleys.org.uk wrote: On 29/01/14 18:04, Linux Luser wrote: We have a pretty tightly-controlled private network environment which we've configured to have a 1-to-1-to-1 relationship between client MAC address, hostnames and IP addresses. Apart from guest IP ranges, we have control over when clients get added to the network. Thus, we can detect duplicate MAC addresses before it becomes an issue. In this setup, we can't need or want to use the client identifier option of DHCP. In fact, it becomes a problem when we start doing PXELinux installs, where a different client id gets sets during a remote install session, then when the install is complete and the new OS boots up, it gets a different IP address (because dnsmasq still knows about the lease it gave that same machine only 10 minutes ago!). To get rid of this issue, we now supply a dhcp-host option to dnsmasq each time we want to do a remote reinstall. The option looks something like this: dhcp-host=MAC addr,id:*,hostname,IP addr,set:install This works, since the id:* part tells dnsmasq to ignore the client ID in favor of the MAC address. But now to my question. Can this be done for ALL DHCP requests? Is there a global identify-by-mac-only option? If not, would you be willing to entertain the idea. I know many others have done this for some time now, using other DHCP server software, so I know it's possible and there doesn't seem to be any ill effects of this.# There isn't a global option to do this, but there is precedent, in the form of --dhcp-ignore-names for adding it, and actually that's something more useful, since the tag system allows the setting to be applied to classes of clients (which could, of course, be all clients) Maybe this is not a good idea? Like I said, we have a fairly controlled environment, so it would work for us. I could see how this would be unnecessary for common setups, though. Or environments that have many VMs running on a single host and simply bridge their network interface may want to use the client identifier option so each VM gets a unique IP even if they're running on the same machine or t But it would be nice to have a greater level of control over this. Thanks for your time. And GREAT piece of software, by the way. dnsmasq is a HUGE time saver and makes changing configurations straight-forward. Do you accept donations? :) Donations by Paypal to si...@thekelleys.org.uk are always welcome, or you could commission me to add new features. I'm available for that on a consultancy basis, cheaper for stuff which goes back into the dnsmasq GPL codebase, more expensive for proprietary code. Cheers, Simon. -- daV.e ___ 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] Always Ignore Client Identifier
We have a pretty tightly-controlled private network environment which we've configured to have a 1-to-1-to-1 relationship between client MAC address, hostnames and IP addresses. Apart from guest IP ranges, we have control over when clients get added to the network. Thus, we can detect duplicate MAC addresses before it becomes an issue. In this setup, we can't need or want to use the client identifier option of DHCP. In fact, it becomes a problem when we start doing PXELinux installs, where a different client id gets sets during a remote install session, then when the install is complete and the new OS boots up, it gets a different IP address (because dnsmasq still knows about the lease it gave that same machine only 10 minutes ago!). To get rid of this issue, we now supply a dhcp-host option to dnsmasq each time we want to do a remote reinstall. The option looks something like this: dhcp-host=MAC addr,id:*,hostname,IP addr,set:install This works, since the id:* part tells dnsmasq to ignore the client ID in favor of the MAC address. But now to my question. Can this be done for ALL DHCP requests? Is there a global identify-by-mac-only option? If not, would you be willing to entertain the idea. I know many others have done this for some time now, using other DHCP server software, so I know it's possible and there doesn't seem to be any ill effects of this. Maybe this is not a good idea? Like I said, we have a fairly controlled environment, so it would work for us. I could see how this would be unnecessary for common setups, though. Or environments that have many VMs running on a single host and simply bridge their network interface may want to use the client identifier option so each VM gets a unique IP even if they're running on the same machine. But it would be nice to have a greater level of control over this. Thanks for your time. And GREAT piece of software, by the way. dnsmasq is a HUGE time saver and makes changing configurations straight-forward. Do you accept donations? :) -- daV.e ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
