Estou tentando testar alguns servidores de nomes em um nome de domínio. Para isso, criei um script que lê uma lista de servidores de nomes e solicita um nome de domínio.
Algo básico assim:
#!/bin/bash
domain=$1
[ -z $domain ] && read -p "DOMAIN NAME: " domain
namefile="./nameserver"
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"
done
O problema que estou tendo é que, quando Dig
falha, não está redirecionando os erros para null
. Assim, a $IPADD
variável recebe um valor errado.
# CORRECT nameserver
# dig +short @8.8.8.8 google.com A 2> /dev/null
142.250.218.206
# WRONG nameserver
# dig +short @8.8.8.80 google.com A 2> /dev/null
;; connection timed out; no servers could be reached
Se eu testá-lo com um endereço de servidor de nomes errado, ainda recebo uma mensagem de erro, como mostrado acima.
Pelo que entendi, ao redirecionar para null
, ele não deve exibir essa mensagem de erro.
Qualquer ideia?
Obrigado.
Acho que entendi qual é o problema agora. Na verdade... Não é um problema, é um comportamento.
Se eu inserir intencionalmente uma opção inválida, o Dig apresentará um erro de sintaxe.
Se eu fizer o mesmo, mas redirecionando
stderr
paranull
, Dig não me mostra nada.Portanto, parece que o Dig está redirecionando corretamente os erros para
null
, não parastdout
.Agora, se eu inserir um servidor de nomes incorreto ou sem resposta, o Dig realmente me diz que não obteve uma resposta,
connection timed out; no server could be reached
. Dig não vê isso como um erro.Além disso, ele retorna o código 9, que significa " Sem resposta do servidor ". Em outras palavras, nenhum serviço DNS pôde ser alcançado com o servidor de nomes fornecido.
Pelo que entendi, " nenhum servidor pôde ser alcançado " pode não ser a melhor resposta. Talvez mudar o termo
server
paraservice
melhorasse um pouco essa resposta.O comentário @schrodingerscatcuriosity faz mais sentido para mim agora e parece ser uma maneira possível de lidar com a resposta de Dig em meu script. Mas, como a resposta IP real é necessária, redirecionar toda a saída para null (&> /dev/null) não é desejado.
Eu adicionei uma solução alternativa para suprimir a saída de tempo limite.