[Dnsmasq-discuss] TCP Fast Open?
TCP Fast Open eliminates a round trip for TCP connections. Since dnsmasq is performance sensitive and uses many TCP connections, using TCP Fast Open would be a nice improvement. See https://lwn.net/Articles/508865/ for background. On the client side, it's as simple as setting the TCP_FASTOPEN_CONNECT option on the socket. On the server side, dnsmasq would do something like this on the listening socket: int qlen = 5; setsockopt(fd, SOL_TCP, TCP_FASTOPEN, , sizeof(qlen)); Chrome and Firefox have supported TCP Fast Open for clients for over a year, and other DNS servers (ex unbound) use it for client and sever connections too. Could dnsmasq implement TCP Fast Open? Thanks, ~Craig signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Cannot look up disa.mil (dnssec related)
On 23.10.2018 17:57, Simon Kelley wrote: On 22/10/2018 17:56, Craig Andrews wrote: I'm unable to look up *.disa.mil when using dnsmasq - I'm hoping that we can figure out why that is. I have dnsmasq configured to use Cloudflare's 1.1.1.1 as its upstream DNS server; dnsmasq is running on 192.168.0.1. Here are some a couple tests demonstrating the problem: -- $ dig disa.mil @192.168.0.1 +dnssec +short $ dig disa.mil @8.8.8.8 +dnssec +short 156.112.108.76 A 8 2 7200 20181117145327 20181018145327 52983 disa.mil. dMS5WbQ5xJ0HuCBPZUkuoshf0A2n1tvxA75smhcFZNS5SHSOA0zsQaSc YOzNdu5gH6qFXA7TbKhPYN0RcPD+vVcmtfbzv3eJZfh4343IXlBznG6w aLaLt+kI6GGnPQ7skNWOcO4yLct+yaeNxTT95CZnHtwRUx3vzGHS3dJF GYc= [candrews@craigatwork vars]$ dig disa.mil @1.1.1.1 +dnssec +short 156.112.108.76 -- So looking it up using Google's 8.8.8.8 or Cloudflare's 1.1.1.1 with dnssec works, but not with dnsmasq. As Matthias says elsewhere in the thread, the last sentence above appears not to be correct: it does work with 8.8.8.8, but not with 1.1.1.1 srk@holly:~$ dig disa.mil @8.8.8.8 +dnssec +short 156.112.108.76 A 8 2 7200 20181117145327 20181018145327 52983 disa.mil. dMS5WbQ5xJ0HuCBPZUkuoshf0A2n1tvxA75smhcFZNS5SHSOA0zsQaSc YOzNdu5gH6qFXA7TbKhPYN0RcPD+vVcmtfbzv3eJZfh4343IXlBznG6w aLaLt+kI6GGnPQ7skNWOcO4yLct+yaeNxTT95CZnHtwRUx3vzGHS3dJF GYc= srk@holly:~$ dig disa.mil @1.1.1.1 +dnssec +short 156.112.108.76 The replies from 1.1.1.1 are missing the DNSSEC signatures, and this appears to be a problem at Cloudflare, rather than a problem with dnsmasq, or with the domain. If I use 8.8.8.8 as upstream, dnsmasq validates fine. If I use 1.1.1.1 validation fails, because 1.1.1.1 is not returning the RRSIG RRs, even though it's been asked to. Without those RRSIGs the reply can't be validated. This problem with 1.1.1.1 seems to extend to many more .mil domains. TL;DR. Not a dnsmasq problem, not a domain problem, probably a Cloudflare problem. Craig, please could you report this to Cloudflare? Cheers, Simon. Thanks for correcting my misunderstanding of this issue! I've reported the issue to Cloudflare at https://community.cloudflare.com/t/1-1-1-1-doesnt-return-dnssec-data-for-disa-mil-googles-8-8-8-8-does/40837 Thanks, ~Craig ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Cannot look up disa.mil (dnssec related)
I'm unable to look up *.disa.mil when using dnsmasq - I'm hoping that we can figure out why that is. I have dnsmasq configured to use Cloudflare's 1.1.1.1 as its upstream DNS server; dnsmasq is running on 192.168.0.1. Here are some a couple tests demonstrating the problem: -- $ dig disa.mil @192.168.0.1 +dnssec +short $ dig disa.mil @8.8.8.8 +dnssec +short 156.112.108.76 A 8 2 7200 20181117145327 20181018145327 52983 disa.mil. dMS5WbQ5xJ0HuCBPZUkuoshf0A2n1tvxA75smhcFZNS5SHSOA0zsQaSc YOzNdu5gH6qFXA7TbKhPYN0RcPD+vVcmtfbzv3eJZfh4343IXlBznG6w aLaLt+kI6GGnPQ7skNWOcO4yLct+yaeNxTT95CZnHtwRUx3vzGHS3dJF GYc= [candrews@craigatwork vars]$ dig disa.mil @1.1.1.1 +dnssec +short 156.112.108.76 -- So looking it up using Google's 8.8.8.8 or Cloudflare's 1.1.1.1 with dnssec works, but not with dnsmasq. -- # dnsmasq --version Dnsmasq version 2.80test3 Copyright (c) 2000-2018 Simon Kelley Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC no-ID loop-detect inotify dumpfile This software comes with ABSOLUTELY NO WARRANTY. Dnsmasq is free software, and you are welcome to redistribute it under the terms of the GNU General Public License, version 2 or 3. -- Thanks in advance for your help and for this great software, ~Craig ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] systemd service improvements
On 30.06.2016 17:39, Kurt H Maier wrote: On Thu, Jun 30, 2016 at 05:19:54PM -0400, Craig Andrews wrote: I have no argument against only installing the systemd unit if a configure flag is specified. Many pieces of software do it that way - I think the important thing is that it's available from dnsmasq. So I rescind my thought to install it unconditionally. What would the configure flag be passed to? The "make" invocation. Just like how there is a "-DHAVE_DNSSEC" option, there could be a "-DHAVE_SYSTEMD" one. It would take more lines of code to modify the build process to suit this than it would just to write the unit file, and then you'd still have to rewrite the unit file for each distro. The point isn't (necessarily) to conserve lines of code - the point is to have one place for distributions/users to collaborate in order to best develop and maintain this portion of the project. And each distro does not (and absolutely should not) rewrite the unit file. (Would you be happy if each distro patched dnsmasq? Same thing.) The traditional allocation of init responsibilities has always been such as to free the upstream developer from the administrative minutiae by devolving the systems management functions to those whose experience and daily operations have better formed them for the performance of such maintenance takss, thereby releasing the upstream developers for the more task-specific duties and deliberations. Agreed. Systemd advances the situation by making it consistent and easier to manage these kinds of operations by using these short, readable, not many lines of code files that work across distros. Upstream is free to not worry if distros are doing something bizarre in their init process; upstream can trust that all distros are doing the same thing, giving upstream one (signficant) less thing to worry about. Right now, note how each of these distribution's systemd units are different: Gentoo: https://github.com/gentoo/gentoo/blob/cae8d8ccd7658253a336a7595796f8a9264332de/net-dns/dnsmasq/files/dnsmasq.service-r1 Debian: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD Fedora: http://pkgs.fedoraproject.org/cgit/rpms/dnsmasq.git/tree/dnsmasq.service The differences are in paths (a Makefile can eliminate those difference) and different security features (which are only different because some distros didn't notice some security features). Distros are trying to use upstream units and get upstreams to include units: * Fedora: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files "Ideally, systemd unit files are reusable across distributions and shipped with the upstream packages. Please consider working with upstream to integrate the systemd files you prepare in the upstream sources." * https://wiki.archlinux.org/index.php/DeveloperWiki:Systemd#Units "Use the upstream unit files whenever they exist" A growing number of projects (big and small) have upstreamed systemd units, such as: * bluez / Linux Bluetooth * Tor * MariaDB * netdata * lirc * php * memcached In short, I still think a generic unit file in /contrib is best, and people who want to use it will be okay if they have to copy it where their OS wants it. dnsmasq runs in a lot of places systemd doesn't, so systemd is not to be taken as given. khm I agree systemd isn't a given (again, my apologies once again for suggesting that units are installed unconditionally). However, the file does need to be customized for install paths and features (ex -DHAVE_) which the Makefile already does, so the file shouldn't in /contrib - I think it should be with the rest of the source, and conditionally processed and installed to the correct location by the Makefile. I modified the Makefile and added the systemd unit. I'm not a Make expert, so I apologize for the errors I've very likely made. With this patch, you can run (for example): make COPTS="-DHAVE_DBUS -DHAVE_SYSTEMD" all install and you'll get a dnsmasq.system file created, customized, and installed to the correct location (for any distribution). While I was in there, I also made the Makefile (conditionally, if -DHAVE_DBUS is provided) install the dbus service configuration. I'm eager to hear thoughts about this approach. Thanks, ~Craigdiff --git a/.gitignore b/.gitignore index 23f1148..3bfdebb 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +src/dnsmasq.service src/*.o src/*.mo src/dnsmasq.pot diff --git a/Makefile b/Makefile index dd0513b..624047c 100644 --- a/Makefile +++ b/Makefile @@ -51,6 +51,8 @@ top!=pwd # GNU make way. top?=$(CURDIR) +systemd_system_unit_dir = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_SYSTEMD $(PKG_CONFIG) --variable=systemdsystemunitdir systemd` +dbus_sysconfdir = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_DBUS $(PKG_CONFIG)
Re: [Dnsmasq-discuss] systemd service improvements
Greetings and salutations, On 30.06.2016 16:18, Albert ARIBAUD wrote: Bonjour, Le Thu, 30 Jun 2016 21:18:02 +0200 Pali Rohár <pali.ro...@gmail.com> a écrit: On Thursday 30 June 2016 16:58:56 Craig Andrews wrote: > I'd like to propose a couple changes in terms of systemd in dnsmaq. > First, dnsmasq should always install a systemd unit so all > distributions/users can use it I'm against such change. Why on the Earth install useless files into system which do nothing? I really do not want to see that programs starts installing systemd files just because it is "no harm". If such thing happen, dnsmasq then should install also config file for upstart, also for openrc, and also install shortcut for Windows start menu for *all* systems as that is too by that definition "no harm". I tend to agree with the principle that a systemd unit file should only be installed on systems which use systemd. I was surprised indeed to see that the dnsmasq git repo contains such a file. Furthermore, the OP itself indicates that different systemd-based distributions will require different systemd units for dnsmasq, which shows that systemd (or upstart, or sysvinit...) files should be managed at the distribution, not upstream application, level. Amicalement, I have no argument against only installing the systemd unit if a configure flag is specified. Many pieces of software do it that way - I think the important thing is that it's available from dnsmasq. So I rescind my thought to install it unconditionally. Regarding distributing config files for upstart, openrc, and everything else - I think there are 2 ways to look at that: 1) systemd is used by many Linux distributions, and that number is increasing. So by distributing it, the most users benefit, as compared to the low, and decreasing, number of users of openrc and upstart. 2) If dnsmasq wants to distribute init configs for other init systems, that seems fine. That would just mean that if, for example, dnsmasq distributes an upstart configuration file, then all distributions/users of upstart can collaborate in one place instead of all being siloed. The goal of including the systemd unit is for there to be one place (dnsmasq aka upstream) for fixes, improvements, and development to take place. For example, if someone notices that dnsmasq can be hardened, that change currently has to be made in every distribution separately. That lack of collaboration is really inefficient - tons of effort is being wasted. It also introduces confusion and maintainability problems; with every distribution being inconsistent, that's just one more variable dnsmasq has to deal with when a bug report or feature request is made. I'm not currently using Debian, so I can't comment too much on its systemd unit. Ideally, I'd love to see the same unit used for all distributions. But if that's not possible, just like how distributions can patch source code if they have to, distributions can patch upstream's systemd units. Such patching is not a reason to stop distribution of something (be it source code, configuration, or anything else). Thanks, ~Craig ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] systemd service improvements
I'd like to propose a couple changes in terms of systemd in dnsmaq. First, dnsmasq should always install a systemd unit so all distributions/users can use it (if a user/distro doesn't use systemd, the unit will be simply be ignored - no harm done). Currently, the unit is only part of the Debian packaging. Dnsmaq may want to include an alternate unit in the Debian packaging and a generic, for-all-distros version in the default installation. Second, the systemd unit should be improved a bit to feature hardening and not running as root. Here's my proposed dnsmasq.service: --- [Unit] Description=A lightweight DHCP and caching DNS server After=network.target [Service] User=dnsmasq Group=dnsmasq Type=simple PIDFile=/run/dnsmasq/dnsmasq.pid ExecStartPre=/usr/sbin/dnsmasq --test ExecStart=/usr/sbin/dnsmasq -k -x /run/dnsmasq/dnsmasq.pid ExecReload=/bin/kill -HUP $MAINPID RuntimeDirectory=dnsmasq CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN PrivateTmp=yes PrivateDevices=yes ProtectSystem=full ProtectHome=yes NoNewPrivileges=yes [Install] WantedBy=multi-user.target --- Compared to http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD I think this is a nice improvement. The only issue is that the Debian version uses /etc/init.d/dnsmasq and depends on Debian's resolvconf which other distros won't have, hence dnsmaq will probably want to keep a special unit for Debian. Thanks, ~Craig ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
