É permitido definir um registro DNS A vazio/em branco?

É permitido definir um registro DNS A vazio/em branco?

Estou tentando entender o mundo maravilhoso do DNS.

Criei um arquivo de zona para example.com que contém:

@     A    1.2.3.4
*     A    1.2.3.4

No entanto, também estou configurando meu DNS local, local.example.com, no qual criei um arquivo de zona separado para conter o seguinte:

machine1     A    192.168.0.1
machine2     A    192.168.0.2

Quando eu cavo machine1.local.example.com ele retorna um registro 192.168.0.1, ótimo.

Infelizmente, badmachine.local.example.com retorna 1.2.3.4, assim como local.example.com.

Não tenho certeza da melhor maneira de evitar isso. Se eu adicionar o seguinte aos registros A vazios local.example.com serão retornados para os 2 exemplos acima, conforme é o comportamento que desejo:

@     A
*     A

Quero que qualquer coisa.example.com use o curinga, EXCETO qualquer coisa no subdomínio local.example.com que não desejo dar uma resposta, a menos que especificado. Essencialmente, preciso de um curinga com uma exclusão.

Isso é permitido? Esta é uma prática recomendada ou estou fazendo coisas terrivelmente erradas? Estou usando PowerDNS com back-end BIND.

Obrigado por seus pensamentos!

Responder1

Em primeiro lugar, seu comentário para Chris S acima esclarece (na verdade, modifica) consideravelmente sua pergunta original, e espero que você me perdoe por editá-lo em sua pergunta original.

Em segundo lugar, os registros nulos não são permitidos, como outros observaram.

Terceiro, acho que a maneira de fazer o que você deseja é declarar local.example.comum subdomínio adequado:

local                       IN      NS      ns1.example.com
local                       IN      NS      ns2.example.com

listando os mesmos dois servidores de nomes que você executa atualmente para example.com (nota: não conheço PowerDNS, então minhas entradas acima estão no formato BIND). Então, nesses servidores de nomes (que presumo ser este servidor de nomes), você declara um arquivo de zona para local.example.com que contém apenas os hosts que você deseja resolver e nenhum registro curinga.

Então, quando as pessoas procurarem foo.example.com, supondo que não esteja listado, ele corresponderá ao registro curinga existente e retornará 1.2.3.4(ou qualquer outra coisa). Mas quando as pessoas procurarem foo.local.example.com, os registros do servidor de nomes local.example.comserão retornados e uma nova recursão ocorrerá, com seu servidor de nomes agora olhando para o arquivo de zona para local.example.come dizendo (na ausência de um registro específico para fooeum curinga em local.example.com) "não, esse registro não existe".

Responder2

Seria útil saber exatamente quais respostas você procura. As duas primeiras linhas citadas na sua pergunta definem a resposta padrão para o domínio e também a resposta do registro incomparável. Portanto, example.com será atendido pelo registro "@" e qualquer coisa que não exista.exmaple.com será atendido pelo registro "*". Eles não são necessários, você pode se livrar de ambos. Defini-los com valores em branco é uma configuração inválida (na maioria dos sistemas).

Responder3

Não consigo pensar em uma maneira de "anular" uma entrada. Registros A vazios não são permitidos.

Talvez *.example.com A 1.2.3.4impediria a substituição das entradas .local.example.com? Parece que o PowerDNS está se comportando mal de acordo com as especificações. Ter o domínio local.example.com definido deve evitar que o curinga pise em qualquer coisa nesse domínio. Você pode postar arquivos de zona completa? Isso resolveria uma série de pequenas questões.

Responder4

Você deve observar o comportamento específico do servidor que está executando, pois esse recurso não foi implementado de forma consistente:

Citando a RFC 4592, muitas implementações de DNS divergem, de maneiras diferentes, da definição original de curingas.

Curingas na prática

O que você deseja que a entrada do curinga faça está correto, pois entendo a definição do uso do curinga (é melhor pensar nisso como um valor padrão de último recurso). Tentarei encontrar tempo para ler o RFC esclarecedor e atualizá-lo aqui...

informação relacionada