Config BIN RPZ com domínios de vários níveis

Question

Eu uso o RPZ para colocar alguns domínios na lista negra e minha configuração se parece com:

*.com A 127.0.0.1
mydomain.net A 127.0.0.1

se eu consultar um domínio qualquer .com ele funciona corretamente me dando 127.0.0.1

vamos dig fun.com @localhost , minha resposta será:

;; ANSWER SECTION:
fun.com.     5       IN      A       127.0.0.1

agora vamos editar a configuração anterior e fazer a minha zona agora parecer:

*.com A 127.0.0.1
mydomain.net A 127.0.0.1
this.fun.com 127.0.0.1

É desnecessário, porque o master *.com deve cobrir todos os casos, mas tenho meus domínios carregados por várias fontes, então a lista é compilada automaticamente e coisas assim podem acontecer.

Embora isso pareça ser uma alteração inofensiva, e se eu fizer dig this.fun.com @localhost , ele responderá novamente, como:

;; ANSWER SECTION:
this.fun.com.     5       IN      A       127.0.0.1

Se eu agora consultar o domínio raiz dig fun.com @localhost , obtenho:

;; ANSWER SECTION:
fun.com.                86400   IN      A       209.61.131.188

Como ... WHAAT? O que aconteceu aqui? adicionando this.fun.com mascarado fun.com do domínio principal do superior omni-inclusive *.com ?

Este é um comportamento desejado do bind? Eu encontrei algum tipo de bug estranho?

Como pode evitar isso? Devo escrever um script que recurse todos os domínios removendo os contidos nos maiores? (chato mas factível - em busca de melhores alternativas)

TL; DR: Adicionar um domínio de terceiro nível no bind rpz para que o BLACKLIST IT torne o domínio de segundo nível não seguir o filtro principal resultante do WHITELISTED.

    

Answer 1

Quanto ao comportamento e regexps do BIND RPZ: *.com blacklists todos os subdomínios DNS abaixo de com , no entanto se você pretende colocar na lista negra o domínio raiz com você precisa adicionar ao arquivo rpz:

com

Então, se você não introduzir com a lista rpz, ela será resolvida. O que você descreve é um comportamento normal.

Quanto a um analisador de listas negras RPZ, recomendo escrever um, pelo menos para salvar recursos. O impacto durante a execução deve ser mínimo, pois o BIND está usando tabelas de hashing, mas o atraso na leitura da tabela RPZ ao reiniciar o BIND é perceptível (por exemplo, quando o BIND está lendo e analisando a tabela RPZ) e usa um pouco mais de memória. Eu não escrevi esse analisador por enquanto .