<div dir="ltr">I don't think what you are seeing is normal and to me it's all hinting at something local. I feel that there is something common to all your setups causing this. I don't think it's the upstream DNS providers.<div><br></div><div>One thing that pops to mind is UDP packet fragmentation. Perhaps there is something in the network setup or filtering (iptables) which is causing UDP packets to fragment but is dropping the second part of the fragment? This is a surprisingly common problem on a lot of firewalls, for example Sonicwall. Perhaps force dig to use TCP to see if the results are different (dig +tcp <host>).<div><br></div><div>That's just one possibility among many. Swap out one of the machines for a totally different system (Windows laptop maybe?) and repeat the tests. If you don't get the same failure rate while on the same connection, then you know it's your setup.</div></div><div><br></div><div>John</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 5:42 PM, Trevor Cordes <span dir="ltr"><<a href="mailto:trevor@tecnopolis.ca" target="_blank">trevor@tecnopolis.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Further, during additional tests while capturing with tcpdump and<br>
visualizing with wireshark, tcpdump consistently tells me it is<br>
dropping 10-45 packets out of around 1200 it seems to capture to dig<br>
+short just 2 domains in a 5s test. Is that level of drop normal? I<br>
couldn't get a single capture that didn't have drops. Is this just<br>
tcpdump not keeping up, or are these drops also not making it to BIND<br>
itself?? (Though I tested and the same # of drops occur on the "good"<br>
domains too.)<br>
<br>
Also, to rule out iptables I added an accept all rule for --sport 53<br>
(udp and tcp) super early in my external interface chain. Didn't help<br>
one bit. But I'm now 99% sure it's not iptables.<br>
<br>
I found 4 surprising things in wireshark:<br>
<br>
1. After rndc flushing it takes about 600 packets to resolve one dinky<br>
domain name?? Wow!<br>
<br>
2. AAAA records are coming across the wire, in fact they outnumber A<br>
records. I have ipv6 as "turned off"/blocked on a modern linux box as<br>
you can, so I'm not sure why AAAA is showing up, but I guess it's<br>
neither here nor there as long as the A's are coming back ok. They<br>
certainly add a bucket of useless packets to the 600 total though.<br>
<br>
3. Looks like I'm getting back (must be automatic) dns sec stuff in<br>
some of these packets. I don't have any of that configured in my BIND<br>
config, so unless it "just works" with no new config lines, it probably<br>
is just being ignored.<br>
<br>
4. There's a fair amount of TCP port 53 traffic going on! My guess<br>
would have been it was all limited to UDP. Guess I'm behind the<br>
times...<br>
<br>
<br>
Not sure if any of these revelations sheds any light.<br>
_______________________________________________<br>
<div class="HOEnZb"><div class="h5">Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" rel="noreferrer" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">John Lange<br><a href="http://www.johnlange.ca" target="_blank">www.johnlange.ca</a></div>
</div>