Truncated DNS results cause issues

[spf-tools]

Truncated DNS results cause issues

[jsarenik]

Thanks much for reporting this issue. What do you think about using drill instead of dig?

[jsarenik]

@jcbf what do you think about replacing dig for drill?

[lacostej]

@jsarenik I forgot to say: I am on a Mac, and dig is available by default.

[jsarenik]

@lacostej sure. I have Mac too. drill can be installed using http://brew.sh/ by running brew install ldns.

The thing with +tcp in dig is that some servers (particularly cloudflare.com) do not answer TCP DNS request at all so I think we do not want to use +tcp by default with dig.

As for drill I will need to add option -a by default (from man 1 drill):

  -a     Use the resolver structure's fallback mechanism if the answer is
         truncated  (TC=1).  If  a  truncated packet is received and this
         option is set, drill will first send  a  new  query  with  EDNS0
         buffer size 4096.

         If  the  EDNS0 buffer size was already set to 512+ bytes, or the
         above retry also results in a  truncated  answer,  the  resolver
         structure will fall back to TCP.

[lacostej]

Another idea: by default dig shouldn't need +tcp argument. It retries with TCP upon truncated.

The dig output looks like this:

;; Truncated, retrying in TCP mode.
dns14.ovh.net.
ns14.ovh.net.
HI: dns14.ovh.net.
ns14.ovh.net.

And the following patch fixes it:

@@ -24,7 +25,7 @@ findns() {
       break 1
     }
   done
-  echo "$ns" | grep .
+  echo "$ns" | grep -v "retrying in TCP mode" | grep .
 }

 # printip <<EOF

The filtering could be more focused on the comments maybe and moved to a different place in the code.

Maybe better to support this auto-retry mode than to add dependency to a new tool ?

[jcbf]

Hi all, sorry I was away and here is my delayed 0.02€.

1. Regarding drill vs dig. I think drill is not broadly available by default or minimal Linux distros. I would stay away for that unless it is really necessary.

2. Regarding the TCP issue I think supporting tcp should be considered carefully. RFC strongly discourages the use of TCP in SPF records by keep them bellow 512 bytes ( http://tools.ietf.org/html/rfc7208#section-3.4 ). I think @lacostej is doing too many tests against google servers and is being throttled* . If you hit directly a resolver instead of a authoritative that shouldn't happen.

That said I would consider the following:

a) add an option to hit the default resolver instead of going to the authoritative
b) force a specific resolver
c) use

-  echo "$ns" | grep .
+  echo "$ns" | grep NS

*to prevent ddos and/or amplifications attacks rate limiting dns requests on authoritative servers is done by activating the TC flag. That causes retries in TCP and explains why only fails 1 out of 3 tries.

[stevejenkins]

+1 to using dig over drill. dig is far more widely distributed, and since I have a project that is dependent on spf-tools, I'd prefer to avoid an additional dependency.

[jsarenik]

Thank you all for feed-back! I appreciate it. Anyway, the experiment on the drill branch was worth I think and I will backport the changes to dig version. I will also incorporate the change to allow for seamless output even when TCP is used.