DNS
Monitorização DNS
Que resolve, e que a resposta é exatamente o que esperas que seja.
Experimenta agora
Uma verificação, de um lugar, agora mesmo, e nada é guardado. Um monitor verifica de todas as localizações onde operamos e confirma uma falha a partir de dois outros continentes antes de alguém ser acordado, algo que uma única verificação não pode mostrar.
Para que serve
Todos os outros testes nesta lista dependem do DNS, e o DNS é a única coisa que pode falhar enquanto tudo o que aponta está perfeitamente saudável. Uma transferência de zona que correu mal, um painel de registo que alguém editou, uma delegação expirada: o site está online e inacessível.
A falha que vale a pena pagar é mais específica do que isso. Um registo pode resolver rapidamente, de todos os resolvers, e apontar para o endereço de outra pessoa. Nada que verifique se o DNS responde vai alguma vez ver isso. Dá-nos a resposta que esperas e verificamos isso em vez disso.
Como cada verificação aqui, corre a partir de Amsterdam, New York, Sydney and Singapore, e uma falha é confirmada a partir de dois outros continentes antes de alguém ser acordado. Como funciona isso.
O que podes configurar
Tudo abaixo está no formulário quando adicionas um, em todos os planos.
- Registo
- A, AAAA, MX, TXT, NS, CNAME ou SOA.
- Resposta esperada
- Em branco verifica se o nome resolve de todo. Preenchido, verifica se a resposta ainda está certa, que é a falha que nada mais deteta.
- Corresponder
- Qualquer um deles ou exatamente estes. Exatamente estes é a única forma de perceber que um registo foi adicionado em vez de alterado.
- Perguntar a este resolver
- Define o teu próprio servidor autoritativo e vês a alteração no momento em que é feita, em vez de esperar que o resolver que usamos expire a sua cache.
Perguntas
Que tipos de registo podes monitorizar?
A, AAAA, CNAME, MX, TXT, NS e SOA estão no formulário, e CAA, PTR e SRV também são aceites. A lista é deliberadamente mais curta do que tudo o que o DNS pode conter: cada um aqui é um registo cuja alteração é algo que um cliente notaria, sendo o único tipo que merece um alerta.
Qual é a diferença entre NXDOMAIN e SERVFAIL?
NXDOMAIN significa que o nome não existe: um erro de digitação, um registo apagado ou uma delegação que expirou. SERVFAIL significa que os nameservers foram consultados e nenhum deles deu uma resposta utilizável, o que indica uma zona quebrada ou servidores offline. Um terceiro caso, o nome existir sem registo desse tipo, é reportado separadamente, porque os três têm soluções diferentes.
Consegues dizer-me se uma alteração foi propagada?
Parcialmente, e vale a pena ser preciso sobre o que é propagação: nada se espalha, as caches simplesmente expiram ao seu próprio ritmo. As verificações são feitas a partir de três continentes, então uma alteração que chegou a um e não a outro aparece como uma discrepância. Define o teu próprio servidor autoritativo e vês a alteração no momento em que é feita.
Isto detetaria um ataque de DNS hijack?
É para essa falha que existe. Um registo pode resolver rapidamente, de qualquer resolver, com um TTL saudável, e apontar para o endereço de outra pessoa; nada que apenas pergunte se o DNS respondeu irá detetá-lo. Preenche a resposta que esperas e um registo que aponte para outro lugar falha dentro de um intervalo.
Verificas o TTL ou validas o DNSSEC?
Não, e dizemos isso em vez de sugerir o contrário. O TTL é o que a tua zona define e isto não o verifica, e as assinaturas DNSSEC não são validadas. O que é verificado é a resposta que volta e se ainda é a que esperas, que é a falha que o resto da tua monitorização não consegue ver.
O que faz a correspondência exata que a correspondência qualquer não faz?
Qualquer um deles passa quando o valor esperado está em algum lugar na resposta, que é o que queres para um nome atrás de um pool de endereços. Exatamente estes falham quando algo foi adicionado, e adicionar é como o dano geralmente chega: um registo A extra ou um MX extra ao lado do teu é deteção de alteração de registo que nada mais apanha.
Por que não usar dig num script?
Podes, e para verificar um registo uma vez é a ferramenta certa. A dificuldade é que não existe algo como a resposta: o que o teu resolver retorna e o que um resolver em Sydney retorna podem diferir durante o tempo de um TTL, e um script numa máquina a perguntar a um resolver vê apenas uma dessas respostas. Isto pergunta a partir de quatro continentes e pode ser direcionado para um resolver específico, o que transforma uma consulta numa comparação.
O meu registo envia-me emails quando um registo muda. Isso não é suficiente?
Mantém, é uma verificação real e é a forma mais rápida de descobrir que alguém da tua equipa mudou algo. O que cobre é o caso em que a alteração passou pelo teu registo, que é o que menos te preocupava. Não diz nada quando um registo é alterado num fornecedor que também usas, quando uma transferência de zona falha, ou quando um resolver em algum lugar retorna algo que o teu registo nunca publicou. Essas são as falhas que parecem que nada está errado.