Re: [Dnsmasq-discuss] multiple upstream servers
What DNS server does the client MOEDW1CKH5 think is it's DNS? If it's a linux client then check /etc/resolv.conf to see or sniff the wire for the DHCP request/response. You've told dnsmasq to send a lease with option 6 (DNS) set to 10.88.13.3. Where dnsmasq forwards the queries to is not relevant to your issue, you only have one upstream server configured. S Irlapati wrote on 7/29/2020 3:29 PM: > Yes, that was a cut and paste error. I have simplified the file to > make things easier to debug. > > Here is what it looks like now, I will paste the whole file here > > port=53 > bogus-priv > no-resolv > local=/localnet/ > user=dnsmasq > group=dnsmasq > interface=enp5s0 > listen-address=127.0.0.1,192.168.13.1 > expand-hosts > domain=irlanet.org > dhcp-range=192.168.13.224,192.168.13.255,2h > dhcp-authoritative > cache-size=0 > cname=win-sji,MOEDW1CKH5 > log-queries > log-dhcp > > dhcp-host=00:68:eb:3b:32:33,MOEDW1CKH5,set:red,192.168.13.192 > > dhcp-option=tag:red,option:dns-server,10.88.13.3 > dhcp-option=tag:green,option:dns-server,10.88.13.4 > dhcp-option=option:dns-server,10.88.13.4 > server=10.88.13.4#53 > > Here is how dnsmasq is tested from MODEW1CKH5 > > [si@MOEDW1CKH5 593]>curl ident.me > 97.90.236.142 > > Here is what shows up in the log files > > Jul 29 17:26:16 xroads dnsmasq[2612016]: query[A] ident.me from > 192.168.13.192 > Jul 29 17:26:16 xroads dnsmasq[2612016]: forwarded ident.me to 10.88.13.4 > Jul 29 17:26:16 xroads dnsmasq[2612016]: query[] ident.me from > 192.168.13.192 > Jul 29 17:26:16 xroads dnsmasq[2612016]: forwarded ident.me to 10.88.13.4 > Jul 29 17:26:16 xroads dnsmasq[2612016]: reply ident.me is 176.58.123.25 > Jul 29 17:26:16 xroads dnsmasq[2612016]: reply ident.me is > 2a01:7e00::f03c:91ff:fe70:2b9d > > Does the order of the statements in the config files matter? > > On 7/29/2020 2:42 PM, Daryl Richards wrote: >> On 2020-07-29 2:40 p.m., S Irlapati wrote: >>> Thanks for the quick reply. >>> >>> I have changed it to >>> >>> dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 >>> dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 >>> >>> dhcp-option=tag:red,option:dns-server,10.88.13.3 >>> dhcp-option=tag:green,option:dns-server,10.88.13.4 >>> server=10.88.13.4#53 >>> >>> It still does the same thing. >>> >>> When querying from machine floater, it get forwarded it to 10.88.13.4 >>> >>> Any other suggestions? Could there be something else that is being >>> missed? >> >> I'm not sure if this is a cut/paste error - but the line looks the >> same as before with tag: instead of set:.. Also looking at the man >> page it shows the options in a slighty different order (don't know if >> that matters). So, it should be: >> >> dhcp-host=00:a1:b0:08:61:67,set:red,192.168.13.109,floater >> dhcp-host=00:c0:a8:be:ed:d0,set:green,192.168.13.110,Ziong >> > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 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] multiple upstream servers
Here are a few experiments that have been done. Config file: port=53 bogus-priv no-resolv local=/localnet/ user=dnsmasq group=dnsmasq interface=enp5s0 listen-address=127.0.0.1,192.168.13.1 expand-hosts domain=irlanet.org dhcp-range=192.168.13.224,192.168.13.255,2h dhcp-authoritative cache-size=0 cname=win-sji,MOEDW1CKH5 log-queries log-dhcp dhcp-host=40:16:7e:63:60:d1,Salem,set:red,192.168.13.102 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 dhcp-option=option:dns-server,10.88.13.4 server=10.88.13.4#53 From the host Salem when forcing a quiery: @salem 558]>curl ident.me 154.21.57.55 From dnsmasq server log files Jul 29 18:17:56 xroads dnsmasq[3822653]: query[A] ident.me from 192.168.13.102 Jul 29 18:17:56 xroads dnsmasq[3822653]: forwarded ident.me to 10.88.13.4 Jul 29 18:17:56 xroads dnsmasq[3822653]: query[] ident.me from 192.168.13.102 Jul 29 18:17:56 xroads dnsmasq[3822653]: forwarded ident.me to 10.88.13.4 Jul 29 18:17:56 xroads dnsmasq[3822653]: reply ident.me is 176.58.123.25 Jul 29 18:17:56 xroads dnsmasq[3822653]: reply ident.me is 2a01:7e00::f03c:91ff:fe70:2b9d The goal is to make queries from Salem to be forwared to 10.88.13.4 From here only the serveer lines will be changed. dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 dhcp-option=option:dns-server,10.88.13.4 # server=10.88.13.4#53 Query from Salem results: @salem 558]>curl ident.me curl: (6) Could not resolve host: ident.me Dnsmasq log file output: Jul 29 18:20:57 xroads dnsmasq[4042096]: query[A] ident.me from 192.168.13.102 Jul 29 18:20:57 xroads dnsmasq[4042096]: query[] ident.me from 192.168.13.102 Jul 29 18:20:57 xroads dnsmasq[4042096]: query[A] ident.me from 192.168.13.102 Jul 29 18:20:57 xroads dnsmasq[4042096]: query[] ident.me from 192.168.13.102 Jul 29 18:20:57 xroads dnsmasq[4042096]: query[A] ident.me.irlanet.org from 192.168.13.102 Jul 29 18:20:57 xroads dnsmasq[4042096]: query[] ident.me.irlanet.org from 192.168.13.102 Jul 29 18:20:57 xroads dnsmasq[4042096]: query[A] ident.me.irlanet.org from 192.168.13.102 Jul 29 18:20:57 xroads dnsmasq[4042096]: query[] ident.me.irlanet.org from 192.168.13.102 It looks like dnsmasq does not know where to forward the requests. Changing the servers again: dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 dhcp-option=option:dns-server,10.88.13.4 server=10.88.13.3#53 Querying from Salem: @salem 558]>curl ident.me 154.21.57.55 Dnsmasq log file: Jul 29 18:23:36 xroads dnsmasq[4105784]: query[A] ident.me from 192.168.13.102 Jul 29 18:23:36 xroads dnsmasq[4105784]: forwarded ident.me to 10.88.13.3 Jul 29 18:23:36 xroads dnsmasq[4105784]: query[] ident.me from 192.168.13.102 Jul 29 18:23:36 xroads dnsmasq[4105784]: forwarded ident.me to 10.88.13.3 Jul 29 18:23:36 xroads dnsmasq[4105784]: reply ident.me is 176.58.123.25 Jul 29 18:23:36 xroads dnsmasq[4105784]: reply ident.me is 2a01:7e00::f03c:91ff:fe70:2b9d From the above experiments it looks like dhcp-option is completely ignored. Does anyone see a problem with the config? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
On 2020-07-29 2:40 p.m., S Irlapati wrote: Thanks for the quick reply. I have changed it to dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 server=10.88.13.4#53 It still does the same thing. When querying from machine floater, it get forwarded it to 10.88.13.4 Any other suggestions? Could there be something else that is being missed? I'm not sure if this is a cut/paste error - but the line looks the same as before with tag: instead of set:.. Also looking at the man page it shows the options in a slighty different order (don't know if that matters). So, it should be: dhcp-host=00:a1:b0:08:61:67,set:red,192.168.13.109,floater dhcp-host=00:c0:a8:be:ed:d0,set:green,192.168.13.110,Ziong -- Daryl Richards Isle Technical Services Inc. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
Yes, that was a cut and paste error. I have simplified the file to make things easier to debug. Here is what it looks like now, I will paste the whole file here port=53 bogus-priv no-resolv local=/localnet/ user=dnsmasq group=dnsmasq interface=enp5s0 listen-address=127.0.0.1,192.168.13.1 expand-hosts domain=irlanet.org dhcp-range=192.168.13.224,192.168.13.255,2h dhcp-authoritative cache-size=0 cname=win-sji,MOEDW1CKH5 log-queries log-dhcp dhcp-host=00:68:eb:3b:32:33,MOEDW1CKH5,set:red,192.168.13.192 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 dhcp-option=option:dns-server,10.88.13.4 server=10.88.13.4#53 Here is how dnsmasq is tested from MODEW1CKH5 [si@MOEDW1CKH5 593]>curl ident.me 97.90.236.142 Here is what shows up in the log files Jul 29 17:26:16 xroads dnsmasq[2612016]: query[A] ident.me from 192.168.13.192 Jul 29 17:26:16 xroads dnsmasq[2612016]: forwarded ident.me to 10.88.13.4 Jul 29 17:26:16 xroads dnsmasq[2612016]: query[] ident.me from 192.168.13.192 Jul 29 17:26:16 xroads dnsmasq[2612016]: forwarded ident.me to 10.88.13.4 Jul 29 17:26:16 xroads dnsmasq[2612016]: reply ident.me is 176.58.123.25 Jul 29 17:26:16 xroads dnsmasq[2612016]: reply ident.me is 2a01:7e00::f03c:91ff:fe70:2b9d Does the order of the statements in the config files matter? On 7/29/2020 2:42 PM, Daryl Richards wrote: On 2020-07-29 2:40 p.m., S Irlapati wrote: Thanks for the quick reply. I have changed it to dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 server=10.88.13.4#53 It still does the same thing. When querying from machine floater, it get forwarded it to 10.88.13.4 Any other suggestions? Could there be something else that is being missed? I'm not sure if this is a cut/paste error - but the line looks the same as before with tag: instead of set:.. Also looking at the man page it shows the options in a slighty different order (don't know if that matters). So, it should be: dhcp-host=00:a1:b0:08:61:67,set:red,192.168.13.109,floater dhcp-host=00:c0:a8:be:ed:d0,set:green,192.168.13.110,Ziong ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
On Wed, Jul 29, 2020 at 03:42:27PM -0400, Daryl Richards wrote: > On 2020-07-29 2:40 p.m., S Irlapati wrote: > > Thanks for the quick reply. > > > > I have changed it to > > > > dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 > > dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 > > > > dhcp-option=tag:red,option:dns-server,10.88.13.3 > > dhcp-option=tag:green,option:dns-server,10.88.13.4 > > server=10.88.13.4#53 > > > > It still does the same thing. > > > > When querying from machine floater, it get forwarded it to 10.88.13.4 > > > > Any other suggestions? Could there be something else that is being missed? > > I'm not sure if this is a cut/paste error - but the line looks the same as > before with tag: instead of set:.. Also looking at the man page it shows the > options in a slighty different order (don't know if that matters). So, it > should be: > > dhcp-host=00:a1:b0:08:61:67,set:red,192.168.13.109,floater > dhcp-host=00:c0:a8:be:ed:d0,set:green,192.168.13.110,Ziong > You are invited to report a "Yes, that works" Groeten Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
dhcp-host=00:a1:b0:08:61:67,floater,set:red,192.168.13.109 > The set: construct sets the tag whenever this *--dhcp-host* > directive is in use. This can be used to selectively send DHCP options > just for this host. More than one tag can be set in a *--dhcp-host* > directive (but not in other places where "set:" is allowed). When > a host matches any *--dhcp-host* directive (or one implied by > /etc/ethers) then the special tag "known" is set. This allows dnsmasq > to be configured to ignore requests from unknown machines using > *--dhcp-ignore=tag:!known* If the host matches only a *--dhcp-host* > directive which cannot be used because it specifies an address on > different subnet, the tag "known-othernet" is set. > > The tag: construct filters which dhcp-host directives are used. > Tagged directives are used in preference to untagged ones. > S Irlapati wrote on 7/29/2020 11:40 AM: > Thanks for the quick reply. > > On 7/29/2020 1:02 PM, Daryl Richards wrote: >> >> The proper syntax on the dhcp-host lines is 'set:red' and 'set:green' >> to set the tags that you then use on the options.. >> > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 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] Incorrect response for DNAME'd records in dnsmasq 2.80+
Indeed, that's the commit that did it. I'm not sure why that change has any effect for DNAMEs, though (which are not being generated internally to dnsmasq)... On Wed, Jul 29, 2020 at 12:07 PM Geert Stappers wrote: > On Wed, Jul 29, 2020 at 11:23:17AM -0700, James Brown wrote: > > I'm upgrading some test nodes in my employer's cluster from 2.78 to 2.82 > > and handling of DNAMEs in the new version seems different (and wrong). > > > > The setup: > > > > local.mycompany.net is a DNAME to local-.mycompany.net, with > > authoritative resolvers in each datacenter serving a different DNAME > record > > prod.mycompany.net is an unrelated domain > > > > /etc/resolv.conf contains the line > > > > search local.mycompany.net prod.mycompany.net > > > > Imagine searching for the bare-word "foo", which is defined in > > prod.mycompany.net but nowhere else. > > > > Under dnsmasq 2.78, querying for the bare name "foo" using the system > > resolver will correctly first attempt to query for " > foo.local.mycompany.net", > > get back a DNAME to foo.local-dcname.mycompany.net, then get an empty > > response with the NXDOMAIN code; that will fail, and glibc will then > query " > > foo.prod.mycompany.net", which is the correct record. > > > > Under dnsmasq 2.82, querying for the bare name "foo" using the system > > resolver will correctly first attempt to query for " > foo.local.mycompany.net", > > get back a DNAME to foo.local-dcname.mycompany.net, gets back an empty > > response with the NOERROR code. This causes the system resolver to stop > > trying new search domains. This behavior seems to be dependent on > caching; > > the first request correctly returns NXDOMAIN but subsequent requests > return > > NOERROR. There's actually something more confusing to it than this; if > the > > first request is for A, then subsequent requests return NOERROR but > > subsequent A requests return NXDOMAIN. Some kind of weird cache poisoning > > between record types? > > > > I bisected this in git and this behavioral change was introduced in > > commit b6f926fbefcd2471699599e44f32b8d25b87b471. > > $ git log b6f926fbe...b6f926fbe^1 > commit b6f926fbefcd2471699599e44f32b8d25b87b471 > Author: Simon Kelley > Date: Tue Aug 21 17:46:52 2018 +0100 > > Don't return NXDOMAIN to empty non-terminals. > > When a record is defined locally, eg an A record for one.two.example > then > we already know that if we forward, eg an query for > one.two.example, > and get back NXDOMAIN, then we need to alter that to NODATA. This is > handled > by check_for_local_domain(). But, if we forward two.example, because > one.two.example exists, then the answer to two.example should also be > a NODATA. > > For most local records this is easy, just to substring matching. > for A, and CNAME records that are in the cache, it's more > difficult. > The cache has no efficient way to find such records. The fix is to > insert empty (none of F_IPV4, F_IPV6 F_CNAME set) records for each > non-terminal. > > The same considerations apply in auth mode, and the same basic > mechanism > is used there too. > > > Regards > Geert Stappers > -- > Silence is hard to parse > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- James Brown Engineer ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Incorrect response for DNAME'd records in dnsmasq 2.80+
On Wed, Jul 29, 2020 at 11:23:17AM -0700, James Brown wrote: > I'm upgrading some test nodes in my employer's cluster from 2.78 to 2.82 > and handling of DNAMEs in the new version seems different (and wrong). > > The setup: > > local.mycompany.net is a DNAME to local-.mycompany.net, with > authoritative resolvers in each datacenter serving a different DNAME record > prod.mycompany.net is an unrelated domain > > /etc/resolv.conf contains the line > > search local.mycompany.net prod.mycompany.net > > Imagine searching for the bare-word "foo", which is defined in > prod.mycompany.net but nowhere else. > > Under dnsmasq 2.78, querying for the bare name "foo" using the system > resolver will correctly first attempt to query for "foo.local.mycompany.net", > get back a DNAME to foo.local-dcname.mycompany.net, then get an empty > response with the NXDOMAIN code; that will fail, and glibc will then query " > foo.prod.mycompany.net", which is the correct record. > > Under dnsmasq 2.82, querying for the bare name "foo" using the system > resolver will correctly first attempt to query for "foo.local.mycompany.net", > get back a DNAME to foo.local-dcname.mycompany.net, gets back an empty > response with the NOERROR code. This causes the system resolver to stop > trying new search domains. This behavior seems to be dependent on caching; > the first request correctly returns NXDOMAIN but subsequent requests return > NOERROR. There's actually something more confusing to it than this; if the > first request is for A, then subsequent requests return NOERROR but > subsequent A requests return NXDOMAIN. Some kind of weird cache poisoning > between record types? > > I bisected this in git and this behavioral change was introduced in > commit b6f926fbefcd2471699599e44f32b8d25b87b471. $ git log b6f926fbe...b6f926fbe^1 commit b6f926fbefcd2471699599e44f32b8d25b87b471 Author: Simon Kelley Date: Tue Aug 21 17:46:52 2018 +0100 Don't return NXDOMAIN to empty non-terminals. When a record is defined locally, eg an A record for one.two.example then we already know that if we forward, eg an query for one.two.example, and get back NXDOMAIN, then we need to alter that to NODATA. This is handled by check_for_local_domain(). But, if we forward two.example, because one.two.example exists, then the answer to two.example should also be a NODATA. For most local records this is easy, just to substring matching. for A, and CNAME records that are in the cache, it's more difficult. The cache has no efficient way to find such records. The fix is to insert empty (none of F_IPV4, F_IPV6 F_CNAME set) records for each non-terminal. The same considerations apply in auth mode, and the same basic mechanism is used there too. Regards Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
On 7/29/20 1:21 PM, S Irlapati wrote: dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 server=10.88.13.4#53 The above does not work. I can make query from floater and it still uses sever 10.88.13.4 what happens if you move the server line higher? do the others override it, then? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
Thanks for the quick reply. I have changed it to dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 server=10.88.13.4#53 It still does the same thing. When querying from machine floater, it get forwarded it to 10.88.13.4 Any other suggestions? Could there be something else that is being missed? On 7/29/2020 1:02 PM, Daryl Richards wrote: On 2020-07-29 1:21 p.m., S Irlapati wrote: dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 server=10.88.13.4#53 The above does not work. I can make query from floater and it still uses > sever 10.88.13.4 The proper syntax on the dhcp-host lines is 'set:red' and 'set:green' to set the tags that you then use on the options.. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Incorrect response for DNAME'd records in dnsmasq 2.80+
I'm upgrading some test nodes in my employer's cluster from 2.78 to 2.82 and handling of DNAMEs in the new version seems different (and wrong). The setup: local.mycompany.net is a DNAME to local-.mycompany.net, with authoritative resolvers in each datacenter serving a different DNAME record prod.mycompany.net is an unrelated domain /etc/resolv.conf contains the line search local.mycompany.net prod.mycompany.net Imagine searching for the bare-word "foo", which is defined in prod.mycompany.net but nowhere else. Under dnsmasq 2.78, querying for the bare name "foo" using the system resolver will correctly first attempt to query for "foo.local.mycompany.net", get back a DNAME to foo.local-dcname.mycompany.net, then get an empty response with the NXDOMAIN code; that will fail, and glibc will then query " foo.prod.mycompany.net", which is the correct record. Under dnsmasq 2.82, querying for the bare name "foo" using the system resolver will correctly first attempt to query for "foo.local.mycompany.net", get back a DNAME to foo.local-dcname.mycompany.net, gets back an empty response with the NOERROR code. This causes the system resolver to stop trying new search domains. This behavior seems to be dependent on caching; the first request correctly returns NXDOMAIN but subsequent requests return NOERROR. There's actually something more confusing to it than this; if the first request is for A, then subsequent requests return NOERROR but subsequent A requests return NXDOMAIN. Some kind of weird cache poisoning between record types? I bisected this in git and this behavioral change was introduced in commit b6f926fbefcd2471699599e44f32b8d25b87b471. -- James Brown Engineer ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] multiple upstream servers
Hi Folks, I am trying to configure dnsmasq to selectively send requests to different upstream servers based on their IP addresses which have been given by them by dnsmasq. Here are the relevant lines of code. dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 dhcp-option=tag:red,option:dns-server,10.88.13.3 dhcp-option=tag:green,option:dns-server,10.88.13.4 server=10.88.13.4#53 The above does not work. I can make query from floater and it still uses sever 10.88.13.4 If the server option is taken out, then dnsmasq does not forward the queries anywhere. It is like the dhcp-option has no effect. I came with this kind of configuration by doing google searches, but they were 7 year old posts. Can someone please help find the right configuration or guess what could be wrong with the configuration? Sam ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
