<div dir="ltr">Ok, thanks - that makes sense in terms of the 'incomplete' entry being cached.<br><div><br></div><div>I might set up a couple of dns servers to simulate this at some point - I'm going to want a reproducible setup for our own testing as well...  If I can then I'll come back with that log...</div><div><br></div><div>Actually, maybe I already have it, let me check...</div><div>Nope - I have that up to the dnsmasq restart, not the software restart.</div><div><br></div><div>Cheers,</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Apr 2019 at 16:27, Simon Kelley <<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 30/03/2019 08:41, John Robson wrote:<br>
> Simon,<br>
> <br>
> The upstream server is authoritative for the initial domain (being<br>
> inside an organisation I don’t think that’s unusual) and the incomplete<br>
> (but perfectly valid, I agree) response is taken as complete. The<br>
> upstream server does do recursion as well, but when that failed it just<br>
> returned what it could (seems reasonable enough).<br>
> <br>
> I’d have thought that the lack of an actual resolved A record (which is<br>
> what was asked for) would mark the cache entry as incomplete at best.<br>
> This is pure gut, not a technically based statement.<br>
<br>
A CNAME reply with no record for the target of the CNAME, from a<br>
recursive server, establishes that the target doesn't exist. If it were<br>
otherwise, there would be large numbers of legitimate answers which are<br>
uncachable. Consider that there are many record types and the target of<br>
a CNAME will not exist for most record types.<br>
<br>
As a common example, an IPv6 enabled host will query for the AAAA record<br>
of something it wants to talk to. If hostname is a CNAME, and the thing<br>
it want's to talk to doesn't have an AAAA record, then the reply will be<br>
a CNAME with no target. You really want to be able to cache that.<br>
<br>
<br>
> <br>
> And whilst I agree that the record was cached (and that that is probably<br>
> technically correct) I can’t then explain why dnsmasq stopped using the<br>
> cache when I restarted my program - with 45+ minutes of cache left,<br>
> dnsmasq went back to the upstream server and got a complete answer.<br>
> <br>
> Restarting dnsmasq obviously reset the cache, and everything recovered<br>
> when I did that - but restarting other software shouldn’t have magically<br>
> reset the cache, and yet it did.<br>
<br>
<br>
I can't explain that. If it's reproducible, run dnsmasq with<br>
--log-queries set and see exactly what's going on.<br>
<br>
<br>
> <br>
> (Un)Fortunately the second/third nameservers seem to be being better<br>
> behaved at the moment, so we haven’t seen the incomplete response in<br>
> several days - kind of makes it harder to test though.<br>
<br>
Not reproducible, then. That's a pity.<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
> <br>
> Cheers,<br>
> <br>
> John<br>
> <br>
> <br>
> <br>
> On Fri, 29 Mar 2019 at 22:43, Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>>> wrote:<br>
> <br>
>     On 21/03/2019 11:01, John Robson wrote:<br>
>     > OK,<br>
>     ><br>
>     > Maybe this does reveal something about the caching...<br>
>     > Which might be expected behaviour, but I am not convinced it's<br>
>     useful...<br>
>     ><br>
>     > Overnight monitoring has shown that the upstream server does<br>
>     > occasionally send back an incomplete (but perfectly valid) CNAME only<br>
>     > response.  Mostly I can justify the caching behaviour based on the<br>
>     TTLs<br>
>     > of the second CNAME or A record (the server is authoritative for the<br>
>     > first CNAME, so that's always at 3600).<br>
>     ><br>
>     > As a slight aside:<br>
>     > dnsmasq sends a query at 22:57:32.599, then again (new transaction id)<br>
>     > at 22:57:33.601, and at 22:57:36.601.<br>
>     > This last query gets a response in 0.1 seconds, both the others<br>
>     > eventually come in (incomplete) at 22:57:44.073<br>
>     > I am assuming that dnsmasq ignored these late arrivals (either due<br>
>     to a<br>
>     > default timeout, or just because a better answer has been received -<br>
>     > this would be comparable with behaviour when it queries multiple<br>
>     servers<br>
>     > to decide which is 'best').<br>
>     > In this case we are protected by the fact that the incomplete query<br>
>     > takes far longer than the complete one due to timeouts.<br>
>     ><br>
>     > Later though:<br>
>     > At 01:12:47 we are out of TTL, so send a request, and get an<br>
>     incomplete<br>
>     > response... The response only contains the first CNAME, which has<br>
>     a 3600<br>
>     > TTL.<br>
>     ><br>
>     > Then dnsmasq doesn't send another query for an hour - despite the fact<br>
>     > that it doesn't have a "good" answer.<br>
>     > In this case the query it sends after an hour gets incomplete response<br>
>     > again - not good.<br>
>     > Then I lost track because the container got moved to a different<br>
>     host -<br>
>     > but it looks like it was returning incomplete for several hours...<br>
>     ><br>
>     ><br>
>     > dnsmasq is otherwise well behaved - it is still responding to other<br>
>     > queries just fine, despite being hammered by more than 2k<br>
>     queries/second<br>
>     ><br>
>     > Two questions:<br>
>     >  - Is it correct/wanted behaviour to cache an incomplete record<br>
>     like this?<br>
>     > I have no issue caching the cname, but should we keep trying to<br>
>     resolve<br>
>     > the cname to an a record?<br>
>     ><br>
>     >  - Why/How does a restart of the querying program change the caching<br>
>     > behaviour of dnsmasq?<br>
>     > Because even if the program is restarted after just a few minutes it<br>
>     > immediately gets better data - my capture from yesterday shows that<br>
>     > despite the fact that the TTL had 2855 seconds (of the 3600 default)<br>
>     > left just two minutes before the first 'new process' request comes in,<br>
>     > that new request triggers an outbound query.<br>
>     ><br>
>     ><br>
>     > Cheers,<br>
>     ><br>
>     > John<br>
>     ><br>
> <br>
>     What's you're calling an "incomplete" answer is actually a perfectly<br>
>     good answer. Dnsmasq is entitled to infer that the target of the CNAME<br>
>     doesn't exist if it's not included in the answer, and keep that<br>
>     information in the cache for the the TTL  period.<br>
> <br>
>     Note that is _only_ true if the the upstream server is a recursive<br>
>     server - as such it's expected to attempt the follow the CNAME and<br>
>     return as much of the chain as exists. If the upstream server is an<br>
>     authoritative server, that's not true - if the CNAME target is outside<br>
>     the domain(s) that the server is authoritative for, then the target will<br>
>     not be included. This is one reason why dnsmasq should only use<br>
>     recursive servers, an it will log an error if an upstream server is not<br>
>     recursive (ra flag not set). It's also the most common reason why people<br>
>     see the dnsmasq behaviour you're describing.<br>
> <br>
> <br>
> <br>
>     Cheers,<br>
> <br>
>     Simon.<br>
> <br>
> <br>
>     _______________________________________________<br>
>     Dnsmasq-discuss mailing list<br>
>     <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
>     <mailto:<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a>><br>
>     <a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><span style="font-size:12px"><strong>John Robson<br>
Sr. Customer Support Engineer</strong></span><strong><strong style="font-size:12px"><span style="font-family:helvetica">, <span style="color:rgb(255,102,0)"><a href="https://www.zenoss.com/" style="color:rgb(255,102,0)" rel="nofollow" target="_blank">Zenoss</a></span></span></strong></strong><br>
<span style="font-size:12px"><a href="mailto:jrobson@zenoss.com" rel="nofollow" target="_blank">jrobson@zenoss.com</a> | <strong>O:</strong> <br>
<br>
<a href="https://www.zenoss.com/resources/gartner-market-guide-it-infrastructure-monitoring-tools" rel="nofollow" target="_blank"><img alt="" height="72" src="https://storage.googleapis.com/signaturesatori/customer-C037uqfsj/images/4ff6690fc1da92c198a6e80a5cf22bddf76979965ecda99d11689d33ab31cefb.png" width="360"></a><br>
</span></div>