[Dnsmasq-discuss] New DNSSEC test release.
I've just tagged 2.69test8, which has some significant fixes to the DNSSEC code. One thing to note: I've also completely changed the way the trust anchors are specified, from DNSKEYS to DS records. If you're using the trust-anchors.conf file I supply, this should be transparent, but if you explicitly configured them, you'll need to change that configuration before the new binary will start succesfully. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] I love this little gem !
On 09/02/14 00:34, Elsie Buck wrote: I just ran across http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q1/008009.html which is exactly what I want to do at my home. Why you ask? Well, I have 5 computers (one for each room), 2 file servers, 2 media players and 2 laptops. Not real impressive, but DNSMasq setup correctly, blocks banner ads and bad sites (yeah I get the lists from a couple of places - it's all automatic to me). so the bad sites get sent to my own web server which basically says Oops, you didn't intend to be here. Which is ok. I know what it means and why I ended up there. I'm the only one who counts. What I don't want is the boring site not found (NXDomain). I thought I knew where that page was generated from within windows, but I cannot remember and Google just isn't helping. So I thought, how about DNSMasq? But the above link explains why not. I'm running DNSMasq on a DNS-323 file server. I believe I've found other programs that might do something close to what I want, but I don't know those programs and would rather stay with the tried and true. I thought if enough people requested this feature, you might reconsider... It's really not a good idea: this is probably the definitive paper on why not: http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09-en.pdf Did I tell you, I love this little gem? dhcp is fantastic. I have 10 devices that can be configured simply with DNSMasq. How cool is that? Glad you like it! 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] New DNSSEC test release.
One thing to note: I've also completely changed the way the trust anchors are specified, from DNSKEYS to DS records. Very nice and, yes, it works. :) All that's left is to find a way to obtain those securely when dnsmasq starts up, somewhat in the way unbound-anchor(1) from Unbound does. -JP ___ 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
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] New DNSSEC test release.
On 11/02/14 12:10, Jan-Piet Mens wrote: One thing to note: I've also completely changed the way the trust anchors are specified, from DNSKEYS to DS records. Very nice and, yes, it works. :) All that's left I wish, I wish. NSEC3 is still lurking. is to find a way to obtain those securely when dnsmasq starts up, somewhat in the way unbound-anchor(1) from Unbound does. Is unbound-anchor fairly stand-alone? Maybe run unbound-anchor and then covert the format of the resulting trust-anchors file would be a viable solution? Simon. -JP ___ 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] New DNSSEC test release.
Is unbound-anchor fairly stand-alone? Maybe run unbound-anchor and then covert the format of the resulting trust-anchors file would be a viable solution? Fairly, yes, but: if people can run unbound-anchor they have Unbound, so what would be the point of dnsmasq as a validator? ;-) -JP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] What IP to use for ad/track blocking?
I have a few entries in my dnsmasq.conf file to block some tracking sites, as follows:- address=/www.addthis.com/127.0.0.1 address=/googlesyndication.com/127.0.0.1 address=/google-analytics.com/127.0.0.1 address=/googleadservices.com/127.0.0.1 address=/doubleclick.net/127.0.0.1 address=/finder.cox.net/127.0.0.1 However this means that my web server gets the hits instead if the requests are HTTP ones. I.e. if I enter www.addthis.com into the Firefox address it takes me to my local web server's root page. Is there any IP I can put there which will prevent this - i.e. which is a sort of 'do nothing' IP? I've tried 0.0.0.0 but that takes me to the local page in exactly the same way as 127.0.0.1. -- Chris Green ___ 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
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
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] 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] cname ghs.googlehosted.com.. possible?
On 11/02/14 22:21, B. Cook wrote: It seems that as of 2.68 the proper way to do a cname entry is to have the entry in the format of: (man page..) cname=cname,target Is would seem that a target of ghs.googlehosted.com could not be properly satisfied at this time. From the man page There are significant limitations on the target; it must be a DNS name which is known to dnsmasq from /etc/hosts (or additional hosts files), from DHCP, from --interface-name or from another --cname. If the target does not satisfy this cri‐ teria, the whole cname is ignored. So, not possible, sorry. Simon. The only option seems to be to pick one (A) IP address for ghs.googlehosted.com (e.x. 74.125.22.121) .. Which is guaranteed good only for the 300 seconds that Google published it for .. right? (related to google apps for education..) Thanks in advance ___ 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] What IP to use for ad/track blocking?
I haven't tried it, but maybe 127.0.0.2 will do the trick. On Feb 11, 2014 4:40 PM, Chris Green c...@isbd.net wrote: I have a few entries in my dnsmasq.conf file to block some tracking sites, as follows:- address=/www.addthis.com/127.0.0.1 address=/googlesyndication.com/127.0.0.1 address=/google-analytics.com/127.0.0.1 address=/googleadservices.com/127.0.0.1 address=/doubleclick.net/127.0.0.1 address=/finder.cox.net/127.0.0.1 However this means that my web server gets the hits instead if the requests are HTTP ones. I.e. if I enter www.addthis.com into the Firefox address it takes me to my local web server's root page. Is there any IP I can put there which will prevent this - i.e. which is a sort of 'do nothing' IP? I've tried 0.0.0.0 but that takes me to the local page in exactly the same way as 127.0.0.1. -- Chris Green ___ 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
