Re: [Dnsmasq-discuss] How does DNSMASQ handle large concurrent configure file updating request requests
On Sun, Feb 15, 2015 at 4:11 AM, Simon Kelley si...@thekelleys.org.uk wrote: Got it. Do you have --no-hosts set? That would explain why it was working for me and not for you. I just pushed the fix to git. Your guessing is completely right! I am using no-hosts in dnsmasq.conf. Now the new codes work greatly in my environment. But another issue I found is, the IP binding can't be really released even after remove the config files and manually call dhcp_release. So when I create another VM with the same IP address, it will report duplication. dnsmasq.log is something like: --- Feb 15 06:12:45 dnsmasq-dhcp[3521]: DHCPRELEASE(eth2) 10.11.0.3 fa:e1:51:0b:a5:00 ... Feb 15 06:13:13 dnsmasq[3521]: inotify, new or changed file /etc/hosts.dhcps//fa:e9:4a:40:7f:00 Feb 15 06:13:13 dnsmasq-dhcp[3521]: read /etc/hosts.dhcps//fa:e9:4a:40:7f:00 Feb 15 06:13:13 dnsmasq[3521]: duplicate dhcp-host IP address 10.11.0.3 at line 1 of /etc/hosts.dhcps//fa:e9:4a:40:7f:00 Feb 15 06:13:23 dnsmasq-dhcp[3521]: DHCPDISCOVER(eth2) fa:e9:4a:40:7f:00 no address available Feb 15 06:13:26 dnsmasq-dhcp[3521]: DHCPDISCOVER(eth2) fa:e9:4a:40:7f:00 no address available --- Anything wrong? -- Yongkang You ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] proxyDHCP + EFI PXE?
Thanks Simon. I will send you the packet captures within the next 24 hours. I realize that this is currently a niche feature, but I would expect it to become more common in the near future as things move towards EFI. Looking through the mailing list, I found this post from last year indicating the same issue: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q1/008182.html There have been no changes to this code since 2.71, so upgrading won't save you. I have no idea if this has ever worked. I've certainly never tested it, and it wouldn't surprise me if no-one has made it work: it's pretty niche. I don't, AFAIK, have any suitable hardware to test this, but you may be in a perfect position to do what I'd do next, which is to compare the PXE packet that WDS sends, and which works, with the one the dnsmasq sends, and is ignored. On a good day, that will give us one, obvious, difference and an easy fix :-) Could you post complete packet captures suitable for loading into Wireshark, or send them directly to me if you prefer? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Option log-queries=extra complains about extraneous parameter
Hi. Trying to use the new extra logging results in a failed startup and a syslog message saying the configuration has an extraneous parameter. Ist this a bug or am I missing something obvious? Sincerely, Joachim ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnssec-no-timecheck enhancement idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/02/15 12:01, Kevin Darbyshire-Bryant wrote: The principle I agree with. I'm wondering about the mechanics of accessing this NVRAM 'last good time'. Is this something you're thinking that dnsmasq should access maintain, in which case a file stored in a non-volatile filesystem would be the most cross-platform method. Or are you thinking the device OS should write a parameter into dnsmasq's config file at start (as I've cobbled together) ? I have to say that I'd quite like dnsmasq to handle all the timestamp related stuff so dnssec could simply be a case of throwing a switch and everything is handled automagically. That might encourage home router manufacturers to include enable by default. But what do I know!? I'm not a fan of the 'proxy for now' idea for exactly the reasons you describe. I think it better to wait for 'now' to really be after 'last good time', the implication is that NTP has done its stuff sync'd the clock. I would hope that NTP would be early on in the startup process so the exploit window narrow. If the device will always have NVRAM available in the form of a filesystem, then using a time stamp on that is the obvious way to go. The only disadvantage I can see is that some devices may have NVRAM, but not be able to use it to store a filesystem. I don't have the knowledge to be able to have a strong opinion on that. Assuming we have a fileysystem, then the following algorithm would seem to work. On startup, if the timestamp on a NVRAM file is in the future, disable time checking for DNSSEC. The first time the timestamp goes into the past, enable timestamp checking henceforward, and reset the timestamp on the file to now That leaves only the case where at startup, the file doesn't exist. I think creating it and setting its mtime to 01-01-2015, then running the rest of the algorithm, will probably do in that case. Extending dnssec-no-timecheck, to take a pathname to enable this mode seems a reasonable idea. So - --dnssec-no-timecheck works as before, with SIGHUP - --dnssec-no-timecheck=/path/to/nvfilesystem invokes the new behaviour. How's that sound? Cheers, Simon. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU32AYAAoJEBXN2mrhkTWi8VkQAImoX1tf0utktpqG7FIzFpI5 YyqGseTFw+4PreofAatDTgKdpgqFPACUYfqoj+56Xbk2u4jUFoxfeUrSLQwQ9C75 eXbvWynhul1omVZjB96yXDkpysxQ5yhajLk7cgmIYpX6HBOtng3TiAfUGRqUa7ny qTxo6Ap0Al3RKsilZCBTcw3/G5yJg/rQuQGsuL/66nLW/au5sORw2AP/K4EbRAID Iw4jjfAWc3I7TgPEc2AX6nxiaA0+B2Kl7Tw6VUnmjsEwAjhjNgIKEeDrlgwXxxih CvnnHT/GSA6Dxa7rqrhzZ3B5AQzfsrIxhZTqwU/hkibspBWwye/P1thLWV67pmlc /EKHQsRydqlCZL43Ji1hRVJlnycU26AzePi+u0EgdJ/ayt4hwZC78jiKRfGFrh4b 5BAR07qjO14ZlVmCUYeaS3eAi4OYtk017Pbosdhc6V5CsSn0rIyKJw4Ir2gfyFSl UvVbTFiSST0pp2cKJjYRZrgf/LfoGW/7Is21DcAZMn9LLGq8TTWt8ImA+cQWGg3f ItQqsgrKI/8J18ThcAJvZM2UyW119hSEy7iIpsaw1h2mB961X+q6GeW7tx47AuVy 9MpBfjNaS2LTaOClOceEFCLCtLpIlYL8WwnTnU+C4cVXp6dRyO/4B9SrSY2vD50i 3rPLTS626d2Zq0MnVYfk =96X2 -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] log-queries=extra - Ignore my previous mail
I just found I actually was stupid. Sincerely, Joachim ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] proxyDHCP + EFI PXE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/02/15 06:04, Greg C wrote: Has anybody been able to pxeboot an EFI system using Dnsmasq in proxyDHCP mode? Every machine I have tried fails to boot (mostly newer Dells with Intel cards). The relevant lines from from my config file are here: pxe-service=x86-64_EFI,Loading...,snponly dhcp-range=192.168.0.0,proxy,255.255.0.0 Watching the traffic with wireshark I can see the proxy response get sent containing my 'menu' encapsulated in option 43 with the correct boot file name. Still, the client never seems acknowledge the boot info, either by showing an error or attempting to boot. It just times out after ~60 seconds and boots to the next device. If I reboot using 'Legacy PXE', everything works perfectly (I have a line for x86PC as well). If I switch from proxy to full DHCP I can boot in EFI mode without issue. I am running Dnsmasq version 2.71 on Ubuntu if that matters. Am I doing something wrong, or does proxyDHCP not work with EFI systems yet? These same machines can boot to Windows Deployment Services in proxyDHCP mode, so I am sure EFI PXE is capable of booting this way. Thanks. There have been no changes to this code since 2.71, so upgrading won't save you. I have no idea if this has ever worked. I've certainly never tested it, and it wouldn't surprise me if no-one has made it work: it's pretty niche. I don't, AFAIK, have any suitable hardware to test this, but you may be in a perfect position to do what I'd do next, which is to compare the PXE packet that WDS sends, and which works, with the one the dnsmasq sends, and is ignored. On a good day, that will give us one, obvious, difference and an easy fix :-) Could you post complete packet captures suitable for loading into Wireshark, or send them directly to me if you prefer? Cheers, Simon. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU32ICAAoJEBXN2mrhkTWi8xgP/0G4Snl7qCDIJfYR3REMwHHn TOU/KtBDegVE5zoqEJGS2s1tyIpqli4oH875smVztQ6owQjurfIOS7AA2k/wDCl9 OrQ3b0S1oIYXXTXngNJnliqPbn/Ue9JmirbDkculq13/hzw2a3H0qOdEV0nTtFfb o81xNYX4Hy++M1aGSlUhF0eZ2uDtmG7eNXZ0Efr3XbsLiX+7HKDu7WWWu2lnr1G6 VfHPBQ8K0uqXq9Un6fd/fm5hxtK20dC0+gu4KyAN4kxxjP30f3x4g+uUGB6cEYSy h7J7hvGoPbfetOOCd9yrERS1yt1/XDQWAR7gug775pHIoKnbHCamR3VUDhXqNagJ BVSNCPXZi7LbGDdZ95zKjSuZc1u1/tFzHFt+/67cyqzuksszm7+V+1viejDpl7PM MKid9y8YQJndjL6yS/usQwqBgD5F2bqtd+ks7KBnp9qGxO4FN6OcKsXujQGluZ1z N4wKIrXnDZT8ERZbwrSbI8atE/LiTIJ+V65onh+7vJvxYsD1S6VZmsek+hPqES41 jvix8lZttc9tR+SPI84WUWZ3v09EsM01KMkZv+L0+Ek15Fcimapaw0jKuUEtRRa9 wtnBGW4j6dFjzvtyBl/jYKpnnLUm4dfkcMxPng9QmrEFp2JNjGEhTCX7i0Rt7NKo GXAW05axbGooIVSg6yCn =iW5b -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] dnssec-no-timecheck enhancement idea
On 14 Feb 2015, at 14:47, Simon Kelley si...@thekelleys.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/02/15 12:01, Kevin Darbyshire-Bryant wrote: The principle I agree with. I'm wondering about the mechanics of accessing this NVRAM 'last good time'. Is this something you're thinking that dnsmasq should access maintain, in which case a file stored in a non-volatile filesystem would be the most cross-platform method. Or are you thinking the device OS should write a parameter into dnsmasq's config file at start (as I've cobbled together) ? I have to say that I'd quite like dnsmasq to handle all the timestamp related stuff so dnssec could simply be a case of throwing a switch and everything is handled automagically. That might encourage home router manufacturers to include enable by default. But what do I know!? I'm not a fan of the 'proxy for now' idea for exactly the reasons you describe. I think it better to wait for 'now' to really be after 'last good time', the implication is that NTP has done its stuff sync'd the clock. I would hope that NTP would be early on in the startup process so the exploit window narrow. If the device will always have NVRAM available in the form of a filesystem, then using a time stamp on that is the obvious way to go. The only disadvantage I can see is that some devices may have NVRAM, but not be able to use it to store a filesystem. I don't have the knowledge to be able to have a strong opinion on that. I don't really have that knowledge either, I've experience with Broadcom router platforms running the likes of Tomato and/or Asuswrt. These have had jffs filesystems from very early days (and I've not yet encountered a situation where the NVRAM has worn out either). Assuming we have a fileysystem, then the following algorithm would seem to work. On startup, if the timestamp on a NVRAM file is in the future, disable time checking for DNSSEC. The first time the timestamp goes into the past, enable timestamp checking henceforward, and reset the timestamp on the file to now That leaves only the case where at startup, the file doesn't exist. I think creating it and setting its mtime to 01-01-2015, then running the rest of the algorithm, will probably do in that case. Extending dnssec-no-timecheck, to take a pathname to enable this mode seems a reasonable idea. Sounds excellent. Is it worth being really clever and setting the default time to build time rather than 01-01-2015? As a further wear protection effort, only update mtime on the existing file if the difference exceeds 1 day? This would limit the amount of writes on process start (Asuswrt restarts dnsmasq for the most bizarre reasons) So - --dnssec-no-timecheck works as before, with SIGHUP - --dnssec-no-timecheck=/path/to/nvfilesystem invokes the new behaviour. How's that sound? Really good! And really appreciate your time consideration of this. Kevin Cheers, Simon. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU32AYAAoJEBXN2mrhkTWi8VkQAImoX1tf0utktpqG7FIzFpI5 YyqGseTFw+4PreofAatDTgKdpgqFPACUYfqoj+56Xbk2u4jUFoxfeUrSLQwQ9C75 eXbvWynhul1omVZjB96yXDkpysxQ5yhajLk7cgmIYpX6HBOtng3TiAfUGRqUa7ny qTxo6Ap0Al3RKsilZCBTcw3/G5yJg/rQuQGsuL/66nLW/au5sORw2AP/K4EbRAID Iw4jjfAWc3I7TgPEc2AX6nxiaA0+B2Kl7Tw6VUnmjsEwAjhjNgIKEeDrlgwXxxih CvnnHT/GSA6Dxa7rqrhzZ3B5AQzfsrIxhZTqwU/hkibspBWwye/P1thLWV67pmlc /EKHQsRydqlCZL43Ji1hRVJlnycU26AzePi+u0EgdJ/ayt4hwZC78jiKRfGFrh4b 5BAR07qjO14ZlVmCUYeaS3eAi4OYtk017Pbosdhc6V5CsSn0rIyKJw4Ir2gfyFSl UvVbTFiSST0pp2cKJjYRZrgf/LfoGW/7Is21DcAZMn9LLGq8TTWt8ImA+cQWGg3f ItQqsgrKI/8J18ThcAJvZM2UyW119hSEy7iIpsaw1h2mB961X+q6GeW7tx47AuVy 9MpBfjNaS2LTaOClOceEFCLCtLpIlYL8WwnTnU+C4cVXp6dRyO/4B9SrSY2vD50i 3rPLTS626d2Zq0MnVYfk =96X2 -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What if external DNS unreachable or timed out
Thank you. Well it looks like dnsmasq does not cache. When I send SIGUSR1 to dnsmasq (with log-queries option enabled) it returns list of cache which consists of one entry - 127.0.0.1 (flags 4FRI H). This is despite the fact that I performed dozen of queries just before. Log file looks like: query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 10.0.0.1 is my internal DNS server (it is authoritative for domain domain) Is there known list of issues which can force dnsmasq not to cache replies? Otherwise I have no idea where to dig. - Original Message - From: /dev/rob0 r...@gmx.co.uk To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Thursday, February 12, 2015 10:13:40 PM GMT -05:00 US/Canada Eastern Subject: Re: [Dnsmasq-discuss] What if external DNS unreachable or timed out On Thu, Feb 12, 2015 at 08:43:20PM -0500, Nikolay P wrote: I am wondering what will happen if none of the external DNS servers are reachable or suddenly (for any reason) a DNS query to external servers timed out. Will Dnsmasq reply to the client's request from cache? Assume that this particular query is performed frequently and it should be in Dnsmasq cache. If the record is cached, dnsmasq is not going to ask an upstream nameserver. If a query is made to an upstream nameserver, that means the record is NOT in the cache. Then if the upstream query times out or otherwise fails, that's what dnsmasq will tell the client. So, will the Dnsmasq reply to the client's request from cache if none of the external servers replied? No, it wasn't cached. -- 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] What if external DNS unreachable or timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/02/15 20:00, Nikolay P wrote: Thank you. Well it looks like dnsmasq does not cache. When I send SIGUSR1 to dnsmasq (with log-queries option enabled) it returns list of cache which consists of one entry - 127.0.0.1 (flags 4FRI H). This is despite the fact that I performed dozen of queries just before. Log file looks like: query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 10.0.0.1 is my internal DNS server (it is authoritative for domain domain) Is there known list of issues which can force dnsmasq not to cache replies? Otherwise I have no idea where to dig. If the time-to-live value in the replies for host.domain is zero or only a few seconds, then the reply will either not be cached, or thrown out before you get around to re-querying it. Use dig to make the test queries, and it will tell you the TTL values. (It's also possible to disable caching in dnsmasq by configuration. You're unlikely to have done that by accident) Cheers, Simon. - Original Message - From: /dev/rob0 r...@gmx.co.uk To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Thursday, February 12, 2015 10:13:40 PM GMT -05:00 US/Canada Eastern Subject: Re: [Dnsmasq-discuss] What if external DNS unreachable or timed out On Thu, Feb 12, 2015 at 08:43:20PM -0500, Nikolay P wrote: I am wondering what will happen if none of the external DNS servers are reachable or suddenly (for any reason) a DNS query to external servers timed out. Will Dnsmasq reply to the client's request from cache? Assume that this particular query is performed frequently and it should be in Dnsmasq cache. If the record is cached, dnsmasq is not going to ask an upstream nameserver. If a query is made to an upstream nameserver, that means the record is NOT in the cache. Then if the upstream query times out or otherwise fails, that's what dnsmasq will tell the client. So, will the Dnsmasq reply to the client's request from cache if none of the external servers replied? No, it wasn't cached. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU391GAAoJEBXN2mrhkTWiMQYP/Anapo7LXImykuh7EdzkVYlj Fa7LrmR9aEpI6S0mhPDd3zx37BUquT9xTIhhXSzOwVWuR/eCf8pJx3vq8PHhaQiw OnvMS9jPXk2fLUFEoB8QEs022nKaKokrJMUMnpGN8GkhPSpge4oZcWJCd122lKHm 5HcJvGiMo9OEs4w8eVpt1rcOVWyjBYh4N7XUhCiKDkAAW3mgwxOaaVjfZNVbDDKN arPYWEpUpGs1F8r6l3LWhP0gTzaiBkqCd/L8+PQ8Yl8nMY17Ugh8l/NcYaH0iQ11 BRUJwLCcG2gCgKWVHH8YnXVqv/hESE8zdD/DVe8NJcLzMAV45GCvp951COgJazJg h/xg+T/N4CIN/BDUGrK4GMr7s7eptbfYzYV2VcvNZhqMlPSHY1mcfxlEMdBSGmKS SuJFxqlCzW4/i9EoyPGT7uhSCkjmYOG+SwMqa3GMQAKBdEXe94hTtCV/sHuuD1Ln T6R5r5vkBWVhUX3V8/BwoTSI/jDzqJUNGVNGCfO8McphjzbrX8GwMMtt3d2z+oZK D425KiCSagv44z/rFdijlIIjApbuIFzoalsuPfBBXgVetS1DL1k0ounAxCYPJxSx qdfA+y6ViIskIn1CD6JdfitOOqBX9JeW5M1ehn8ozr/WxDUFF3BYU5qGL+p1RUfL 3zr7pYGjwESyS4G1GRhY =wpl0 -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
