[Dnsmasq-discuss] dnsmasq v2.86?
Hey Simon, various dnsmasq-2.86 test tags are around and it doesn't look like there are any intermediate bugs around. The Pi-hole beta seems to have attracted at least a few couple of dozen additional testers and nothing seems to have come up here, either. How do you feel about tagging a v2.86 release? Best regards, Dominik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Please support IPv6 on 'alias=' settings
On 04/08/2021 15:05, Petr Menšík wrote: > Hi, > > how does this help to block something? If responses are dnssec signed, > changing replies would make verification failing. > > What is the point of blocking base on IP level in DNS? If you want > blocking target addresses, why just firewall is not used at the router? > What is advantage of using DNS instead? > > It can block any name by using --address=/blockedname/::1. No similar > thing is possible based on resolved address, but when would it be > needed? Is there reason why firewall would not be more efficient way to > block IP (range)? > > Cheers, > All good points, but on the other hand, if we support this for IPv4, there's no reason not to do it for IPv6 also. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 10/08/2021 14:53, Dominik wrote: > Hey Simon, > > various dnsmasq-2.86 test tags are around and it doesn't look like > there are any intermediate bugs around. The Pi-hole beta seems to have > attracted at least a few couple of dozen additional testers and nothing > seems to have come up here, either. > > How do you feel about tagging a v2.86 release? > > Best regards, > Dominik > > I've been accumulating patches for a couple of weeks, and started working through those tonight. None are very intrusive or controversial. Once those are done, I'll tag rc1. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] feature: dictionary order import of addn-hosts dirs?
On 08/08/2021 15:05, Kevin Darbyshire-Bryant wrote: > > >> On 8 Aug 2021, at 14:54, Ed W wrote: >> >> >> Quoting from https://www.dictionary.com/browse/condescending >> >> "To be condescending is to interact with others in a way that implies that >> you’re superior to them. >> It especially refers to when this is done in an arrogant or patronizing way" >> >> ..."Being condescending often involves not only what is said, but also how >> it’s said. A >> condescending tone is often one that sounds like it’s directed at a child.” > >> >> >> I notice you like to offer snippy responses quite regularly on this mailing >> list. Can I recommend >> you read a few articles such as: >> >> >> https://compassionatecoding.com/blog/2016/8/25/tech-has-a-toxic-tone-problemlets-fix-it >> >> >> I would remind you that I have generally been happy to pay for my feature >> requests. Please don't >> feel encouraged for you to offer development time though, I don't feel that >> I wish to employ you. > > I’m tired of Geert too and I’ve run out of patience. I don’t care if I get > banned from the list for this and it’s probably the reaction that he wants > but it’s not my loss if I get kicked. > > Fuck off Geert. You’re a pain in the arse. And yet more tricks with your > “monthly posting”, complete with spelling errors. > > Cheers, > > Kevin D-B > Whilst I may not endorse the language, I do understand the sentiment. I don't feel the need to ban _anybody_ from this list, but Geert, please take account of what your fellow list members are saying. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] inet_addr and inet_aton replacement
On 09/08/2021 15:14, Petr Menšík wrote: > Hi, > > some of our internal checking tools emit errors when the code is using > outdated function with IPv4 only support. Because IPv6 build-time > support is now required, I think using instead inet_pton would be better. > > The first attached patch replaces inet_addr with proper error reporting > function. I think this is without issues. > > The second patch replaces inet_ntoa function with similar ntop. It > contains more changes, because more recent function does not use > internal hidden buffer but requires using external. I think > daemon->addrbuff is used for this case usually. It brings more lines of > code. It should also require more strict IP address format. Instead of > "10.0", full "10.0.0.0" is required. It might refuse some weird > configuration files. I think it is more correct. > > Altough I have feeling some parts should be merged. For example > log_packet from src/rfc2131.c is quite similar to log6_packet from > src/rfc3315.c. They differ in address family handled and different > function signatures. Only IPv4 variant forwards log to UBUS, I expect > that is not intentional difference. I expect differences between > protocols should be as minimal as possible. > > What do you think, do those changes make sense? > I think if I'd been doing this, I might have provided our_inet_ntoa() which just wrapped inet_ntop() and declared a static buffer, but this is better, if more work. I moved the allocation of daemon->addrbuff into read_opts() so that is can be used in the option code rather than the 127.127.127.127 local variable, and deleted the commented out line about UBus. That call to UBus is likely to go anyway. Patches applied otherwise as-is. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] feature: dictionary order import of addn-hosts dirs?
On 08/08/2021 14:02, Ed W wrote: > > On 19/07/2021 18:52, Ed W wrote: >> Hi, around 2.82 someone posted a little patch to import the config files in >> dictionary order, which >> is very useful for situations where you have overlapping definitions. I'm >> using an addn-hosts stanza >> pointing to a directory and files currently import in a somewhat random >> order (suppose inode >> order?), which can lead to unexpected reverse host definitions in some cases >> >> Could we have a dictionary order import for add-hosts files please? >> >> Ed W > > > Hi, I have developed the attached patch without really being sure that this > is the best approach. I > would be grateful for some feedback. I have used scandir without > understanding if this is portable > across systems that we support with dnsmasq. Also I am trying to copy the > existing coding style, but > surely I have failed. > I'll look in more detail soon, but this certainly looks like the right way to go. > I'm also unclear that it still works as advertised in the case that I don't > have inotify enabled? > Any help? Since the whole point of the inotify stuff is that individual files get read as they change, imposing or relying on a particular order doesn't make much sense. I'd therefore not make any changes to inotify.c. The man page then needs to note that --dhcp-hostsdir --dhcp-optsdir and --hostsdir DON'T offer any ordering of files read, but --dhcp-hostsfile --dhcp-optsfile and --addn-hosts with directory arguments DO. > > The intent is that I have a few aliases for my local system name. However, > the reverse name depends > on the order that the addn-hosts files are read. In any case predictable > dictionary order seems like > a nice thing to have for all config files Seems sensible. Simon. > > Thanks > > > Ed W > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] feature: dictionary order import of addn-hosts dirs?
On 10/08/2021 23:12, Simon Kelley wrote: > On 08/08/2021 14:02, Ed W wrote: >> On 19/07/2021 18:52, Ed W wrote: >>> Hi, around 2.82 someone posted a little patch to import the config files in >>> dictionary order, which >>> is very useful for situations where you have overlapping definitions. I'm >>> using an addn-hosts stanza >>> pointing to a directory and files currently import in a somewhat random >>> order (suppose inode >>> order?), which can lead to unexpected reverse host definitions in some cases >>> >>> Could we have a dictionary order import for add-hosts files please? >>> >>> Ed W >> >> Hi, I have developed the attached patch without really being sure that this >> is the best approach. I >> would be grateful for some feedback. I have used scandir without >> understanding if this is portable >> across systems that we support with dnsmasq. Also I am trying to copy the >> existing coding style, but >> surely I have failed. >> > I'll look in more detail soon, but this certainly looks like the right > way to go. > >> I'm also unclear that it still works as advertised in the case that I don't >> have inotify enabled? >> Any help? > Since the whole point of the inotify stuff is that individual files get > read as they change, imposing or relying on a particular order doesn't > make much sense. I'd therefore not make any changes to inotify.c. > > The man page then needs to note that --dhcp-hostsdir --dhcp-optsdir and > --hostsdir DON'T offer any ordering of files read, but > --dhcp-hostsfile --dhcp-optsfile and --addn-hosts with directory > arguments DO. Aha, then I might have gone off the rails here then... It's the changes in inotify.c which affect my --addn-hosts directives? I left the top part of the patch to option.c in there as it seemed like it probably affected (hostsdir?), and seemed useful yet without any real cost? Could it be that when inotify fires that it pulls in all files in --addn-hosts? In which case the dictionary order functions, even though we have inotify? Ed W ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
