Re: [Dnsmasq-discuss] No caching unless recursion enabled?
> /* Don't put stuff from a truncated packet into the cache. > Don't cache replies from non-recursive nameservers, since we may get a > reply containing a CNAME but not its target, even though the target > does exist. */ > if (!(header->hb3 & HB3_TC) && > !(header->hb4 & HB4_CD) && > (header->hb4 & HB4_RA) && > !no_cache_dnssec) >cache_end_insert(); > Removing the > (header->hb4 & HB4_RA) && > line will provide the behaviour you're seeking. I don't propose to make this change in the distributed dnsmasq code. I'd suggest adding a comment to the end of that line that reminds anyone what removing it does (and then not removing the line but commenting it out). Brad ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] prevent dnsmasq from releasing IPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not directly. If you just want a record of leases after they've been released, then you can save information by using the dhcp-script function. If you want to stop re-use of the addresses, then the best you can easily do is to allocate static addresses to clients. That will stop the addresses being allocated to other clients, even when not leased. Cheers, Simon. On 25/01/16 16:42, Stefan Priebe - Profihost AG wrote: > Hi, > > is there any way to keep IPs in the dnsmasq DB even the host sends > a release? > > I want to keep those entry at least for 2 more days. > > Greets, Stefan > > ___ Dnsmasq-discuss > mailing list Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJWpp+TAAoJEBXN2mrhkTWiBNgP/j/c9SlvhOCHkp1sR5zomVj2 Yc7v5W97Emq6Z/vu63iLVHDx3KfaVa4a2o/yup7LmeURAKs/+bGvcH12CItbTKzS Ky8dvdbX6q3KZSxMT+gvC7BdpDKIlzGzwrbpX4SlRoc7BBW7e2JyIU1c9PwOsxYh 17fH4Cf2FK8IGtjz5ypDvv+0oemjeUaJnRYmNuNqU3Kqb7A4QJTxY4PaYFDuZNif x7ECTRAO7T7I8yaCyDWDwG+jyzJif90uvsfWwiU21jxBlfbXyzfpdzPiWziG98MV cKoj5E2GDTCl/F1BCJ0xqf21admWDscB26i4CiLs+iROZ5mUt5a3EE3o2IxBKXIe wNHSJu25kwyWnIHyDvGrqsFPUYDVhu+gbgBrg+ZQA7KngboDTjtq2noMxKvbTsDt m7qWEgifxbVYTHbWTx4EhWhyIY4IjwbDLBV220qK7LFda06OliC805pHN9HxWgBZ jHlK41LL6nJy0MmdPo3mJIl1JTKhfpEMIxDxeVg7fQtsffxg4dhbyOlOi9qv2K3H TaviDLCdWkqXkbzC3OjoteXG2oNeMiTSaG2UuvVxDjtZrdKPpiznS9jWrcWB6Ntb 8AXAIMWE6xuRVSYlhuPn+VbQ14XQAGL3XFCuXB9HVTvV4VyoOtyggzweJUNLSzJ+ S4t6lZzOiAlCAoJ26nTp =3Jfp -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Regression: dnsmasq replies to forwarded query too early when receiving REFUSED response from upstream server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Patch applied. Many thanks. Simon. On 25/01/16 02:27, Chris Novakovic wrote: > Treat REFUSED (not SERVFAIL) as an unsuccessful upstream response > > Commit 51967f9807665dae403f1497b827165c5fa1084b began treating > SERVFAIL as a successful response from an upstream server (thus > ignoring future responses to the query from other upstream > servers), but a typo in that commit means that REFUSED responses > are accidentally being treated as successful instead of SERVFAIL > responses. > > This commit corrects this typo and provides the behaviour intended > by commit 51967f9: SERVFAIL responses are considered successful > (and will be sent back to the requester), while REFUSED responses > are considered unsuccessful (and dnsmasq will wait for responses > from other upstream servers that haven't responded yet). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJWppnwAAoJEBXN2mrhkTWi+NgQAJkG8EvEPajSZT3b2Uo5j0dF 0FisYp1Xcu6t+u84A5R2NGOTn/pWAcjA2b5Ddx7PYq/3V5p2GSdIDYKCVDmKOrWj dhkSE9B1eQlP/E15bfxhZ85fY0Bf2nh3/2qVdOU6fU8L4C92h6/0v0FlYit4gP+3 cT1BUEEkJh4Tx78YW8TvWscmi6UPpTcjEd8Rrm2BHmL/CIc5OqqjhE8xrTamrVBd 6jBhFe48O9nTxyzePufsBnzL/Pd8t+qi4isPFzCeh8PGm9zYR0rjhyMzGYvsQvQC hGeNYT7FdhuxhvItsRPYO7I6d1EG7EBHazjbYPitjsK3Dw7vcC4qLx2PnHBZqmuy yUqYGCMQnb7l+1zexRMyhL5GsVsnu/webprceOsqlk8rIID0SzBBkb9OnMgsLcQv mKV1rmr7UcysARaLjNGXmP51Una+CEISiXx3noymIGPQ2aa2S0pPxihlWxWXAiFp plHmVmQQWNPMh+2Vu/+7UTSphHonFVT1qK8yM254lS3v2pXIVqnNH2tXCfhBp7Mj X2WIr9XDQV4+x598UdKQnIE4SiRFVpqUcAk1VhRyclZK0EBxuIdJSNoCkI1vnJZi 2y/5vWfGAvwgjbSouzDZSI7GicwfV+fCosvirQ3uCvXba0GsmuJkFFuLR2HYvVf7 oS24geBPqLgwNOY1J5g2 =LWbm -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] No caching unless recursion enabled?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The no-caching behaviour is provided by this code, at the end of
extract_addresses() in rfc1035.c
/* Don't put stuff from a truncated packet into the cache.
Don't cache replies from non-recursive nameservers, since we may
get a
reply containing a CNAME but not its target, even though the target
does exist. */
if (!(header->hb3 & HB3_TC) &&
!(header->hb4 & HB4_CD) &&
(header->hb4 & HB4_RA) &&
!no_cache_dnssec)
cache_end_insert();
Removing the
(header->hb4 & HB4_RA) &&
line will provide the behaviour you're seeking. I don't propose to
make this change in the distributed dnsmasq code.
Cheers,
Simon.
On 24/01/16 22:25, bob tatus wrote:
> Hi Simon,
>
> The records that I am looking up are all A records, no CNAMEs in
> use here, I've confirmed this by performing a dig against the Bind
> server for queries that were missing the cache with recursion
> disabled. Additionally if I perform a tcpdump I can see the
> requests listing as "A?" and "?", while on the named logs show
> "A +" and " +" in the query logs.
>
> Technically the Bind server does have recursion enabled, however
> it is only allowed from a single IP address, that is the IP address
> of a Squid proxy server.
>
> This allows clients in the network to browse the Internet via the
> Squid proxy, as the Squid proxy server will still be able to
> perform recursive DNS queries for random domains on the Internet.
> The point of this configuration is to prevent all other client
> systems in the network from otherwise resolving external DNS, which
> has been done as a security measure.
>
> On the Bind server as soon as I put in the "allow-recursion {
> Squid-IP; };" value, the query log on this Bind server gets
> absolutely smashed due to the amount of DNS queries coming in that
> are no longer being cached. These queries are all for A records of
> other internal systems on the local network, so prime candidates
> for caching.
>
> As soon as I comment this out and restart the named service
> (thereby allowing recursion from any host), the DNS query logs drop
> off completely, as does the tcpdump port 53 traffic, and I can see
> the cache hits of dnsmasq rising quickly.
>
> Thanks.
>
>> To: dnsmasq-discuss@lists.thekelleys.org.uk From:
>> si...@thekelleys.org.uk Date: Sat, 23 Jan 2016 09:24:08 +
>> Subject: Re: [Dnsmasq-discuss] No caching unless recursion
>> enabled?
>>
>
>
> On 21/01/16 23:16, bob tatus wrote:
Hi there,
I've been using Dnsmasq for a few days now with no problems,
it was caching well and helping a lot.
Yesterday I disabled recursive DNS queries on my DNS server
(Bind 9) as this is not required within the environment,
since doing this it appears that the caching is no longer
working correctly.
To test I enabled recursion once more and the cache hit rate
started climbing again and I saw significantly less queries
being logged on the bind server, confirming that this was
the issue.
I've checked the man page but have not found anything about
this? I need to have recursive DNS queries disabled on the
DNS server and still have the clients that use this DNS
server cache the queries received with Dnsmasq.
The DNS server in question is authoritative for the queries
that I want to cache so there should not be any need for
recursive DNS.
Thanks, Robert.
>
> I just looked in the current code, and there's nothing obvious that
> would account for this effect.
>
> I would note that not having recursion available on _any_ server
> used by dnsmasq as an upstream is unwise. It may work but it will
> be fragile. The most obvious case is if you add a CNAME to the
> authoritative zone which points outside it. Dnsmasq will not look
> up the target of the CNAME, it relies on the upstream server to do
> that, and if the upstream server doesn't (because recursion is
> disabled) then you'll get a valid but wrong answer.
>
> Cheers,
>
> Simon.
>
___
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
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCAAGBQJWppuCAAoJEBXN2mrhkTWiLNMP/3aTFmcu3LhuqyStcH7Acv6h
tjM+dQgkbJoMqw5wb3wd/lDXta+obHvMhzweWlGNdtTncpyCto5mDCuAxtdDv5U0
oauJP62UEELY0aPDoZkAi9rmcjuWhvIjfvj/cul0aP4HX+2rjW9pfr3LcUSeIrXL
K5e+GVGMyNIrpK8BjUAkaVZoe3Dg8qFMbBxcuws2xoTRwWm2RPUF5hPk6e1kuztv
yrQOg0cqP452kudCNhoiMPklmYd6FiUmDzqLfqCOUYpTP7aesdFndwjA/85wHvLp
zZZyNBtQTT92mB1/+sZvTugoBG/r+
[Dnsmasq-discuss] prevent dnsmasq from releasing IPs
Hi, is there any way to keep IPs in the dnsmasq DB even the host sends a release? I want to keep those entry at least for 2 more days. Greets, Stefan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] doc: upstream server selection algorithm
Hello All, I would like to make an enhancement request regarding the documentation of the upstream server selection algorithm. I assumed that only the first server is tried if it responds within timeout. However, I noticed in my Dnsmasq log, that Dnsmasq uses both upstream servers. I thought that there may be a problem with the first server, so I started to debug the issue, Unfortunately, Bind 9.9 has no easy configuration option to log DND replies (it only logs them on debug level 4, but that also means a huge level amount of nonrelevant information). Finally tcpdump helped, and I bacame sure that the first upstream server responds timely. On the man page the only relevan info I found about the subject is this: *--all-servers* By default, when dnsmasq has more than one upstream server available, it will send queries to just one server. Setting this flag forces dnsmasq to send all queries to all available servers. The reply from the server which answers first will be returned to the original requester. This description seems to be obsolete. After reading the changelog I noticed another information: Test which upstream nameserver to use every 10 seconds or 50 queries and not just when a query times out and is retried. This should improve performance when there is a slow nameserver in the list. Thanks to Joe for the suggestion. This seems to valid, at least it is plausible. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
