<div dir="ltr"><div>I ran dig +short <a href="http://gymcan.org">gymcan.org</a> a whole pile of times and it never failed for me. I also ran it directly against the authoritative name server (dig @<a href="http://ns06.domaincontrol.com">ns06.domaincontrol.com</a>. <a href="http://gymcan.org">gymcan.org</a>) with the same result (no failures).</div><div><br></div><div>Also, I monitored it with tcpdump and the packet size is not larger than 72 bytes so fragmentation is unlikely.<br></div><div><br></div><div>I'm still suspicious of the iptables setup. I'd try stopping the firewall entirely (set them all to -ACCEPT and flush the rules) and run the tests again just to fully rule that out.</div><div><br></div><div>I think the thing you need to solve is why are you dropping packets? That isn't normal and since it's spread across multiple servers on different providers, it's most likely your config.</div><div><br></div><div>John</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 12:55 AM, 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">I turned on extreme debug logging on BIND named and triggered a<br>
SERVFAIL and here's what it shows:<br>
<br>
21-Apr-2016 00:44:55.592 client: debug 3: client 127.0.0.1#42594: UDP request<br>
21-Apr-2016 00:44:55.592 client: debug 5: client 127.0.0.1#42594: using view '_default'<br>
21-Apr-2016 00:44:55.592 security: debug 3: client 127.0.0.1#42594: request is not signed<br>
21-Apr-2016 00:44:55.592 security: debug 3: client 127.0.0.1#42594: recursion available<br>
21-Apr-2016 00:44:55.592 client: debug 3: client 127.0.0.1#42594: query<br>
21-Apr-2016 00:44:55.592 client: debug 10: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): ns_client_attach: ref = 1<br>
21-Apr-2016 00:44:55.592 security: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): query (cache) '<a href="http://gymcan.org/A/IN" rel="noreferrer" target="_blank">gymcan.org/A/IN</a>' approved<br>
21-Apr-2016 00:44:55.592 client: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): replace<br>
21-Apr-2016 00:44:55.592 client: debug 3: client @0x7f438001c6a0: udprecv<br>
21-Apr-2016 00:44:56.224 query-errors: debug 1: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): query failed (SERVFAIL) for <a href="http://gymcan.org/IN/A" rel="noreferrer" target="_blank">gymcan.org/IN/A</a> at query.c:7769<br>
21-Apr-2016 00:44:56.224 client: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): error<br>
21-Apr-2016 00:44:56.224 client: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): send<br>
21-Apr-2016 00:44:56.224 client: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): sendto<br>
21-Apr-2016 00:44:56.224 client: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): senddone<br>
21-Apr-2016 00:44:56.224 client: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): next<br>
21-Apr-2016 00:44:56.225 client: debug 10: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): ns_client_detach: ref = 0<br>
21-Apr-2016 00:44:56.225 client: debug 3: client 127.0.0.1#42594 (<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>): endrequest<br>
21-Apr-2016 00:44:56.225 query-errors: debug 2: fetch completed at resolver.c:3658 for <a href="http://gymcan.org/A" rel="noreferrer" target="_blank">gymcan.org/A</a> in 0.632030: SERVFAIL/success [domain:<a href="http://gymcan.org" rel="noreferrer" target="_blank">gymcan.org</a>,referral:2,restart:4,qrysent:2,timeout:0,lame:0,neterr:2,badresp:0,adberr:0,findfail:0,valfail:0]<br>
<br>
Too bad they don't show even more info, but we can still wireshark the details.<br>
<br>
So the error seems to be a "neterr", which bind docs say:<br>
The number of erroneous results that the resolver encountered in<br>
sending queries at the domain zone. One common case is the remote<br>
server is unreachable and the resolver receives an ICMP unreachable<br>
error message.<br>
<br>
But I confirmed no ICMP unreachable came in. "One common case"...<br>
I wonder what the other cases are!<br>
<br>
Aside: I wiresharked making sure to capture ICMP as well and no ICMP<br>
came across during the SERVAIL, so that also helps to exclude<br>
fragmentation issues as they should trigger a ICMP can't-fragment<br>
packet.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
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>