Re: [Dnsmasq-discuss] Change in behaviour of --server
On Thu, Jul 22, 2021 at 08:57:13PM +0200, Geert Stappers via Dnsmasq-discuss wrote: > On Fri, Jul 09, 2021 at 02:10:23PM +0200, Petr Menšík wrote: > > On 7/6/21 10:23 PM, Simon Kelley wrote: > > > On 06/07/2021 12:14, Kevin Darbyshire-Bryant wrote: > > >> An eager OpenWrt tester of current dnsmasq master has noticed the > > >> following change in behaviour: > > > I have to say, I am very much liking the amount of testing that the > > > new code is getting. It's great to find these regressions _before_ > > > release. > > > > > Hi Simon, > > > > would you please tag another test version after fixing build of dbus > > builds? I tried building a test package for Fedora [1], but I would > > have to backport dbus fixes. No recent test release works with dbus > > enabled, which is required on Fedora. > > Tag 2.86test6 has been announced[2], does it build for Fedora?[3] Yes, it does build. Groeten Geert Stappers 1. https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/build/2312608/ 2. https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015320.html 3. https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/builds/ -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Change in behaviour of --server
On Fri, Jul 09, 2021 at 02:10:23PM +0200, Petr Menšík wrote: > On 7/6/21 10:23 PM, Simon Kelley wrote: > > On 06/07/2021 12:14, Kevin Darbyshire-Bryant wrote: > >> Hi Simon, > >> > >> An eager OpenWrt tester of current dnsmasq master has noticed the > >> following change in behaviour: > > I have to say, I am very much liking the amount of testing that the > > new code is getting. It's great to find these regressions _before_ > > release. > > > Hi Simon, > > would you please tag another test version after fixing build of dbus > builds? I tried building a test package for Fedora [1], but I would > have to backport dbus fixes. No recent test release works with dbus > enabled, which is required on Fedora. > > Thanks! Tag 2.86test6 has been announced[2], does it build for Fedora?[3] > Cheers, > Petr Groeten Geert Stappers 1. https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/build/2312608/ 2. https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015320.html 3. https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/builds/ -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Change in behaviour of --server
On 7/9/21 11:57 PM, Simon Kelley wrote: > On 09/07/2021 11:26, Petr Menšík wrote: >> Hi, >> >> just personal opinion. I think all described variants should end with >> configuration error. Desired behavior conflicts for all types. I see no >> reason to have both at the same time when only one can be active. If we >> care much about specific use case, it should print at least warning >> visible in dnsmasq --test output. I would exit with fatal and require >> user to specify clearly what is desired. Leaving only one variant >> without caring about their order. Just comment out the line you do not >> want active. >> >> As a minimum, it should warn there are conflicting orders for a single >> domain. > > Order doesn't matter. As a general rule, and with very few exceptions, > order of configuration _never_ matters in dnsmasq. > > The conflict is defined by priority; > > --server=/example.com/1.2.3.4 > > always has higher priority than > > --address=/example.com/ > > I think that's pretty reasonable. Is it? Administrator requested both forwarding example.com to 1.2.3.4 and sending NXDOMAIN for the name. Whatever priority it takes, one of them would be ignored and behaves like only one of these lines were specified. Administrator should know that just by checking dnsmasq.conf. Citing man page: --address=/example.com/ is equivalent to --server=/example.com/ Why would have forwarder IP higher priority than authoritative NXDOMAIN response? It would be opposite way on common server with authoritative zone such as bind9. Authoritative zone answers have higher priorities than forwarders. I think conflicting instructions should not be silently ignored to avoid confusion, especially those provided explicitly by the user. I think it is not well specified in manual page. Instead of describing arbitrary priorities, I would request user to specify only non-conflicting configuration. > > > Cheers, > > Simon. > > > >> Cheers, >> >> Petr >> >> On 7/6/21 1:14 PM, Kevin Darbyshire-Bryant wrote: >>> Hi Simon, >>> >>> An eager OpenWrt tester of current dnsmasq master has noticed the following >>> change in behaviour: >>> >>> Openwrt uses a conf file containing a list of RFC6761 domains that are >>> considered undesirable to forward, reducing load on upstream servers etc. >>> This conf file contains lines such as "server=/onion/“. Said user >>> overrides this with a line in main config file >>> ’server=/onion/127.0.0.1#2053’. Unfortunately current dnsmasq looks >>> through its servers and returns ’NXDOMAIN’. dnsmasq v2.85 says ‘yeah fine, >>> I’ll forward that to 127.0.0.1#2053’ >>> >>> The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 >>> config file - 2) Take advantage of new syntax and use >>> ’server=/*.onion/127.0.0.1#2053’ >>> >>> I’m flagging this as a change in behaviour and I’m not sure how >>> syntactically it can or even should be fixed, or just documented as a >>> change in behaviour. eg. >>> >>> Should there be a difference (& what should it be) between >>> >>> --server=/onion/ >>> --server=/onion/127.0.0.1#2053 >>> >>> (forward to 127.0.0.1#2053) >>> >>> and >>> >>> --server=/onion/127.0.0.1#2053 >>> --server=/onion/ >>> >>> (not sure!) >>> >>> or even worse >>> >>> --server=/onion/127.0.0.1#2053 >>> --server=/onion/ >>> --server=/onion/127.0.0.1#2153 >>> >>> (use both #2053 & #2153?) >>> >>> Cheers, >>> >>> Kevin D-B >>> >>> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >>> >>> -- >>> Petr Menšík >>> Software Engineer >>> Red Hat, http://www.redhat.com/ >>> email: pemen...@redhat.com >>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Change in behaviour of --server
On 09/07/2021 11:26, Petr Menšík wrote: > Hi, > > just personal opinion. I think all described variants should end with > configuration error. Desired behavior conflicts for all types. I see no > reason to have both at the same time when only one can be active. If we > care much about specific use case, it should print at least warning > visible in dnsmasq --test output. I would exit with fatal and require > user to specify clearly what is desired. Leaving only one variant > without caring about their order. Just comment out the line you do not > want active. > > As a minimum, it should warn there are conflicting orders for a single > domain. Order doesn't matter. As a general rule, and with very few exceptions, order of configuration _never_ matters in dnsmasq. The conflict is defined by priority; --server=/example.com/1.2.3.4 always has higher priority than --address=/example.com/ I think that's pretty reasonable. Cheers, Simon. > > Cheers, > > Petr > > On 7/6/21 1:14 PM, Kevin Darbyshire-Bryant wrote: >> Hi Simon, >> >> An eager OpenWrt tester of current dnsmasq master has noticed the following >> change in behaviour: >> >> Openwrt uses a conf file containing a list of RFC6761 domains that are >> considered undesirable to forward, reducing load on upstream servers etc. >> This conf file contains lines such as "server=/onion/“. Said user overrides >> this with a line in main config file ’server=/onion/127.0.0.1#2053’. >> Unfortunately current dnsmasq looks through its servers and returns >> ’NXDOMAIN’. dnsmasq v2.85 says ‘yeah fine, I’ll forward that to >> 127.0.0.1#2053’ >> >> The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 >> config file - 2) Take advantage of new syntax and use >> ’server=/*.onion/127.0.0.1#2053’ >> >> I’m flagging this as a change in behaviour and I’m not sure how >> syntactically it can or even should be fixed, or just documented as a change >> in behaviour. eg. >> >> Should there be a difference (& what should it be) between >> >> --server=/onion/ >> --server=/onion/127.0.0.1#2053 >> >> (forward to 127.0.0.1#2053) >> >> and >> >> --server=/onion/127.0.0.1#2053 >> --server=/onion/ >> >> (not sure!) >> >> or even worse >> >> --server=/onion/127.0.0.1#2053 >> --server=/onion/ >> --server=/onion/127.0.0.1#2153 >> >> (use both #2053 & #2153?) >> >> Cheers, >> >> Kevin D-B >> >> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >> >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > > ___ > 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] Change in behaviour of --server
Hi Simon, would you please tag another test version after fixing build of dbus builds? I tried building a test package for Fedora [1], but I would have to backport dbus fixes. No recent test release works with dbus enabled, which is required on Fedora. Thanks! Cheers, Petr 1. https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/build/2312608/ On 7/6/21 10:23 PM, Simon Kelley wrote: > On 06/07/2021 12:14, Kevin Darbyshire-Bryant wrote: >> Hi Simon, >> >> An eager OpenWrt tester of current dnsmasq master has noticed the following >> change in behaviour: > I have to say, I am very much liking the amount of testing that the new > code is getting. It's great to find these regressions _before_ release. > >> Openwrt uses a conf file containing a list of RFC6761 domains that are >> considered undesirable to forward, reducing load on upstream servers etc. >> This conf file contains lines such as "server=/onion/“. Said user overrides >> this with a line in main config file ’server=/onion/127.0.0.1#2053’. >> Unfortunately current dnsmasq looks through its servers and returns >> ’NXDOMAIN’. dnsmasq v2.85 says ‘yeah fine, I’ll forward that to >> 127.0.0.1#2053’ >> >> The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 >> config file - 2) Take advantage of new syntax and use >> ’server=/*.onion/127.0.0.1#2053’ >> >> I’m flagging this as a change in behaviour and I’m not sure how >> syntactically it can or even should be fixed, or just documented as a change >> in behaviour. eg. >> >> Should there be a difference (& what should it be) between >> >> --server=/onion/ >> --server=/onion/127.0.0.1#2053 >> >> (forward to 127.0.0.1#2053) >> >> and >> >> --server=/onion/127.0.0.1#2053 >> --server=/onion/ >> > The order is irrelevant. What matters is the type of configuration. This > is defined so that, for instance, > > --address=/example.com/1.2.3.4 > --server=/example.com/8.8.8.8 > > will return 1.2.3.4 to an A query, but forward any other queries to 8.8.8.8 > > The priority order is > > IPv6 address > IPv4 address, > all zeros address (--address=/example.com/#) > NXDOMAIN address (--address=/example.com/#/ or --local or --address) > send to an upstream server. > > The order of the last two was arbitrary: I hadn't considered a situation > in which > > --server=/example.com/#/ > --server=/example.com/8.8.8.8 > > would both exist, and that order is what came out of the implementation > most easily. > > Since doing that is a regression for earlier releases, and you've > demonstrated how the previous behaviour _can_ be useful, I'm happy to > swap the priority of the last two items in my list. > > > 719f79a8fdb7cc72a061b2492ea98f7486b6f90e > > does the deed. > > >> (not sure!) >> >> or even worse >> >> --server=/onion/127.0.0.1#2053 >> --server=/onion/ >> --server=/onion/127.0.0.1#2153 >> >> (use both #2053 & #2153?) > After 719f79a8fdb7cc72a061b2492ea98f7486b6f90e, that's exactly what will > happen. > > In general the new code makes servers for particular domains first-class > citizens, so you can specify more than one and dnsmasq will load-balance > across them in the same way it does for the general upstream servers. > > > > Cheers, > > Simon. > >> Cheers, >> >> Kevin D-B >> >> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Change in behaviour of --server
Hi, just personal opinion. I think all described variants should end with configuration error. Desired behavior conflicts for all types. I see no reason to have both at the same time when only one can be active. If we care much about specific use case, it should print at least warning visible in dnsmasq --test output. I would exit with fatal and require user to specify clearly what is desired. Leaving only one variant without caring about their order. Just comment out the line you do not want active. As a minimum, it should warn there are conflicting orders for a single domain. Cheers, Petr On 7/6/21 1:14 PM, Kevin Darbyshire-Bryant wrote: > Hi Simon, > > An eager OpenWrt tester of current dnsmasq master has noticed the following > change in behaviour: > > Openwrt uses a conf file containing a list of RFC6761 domains that are > considered undesirable to forward, reducing load on upstream servers etc. > This conf file contains lines such as "server=/onion/“. Said user overrides > this with a line in main config file ’server=/onion/127.0.0.1#2053’. > Unfortunately current dnsmasq looks through its servers and returns > ’NXDOMAIN’. dnsmasq v2.85 says ‘yeah fine, I’ll forward that to > 127.0.0.1#2053’ > > The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 > config file - 2) Take advantage of new syntax and use > ’server=/*.onion/127.0.0.1#2053’ > > I’m flagging this as a change in behaviour and I’m not sure how syntactically > it can or even should be fixed, or just documented as a change in behaviour. > eg. > > Should there be a difference (& what should it be) between > > --server=/onion/ > --server=/onion/127.0.0.1#2053 > > (forward to 127.0.0.1#2053) > > and > > --server=/onion/127.0.0.1#2053 > --server=/onion/ > > (not sure!) > > or even worse > > --server=/onion/127.0.0.1#2053 > --server=/onion/ > --server=/onion/127.0.0.1#2153 > > (use both #2053 & #2153?) > > Cheers, > > Kevin D-B > > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Change in behaviour of --server
On 06/07/2021 12:14, Kevin Darbyshire-Bryant wrote: > Hi Simon, > > An eager OpenWrt tester of current dnsmasq master has noticed the following > change in behaviour: I have to say, I am very much liking the amount of testing that the new code is getting. It's great to find these regressions _before_ release. > > Openwrt uses a conf file containing a list of RFC6761 domains that are > considered undesirable to forward, reducing load on upstream servers etc. > This conf file contains lines such as "server=/onion/“. Said user overrides > this with a line in main config file ’server=/onion/127.0.0.1#2053’. > Unfortunately current dnsmasq looks through its servers and returns > ’NXDOMAIN’. dnsmasq v2.85 says ‘yeah fine, I’ll forward that to > 127.0.0.1#2053’ > > The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 > config file - 2) Take advantage of new syntax and use > ’server=/*.onion/127.0.0.1#2053’ > > I’m flagging this as a change in behaviour and I’m not sure how syntactically > it can or even should be fixed, or just documented as a change in behaviour. > eg. > > Should there be a difference (& what should it be) between > > --server=/onion/ > --server=/onion/127.0.0.1#2053 > > (forward to 127.0.0.1#2053) > > and > > --server=/onion/127.0.0.1#2053 > --server=/onion/ > The order is irrelevant. What matters is the type of configuration. This is defined so that, for instance, --address=/example.com/1.2.3.4 --server=/example.com/8.8.8.8 will return 1.2.3.4 to an A query, but forward any other queries to 8.8.8.8 The priority order is IPv6 address IPv4 address, all zeros address (--address=/example.com/#) NXDOMAIN address (--address=/example.com/ or --local or --address) send to an upstream server. The order of the last two was arbitrary: I hadn't considered a situation in which --server=/example.com/ --server=/example.com/8.8.8.8 would both exist, and that order is what came out of the implementation most easily. Since doing that is a regression for earlier releases, and you've demonstrated how the previous behaviour _can_ be useful, I'm happy to swap the priority of the last two items in my list. 719f79a8fdb7cc72a061b2492ea98f7486b6f90e does the deed. > (not sure!) > > or even worse > > --server=/onion/127.0.0.1#2053 > --server=/onion/ > --server=/onion/127.0.0.1#2153 > > (use both #2053 & #2153?) After 719f79a8fdb7cc72a061b2492ea98f7486b6f90e, that's exactly what will happen. In general the new code makes servers for particular domains first-class citizens, so you can specify more than one and dnsmasq will load-balance across them in the same way it does for the general upstream servers. Cheers, Simon. > > Cheers, > > Kevin D-B > > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A > > > ___ > 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
[Dnsmasq-discuss] Change in behaviour of --server
Hi Simon, An eager OpenWrt tester of current dnsmasq master has noticed the following change in behaviour: Openwrt uses a conf file containing a list of RFC6761 domains that are considered undesirable to forward, reducing load on upstream servers etc. This conf file contains lines such as "server=/onion/“. Said user overrides this with a line in main config file ’server=/onion/127.0.0.1#2053’. Unfortunately current dnsmasq looks through its servers and returns ’NXDOMAIN’. dnsmasq v2.85 says ‘yeah fine, I’ll forward that to 127.0.0.1#2053’ The are two solutions to this: 1) drop ’server=/onion/‘ from the RFC6761 config file - 2) Take advantage of new syntax and use ’server=/*.onion/127.0.0.1#2053’ I’m flagging this as a change in behaviour and I’m not sure how syntactically it can or even should be fixed, or just documented as a change in behaviour. eg. Should there be a difference (& what should it be) between --server=/onion/ --server=/onion/127.0.0.1#2053 (forward to 127.0.0.1#2053) and --server=/onion/127.0.0.1#2053 --server=/onion/ (not sure!) or even worse --server=/onion/127.0.0.1#2053 --server=/onion/ --server=/onion/127.0.0.1#2153 (use both #2053 & #2153?) Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with OpenPGP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
