I'm trying to test some nameservers against a domain name. For that, I created a script that reads a list of nameservers and asks for a domain name.

Something basic like this:


[ -z $domain ] && read -p "DOMAIN NAME: " domain


echo "RESULT -  NAMESERVER              DOMAIN                  IP"

for host in $(cat "$namefile"); do
        IPADD=$(dig +short "$host" "$domain" A 2> /dev/null)

        [[ ! -z $IPADD ]] && result="OK" || result="FAIL"

        echo "$result   - Nameserver: $host     - Domain: $domain       - IP answer: $IPADD"

The issue I'm having is that, when Dig fails, it is not redirecting errors to null. Thus, the $IPADD variable receives a wrong value.

# CORRECT nameserver
# dig +short @ google.com A 2> /dev/null

# WRONG nameserver
# dig +short @ google.com A 2> /dev/null
;; connection timed out; no servers could be reached

If I test it with a wrong nameserver address, I still get an error message, like shown above.

As I understand, when redirecting to null, it should not display that error message.

Any idea?

Thank you.

  • The simple answer here is that dig sends errors out to stdout instead of stderr.
    – Hack Saw
    Commented Nov 8, 2022 at 0:11
  • 2
    You could use the return codes instead: dig +short @ google.com A &> /dev/null; [ $? -eq 9 ] && echo 'No reply from server' for example. Commented Nov 8, 2022 at 1:02
  • @HackSaw, It seems that way, indeed. Where can I find that information?
    – markfree
    Commented Nov 9, 2022 at 13:13
  • dig is part of the Bind package, if that's what you mean.
    – Hack Saw
    Commented Nov 9, 2022 at 17:30

1 Answer 1


I think I understand what's the issue now. Actually... Not an issue, a behavior.

If I intentionally input an invalid option, Dig gives me a syntax error.

$ dig @ google.com -A
Invalid option: -A
Usage:  dig [@global-server] [domain] [q-type] [q-class] {q-opt}
            {global-d-opt} host [@local-server] {local-d-opt}
            [ host [@local-server] {local-d-opt} [...]]

Use "dig -h" (or "dig -h | more") for complete list of options

If I do the same, but redirecting stderr to null, Dig shows me nothing.

$ dig @ google.com -A 2> /dev/null

Therefore, it seems Dig is correctly redirecting errors to null, not to stdout.

Now, if I input an incorrect or unresponsive nameserver, Dig actually tells me that it did not get an answer, connection timed out; no server could be reached. Dig does not see that as an error.

Also, it returns code 9, which means "No reply from server". In other words, no DNS service could be reached with the provided nameserver.

As I understand it, "no server could be reached" might not be the best response. Maybe changing the term server to service would enhance that response a bit.

@schrodingerscatcuriosity comment makes more sense to me now and seems to be a possible way to handle Dig's response in my script. But, since the actual IP response is required, redirecting all output to null (&> /dev/null) is not desired.

I've add a work around to suppress the timeout output.

for host in $(cat "$namefile"); do
    IPADD=$(dig +timeout=1 +short "$host" "$domain" A 2> /dev/null)
    echo $IPADD | grep -s -q "timed out" && { IPADD="Timeout" ; result="FAIL" ; }

    echo "$result   - Nameserver: $host     - Domain: $domain       - IP answer: $IPADD"
  • I'm no expert in redirection, but here's an idea: $ dig +short @ google.com A &> /dev/null > /tmp/foo; cat /tmp/foo. Then you process whatever message from /tmp/foo, either error or not. Commented Nov 9, 2022 at 17:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .