Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file
Hi Simon, On Fri, Apr 7, 2017 at 11:27 PM, Simon Kelley wrote: > The overriding objection to this is that it adds to the syntax and > semantics of the resolv-file format, but dnsmasq doesn't "own" that > format: it's actually a libc configuration file, and dnsmasq takes > advantage of the fact that the format is "well known" to extract useful > information from it. If you start adding extra fields to > /etc/resolv.conf then the c-library will get upset. I have been thinking some more about this. The reason for locking the support for server-strings in the resolv behind a command line option, was to avoid what you are describing here - compatibility issues with the existing resolv-file format. I assume that if anyone enables the option, they know what they are doing and what implications it might have. I should maybe have explained this better in either the commit or the addition to the man-page. > I understand the desire to be able to specify resolvers dynamically with > the full set of source-address and routing options; that's actually > already available, and has been for a long time, using the DBus > interface to dnsmasq, which includes the "SetDomainServers" method, > which takes strings identical to argument to --server. I've not looked > at the code, but your previous patch to allow binding both IP and > interface should have automatically added that feature to > SetDomainServers. (if it didn't then I'd certainly take a patch to > correct that.) I did a quick test and it seems that specifying servers (with the additional interface/ip-information) using the DBus-interface works fine. However, this does not help on systems not using DBus (like OpenWRT/LEDE). Do you have any suggestions for an acceptable way to implement this feature, without requiring the use DBus? Thanks in advance for the help, Kristian ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] FW: Cachesize
Hi, I understand this is hardcoded to a limit of 1 but we use it for a small ISP network and quite often reach this, is it possible to make it 25000 in next release? Everyone has the choice at loading what to set it to, so I can't see how this would cause issues. I would prefer to just use available packages than have to compile my own to adjust this and always have to remember the modification. Thanks, Nathan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] FW: Cachesize
Hi Nathan. If you hit a cache limit of 1 quite often, are you sure dnsmasq is still the best choice for that server? I think dnsmasq focuses on small home routers and end networks. Have you considered other caching resolver, unbound for example? I think if this limit is not enough, maybe your network is not small enough. There is limit for some reason. I hope full cache does not mean recursion will stop working, but I did not validate that assumption. I think main DNS resolvers of ISP network should use something more heavy than dnsmasq. How many end hosts are using that server? Do you require dnsmasq specific features? Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 - Original Message - From: "Nathan Downes" To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Monday, April 10, 2017 10:41:24 AM Subject: [Dnsmasq-discuss] FW: Cachesize Hi, I understand this is hardcoded to a limit of 1 but we use it for a small ISP network and quite often reach this, is it possible to make it 25000 in next release? Everyone has the choice at loading what to set it to, so I can’t see how this would cause issues. I would prefer to just use available packages than have to compile my own to adjust this and always have to remember the modification. Thanks, Nathan ___ 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] [PATCH] Support --server syntax in resolv-file
Hi, On Mon, Apr 10, 2017 at 1:53 PM, Vladislav Grishenko wrote: > FYI, changing resolv.conf format could lead libc resolver to fail, so it's > quite dangerous change. > As I understand, you want dynamic DNS servers update with additional info > (interface/src ip binding). > With no DBUS, can't it be done with --servers-file option (available since > 2.69)? > This files allow full format of --server & --rev-server and are reread on > SIGHUP, polling is not supported at the moment. Thanks a lot for the pointer to this command line option. It looks like the perfect solution to my problem :) -Kristian ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file
Hi Kristian, FYI, changing resolv.conf format could lead libc resolver to fail, so it's quite dangerous change. As I understand, you want dynamic DNS servers update with additional info (interface/src ip binding). With no DBUS, can't it be done with --servers-file option (available since 2.69)? This files allow full format of --server & --rev-server and are reread on SIGHUP, polling is not supported at the moment. Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Kristian Evensen Sent: Monday, April 10, 2017 1:35 PM To: Simon Kelley Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] [PATCH] Support --server syntax in resolv-file Hi Simon, On Fri, Apr 7, 2017 at 11:27 PM, Simon Kelley wrote: > The overriding objection to this is that it adds to the syntax and > semantics of the resolv-file format, but dnsmasq doesn't "own" that > format: it's actually a libc configuration file, and dnsmasq takes > advantage of the fact that the format is "well known" to extract > useful information from it. If you start adding extra fields to > /etc/resolv.conf then the c-library will get upset. I have been thinking some more about this. The reason for locking the support for server-strings in the resolv behind a command line option, was to avoid what you are describing here - compatibility issues with the existing resolv-file format. I assume that if anyone enables the option, they know what they are doing and what implications it might have. I should maybe have explained this better in either the commit or the addition to the man-page. > I understand the desire to be able to specify resolvers dynamically > with the full set of source-address and routing options; that's > actually already available, and has been for a long time, using the > DBus interface to dnsmasq, which includes the "SetDomainServers" > method, which takes strings identical to argument to --server. I've > not looked at the code, but your previous patch to allow binding both > IP and interface should have automatically added that feature to > SetDomainServers. (if it didn't then I'd certainly take a patch to > correct that.) I did a quick test and it seems that specifying servers (with the additional interface/ip-information) using the DBus-interface works fine. However, this does not help on systems not using DBus (like OpenWRT/LEDE). Do you have any suggestions for an acceptable way to implement this feature, without requiring the use DBus? Thanks in advance for the help, Kristian ___ 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] dnsmasq got if_nametoindex("lo”), expected was ipi_ifindex=1939
Hello,
I’m facing an issue on dhcp_release and dnsmasq in OpenStack and would
appreciate any help or pointers to find the root cause.
Summary:
dnsmasq is receiving if_nametoindex("lo”) instead of 1939, the index for
tap2bb5e1af-d3 that was issued by dhcp_release command.
The DHCP RELEASE packet is sent fine, and dnsmasq receives it. However, the
release actually never happens because dnsmasq receives it as it was sent by
loopback interface “lo”, index 1. This is observed in the recvmsg from dnsmasq:
ipi_ifindex=if_nametoindex("lo”), opposed to a working environment (x86), where
I see ipi_ifindex=230, the right index for the tap interface.
I am manually reproducing OpenStack commands for dhcp_release with:
* strace -s 1024 ip netns exec qdhcp-6a28b963-4729-441a-ba86-cf8424a0ee1a
./dhcp_release tap2bb5e1af-d3 10.1.0.7 fa:16:3e:af:1a:c4
* ip netns exec qdhcp-6a28b963-4729-441a-ba86-cf8424a0ee1a tcpdump -i lo udp
-nnvvXSs 1514
* strace -s 1024 ip netns exec qdhcp-6a28b963-4729-441a-ba86-cf8424a0ee1a
dnsmasq -d --no-hosts --strict-order --except-interface=lo
--pid-file=/opt/stack/data/neutron/dhcp/6a28b963-4729-441a-ba86-cf8424a0ee1a/pid
--dhcp-hostsfile=/opt/stack/data/neutron/dhcp/6a28b963-4729-441a-ba86-cf8424a0ee1a/host
--addn-hosts=/opt/stack/data/neutron/dhcp/6a28b963-4729-441a-ba86-cf8424a0ee1a/addn_hosts
--dhcp-optsfile=/opt/stack/data/neutron/dhcp/6a28b963-4729-441a-ba86-cf8424a0ee1a/opts
--dhcp-leasefile=/opt/stack/data/neutron/dhcp/6a28b963-4729-441a-ba86-cf8424a0ee1a/leases
--dhcp-match=set:ipxe,175 --bind-interfaces --interface=tap2bb5e1af-d3
--dhcp-range=set:tag0,10.1.0.0,static,86400s
--dhcp-option-force=option:mtu,1450 --dhcp-lease-max=16 --conf-file=
--domain=openstacklocal
dhcp_release:
ioctl(5, SIOCGIFINDEX, {ifr_name="tap2bb5e1af-d3", }) = 0
write(2, "> ifa->ifa_index = 1939", 27> ifa->ifa_index = 1939) = 27
sendto(3,
"\1\1\6\0\0\0\0\0\0\0\0\0\n\1\0\7\0\0\0\0\0\0\0\0\0\0\0\0\372\26>\257\32\304\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0c\202Sc5\1\0076\4\n\1\0\2\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
548, 0, {sa_family=AF_INET, sin_port=htons(67),
sin_addr=inet_addr("10.1.0.2")}, 16) = 548
dnsmasq:
recvmsg(4, {msg_name(16)={sa_family=AF_INET, sin_port=htons(39180),
sin_addr=inet_addr("10.1.0.2")},
msg_iov(1)=[{"\1\1\6\0\0\0\0\0\0\0\0\0\n\1\0\7\0\0\0\0\0\0\0\0\0\0\0\0\372\26>\257\32\304\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0c\202Sc5\1\0076\4\n\1\0\2\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
548}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"),
ipi_spec_dst=inet_addr("10.1.0.2"), ipi_addr=inet_addr("10.1.0.2")}}],
msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 548
# ip netns exec qdhcp-6a28b963-4729-441a-ba86-cf8424a0ee1a ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
1939: tap2bb5e1af-d3: mtu 1450 qdisc noqueue
state UNKNOWN group defaul
Re: [Dnsmasq-discuss] FW: Cachesize
Hi Petr, I guess that is totally possible, I had just used it for a few other projects so figured if it works why not use it :) The only things I use are setting minimum cache ttl to 30 mins and max cache size to 10k. There is only about 1000 endpoints of various types, from residential to business. It only came about because I noticed the quantity of traffic to other resolvers was a lot more than I expected and I guessed caching would improve the experience for the end users. It functions well at this level as far as I can see, always sub ms responses and almost no load on server. It is just a small VM with Dnsmasq, SMTP relay and STUN server. I will check out other options then if I am pushing the limits of capability -Original Message- From: Petr Mensik [mailto:pemen...@redhat.com] Sent: Monday, 10 April 2017 8:51 PM To: Nathan Downes Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] FW: Cachesize Hi Nathan. If you hit a cache limit of 1 quite often, are you sure dnsmasq is still the best choice for that server? I think dnsmasq focuses on small home routers and end networks. Have you considered other caching resolver, unbound for example? I think if this limit is not enough, maybe your network is not small enough. There is limit for some reason. I hope full cache does not mean recursion will stop working, but I did not validate that assumption. I think main DNS resolvers of ISP network should use something more heavy than dnsmasq. How many end hosts are using that server? Do you require dnsmasq specific features? Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 - Original Message - From: "Nathan Downes" To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Monday, April 10, 2017 10:41:24 AM Subject: [Dnsmasq-discuss] FW: Cachesize Hi, I understand this is hardcoded to a limit of 1 but we use it for a small ISP network and quite often reach this, is it possible to make it 25000 in next release? Everyone has the choice at loading what to set it to, so I can’t see how this would cause issues. I would prefer to just use available packages than have to compile my own to adjust this and always have to remember the modification. Thanks, Nathan ___ 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] FW: Cachesize
Hi Nathan, Just thinking out loud: > There is only about 1000 endpoints of various types, from residential to business. Having worked with Unbound and dnsmasq, I would say the proverb "right tool for the right job applies." I would guess not all 1000 endpoints are on one subnet, maybe half-dozen, correct? If you had dnsmasq running an instance for each subnet, then that might be a bit more reasonable. If you want just one VM and one server, then I might suggest Unbound. Its as easy to configure, and you can just recurse the global Internet instead of forward (or forward or both or whatever). If you don't DHCP-DNS in one, then Unbound is going to work for you. > It only came about because I noticed the quantity of traffic to other resolvers was a lot more than I expected and I guessed caching would improve the experience for the end users. That depends on a lot of things. Statistics would need to be collected to be sure. Compare common cache queries that expire versus unique queries. If your cache pushes "google.com" out, then that may be a problem. If its all the click bait on news sites creating unique DNS lookups to a rotating army of ad-sites, then there isn't much to do. > The only things I use are setting minimum cache ttl to 30 mins... That is pushing the edge for certain cases. Server rotation may make some clients connectivity go dead for that 30 mins. Small business customers with small business web-site/email providers can suffer worse when small business server farm providers make things "difficult." Hope it helps. -Eric ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
