iphelix/dnschefDNSChef - proxy DNS para testadores de penetração e analistas de malware
| | versão 0.4 | | / _|
| | __ ___ | | __| |
/ ` | ' / |/ | ' \ / _ \ |
| (| | | | _ \ (| | | | __/ |
_,|| ||/_|| ||___||
D O C U M E N T A Ç Ã O
DNSChef é um proxy DNS altamente configurável para Testadores de Penetração e Analistas de Malware. Um proxy DNS (também conhecido como "DNS Falso") é uma ferramenta usada para análise de tráfego de rede de aplicações, entre outros usos. Por exemplo, um proxy DNS pode ser usado para falsificar solicitações para "badguy.com" e apontá-las para uma máquina local para encerramento ou interceptação, em vez de um host real em algum lugar da Internet.
Existem vários proxies DNS por aí. A maioria simplesmente aponta todas as consultas DNS para um único endereço IP ou implementa apenas uma filtragem rudimentar. O DNSChef foi desenvolvido como parte de um teste de penetração onde havia a necessidade de um sistema mais configurável. Como resultado, o DNSChef é uma aplicação multiplataforma capaz de forjar respostas com base em listas de domínios inclusivas e exclusivas, suportando múltiplos tipos de registros DNS, correspondência de domínios com curingas, proxy de respostas verdadeiras para domínios não correspondentes, definição de arquivos de configuração externos, IPv6 e muitos outros recursos. Você pode encontrar uma explicação detalhada de cada um dos recursos e usos sugeridos abaixo.
O uso de um Proxy DNS é recomendado em situações onde não é possível forçar uma aplicação a usar algum outro servidor proxy diretamente. Por exemplo, algumas aplicações móveis ignoram completamente as configurações de proxy HTTP do sistema operacional. Nestes casos, o uso de um servidor proxy DNS como o DNSChef permitirá que você engane essa aplicação e faça com que ela encaminhe as conexões para o destino desejado.
Antes de começar a usar o DNSChef, você deve configurar sua máquina para usar um servidor de nomes DNS com a ferramenta em execução. Você tem várias opções com base no sistema operacional que vai usar:
Linux - Edite /etc/resolv.conf para incluir uma linha no topo com o host de análise de tráfego (ex: adicione "nameserver 127.0.0.1" se estiver executando localmente). Alternativamente, você pode adicionar um endereço de servidor DNS usando ferramentas como o Gerenciador de Rede. Dentro do Gerenciador de Rede, abra Configurações IPv4, selecione Apenas endereços Automáticos (DHCP) ou Manual na caixa suspensa Método e edite a caixa de texto Servidores DNS para incluir um endereço IP com o DNSChef em execução.
Windows - Selecione Conexões de Rede no Painel de Controle. Em seguida, selecione uma das conexões (ex: "Conexão Local"), clique com o botão direito e selecione propriedades. Na caixa de diálogo que aparece, selecione Protocolo IP (TCP/IP) e clique em propriedades. Por fim, selecione o botão de opção Usar os seguintes endereços de servidor DNS e insira o endereço IP com o DNSChef em execução. Por exemplo, se estiver executando localmente, insira 127.0.0.1.
OS X - Abra Preferências do Sistema e clique no ícone Rede. Selecione a interface ativa e preencha o campo Servidor DNS. Se estiver usando Airport, você terá que clicar no botão Avançado... e editar os servidores DNS a partir daí. Alternativamente, você pode editar /etc/resolv.conf e adicionar um servidor de nomes falso no topo (ex: "nameserver 127.0.0.1").
iOS - Abra Ajustes e selecione Geral. Em seguida, selecione Wi-Fi e clique na seta azul à direita de um Ponto de Acesso ativo na lista. Edite a entrada DNS para apontar para o host com o DNSChef em execução. Certifique-se de ter desativado a interface Celular (se disponível).
Android - Abra Configurações e selecione Redes sem fio e rede. Clique em Configurações de Wi-Fi e selecione Avançado após pressionar o botão Opções no telefone. Ative a caixa de seleção Usar IP estático e configure um servidor DNS personalizado.
Se você não tiver a capacidade de modificar as configurações de DNS do dispositivo manualmente, ainda existem várias opções envolvendo técnicas como ARP Spoofing, Rogue DHCP e outros métodos criativos.
Por fim, você precisa configurar um serviço falso para o qual o DNSChef apontará todas as solicitações. Por exemplo, se você está tentando interceptar tráfego web, deve iniciar um servidor web separado na porta 80 ou configurar um proxy web (ex: Burp) para interceptar o tráfego. O DNSChef apontará as consultas para o seu host proxy/servidor com serviços devidamente configurados.
O DNSChef é uma aplicação multiplataforma desenvolvida em Python que deve funcionar na maioria das plataformas que possuem um interpretador Python. Você pode usar o executável dnschef.exe fornecido para executá-lo em hosts Windows sem instalar um interpretador Python. Este guia se concentrará em ambientes Unix; no entanto, todos os exemplos abaixo foram testados e funcionam também no Windows.
Vamos experimentar o DNSChef com sua funcionalidade mais básica de monitoramento. Execute o seguinte comando como root (necessário para iniciar um servidor na porta 53):
# ./dnschef.py
_ _ __
| | version 0.2 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
[email protected]
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[*] Nenhum parâmetro foi especificado. Executando em modo proxy completo
Sem nenhum parâmetro, o DNSChef será executado em modo proxy completo. Isso significa que todas as solicitações serão simplesmente encaminhadas para um servidor DNS upstream (8.8.8.8 por padrão) e retornadas ao host solicitante. Por exemplo, vamos consultar um registro "A" para um domínio e observar os resultados:
$ host -t A thesprawl.org
thesprawl.org has address 108.59.3.64
O DNSChef exibirá a seguinte linha de log mostrando hora, endereço IP de origem, tipo de registro solicitado e, mais importante, qual nome foi consultado:
[23:54:03] 127.0.0.1: fazendo proxy da resposta do tipo 'A' para thesprawl.org
Este modo é útil para monitoramento simples de aplicações, onde você precisa descobrir quais domínios elas usam para suas comunicações.
O DNSChef tem suporte total para IPv6, que pode ser ativado usando as flags -6 ou --ipv6*. Funciona exatamente como o modo IPv4, com a exceção de que a interface de escuta padrão é alterada para ::1 e o servidor DNS padrão é alterado para 2001:4860:4860::8888. Aqui está um exemplo de saída:
# ./dnschef.py -6
_ _ __
| | version 0.2 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
[email protected]
[*] Usando modo IPv6.
[*] DNSChef iniciado na interface: ::1
[*] Usando os seguintes servidores de nomes: 2001:4860:4860::8888
[*] Nenhum parâmetro foi especificado. Executando em modo proxy completo
[00:35:44] ::1: fazendo proxy da resposta do tipo 'A' para thesprawl.org
[00:35:44] ::1: fazendo proxy da resposta do tipo 'AAAA' para thesprawl.org
[00:35:44] ::1: fazendo proxy da resposta do tipo 'MX' para thesprawl.org
NOTA: Por padrão, o DNSChef cria um listener UDP. Você pode usar TCP com o argumento --tcp discutido mais adiante.
Agora que você sabe como iniciar o DNSChef, vamos configurá-lo para falsificar todas as respostas apontando para 127.0.0.1 usando o parâmetro --fakeip:
# ./dnschef.py --fakeip 127.0.0.1 -q
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[*] Cozinhando todas as respostas A para apontar para 127.0.0.1
[23:55:57] 127.0.0.1: cozinhando a resposta do tipo 'A' para google.com para 127.0.0.1
[23:55:57] 127.0.0.1: fazendo proxy da resposta do tipo 'AAAA' para google.com
[23:55:57] 127.0.0.1: fazendo proxy da resposta do tipo 'MX' para google.com
Na saída acima, você pode ver que o DNSChef foi configurado para fazer proxy de todas as solicitações para 127.0.0.1. A primeira linha do log às 08:11:23 mostra que "cozinhamos" a resposta do registro "A" para apontar para 127.0.0.1. No entanto, outras solicitações para registros 'AAAA' e 'MX' são simplesmente proxiadas de um servidor DNS real. Vamos ver a saída do programa solicitante:
$ host google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address 2001:4860:4001:803::1001
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
Como você pode ver, o programa foi enganado para usar 127.0.0.1 para o endereço IPv4. No entanto, as informações obtidas do IPv6 (AAAA) e dos registros de correio (MX) parecem completamente legítimas. O objetivo do DNSChef é ter o menor impacto possível na operação correta do programa, portanto, se uma aplicação depende de um servidor de correio específico, ela obterá um corretamente através desta solicitação proxiada.
Vamos falsificar mais uma solicitação para ilustrar como direcionar vários registros ao mesmo tempo:
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 -q
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[*] Cozinhando todas as respostas A para apontar para 127.0.0.1
[*] Cozinhando todas as respostas AAAA para apontar para ::1
[00:02:14] 127.0.0.1: cozinhando a resposta do tipo 'A' para google.com para 127.0.0.1
[00:02:14] 127.0.0.1: cozinhando a resposta do tipo 'AAAA' para google.com para ::1
[00:02:14] 127.0.0.1: fazendo proxy da resposta do tipo 'MX' para google.com
Além da flag --fakeip, agora especifiquei --fakeipv6 projetada para falsificar consultas de registro 'AAAA'. Aqui está a saída atualizada do programa:
$ host google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address ::1
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
Mais uma vez, todos os registros não explicitamente sobrescritos pela aplicação foram proxiados e retornados do servidor DNS real. No entanto, IPv4 (A) e IPv6 (AAAA) foram ambos falsificados para apontar para a máquina local.
O DNSChef suporta múltiplos tipos de registros:
+--------+------------------+-----------+-----------------------------+
| Registro| Descrição |Argumento | Exemplo |
+--------+------------------+-----------+-----------------------------+
| A | Endereço IPv4 |--fakeip | --fakeip 192.0.2.1 |
| AAAA | Endereço IPv6 |--fakeipv6 | --fakeipv6 2001:db8::1 |
| MX | Servidor de correio|--fakemail | --fakemail mail.fake.com |
| CNAME | Registro CNAME |--fakealias| --fakealias www.fake.com |
| NS | Servidor de nomes|--fakens | --fakens ns.fake.com |
+--------+------------------+-----------+-----------------------------+
NOTA: Para usabilidade, nem todos os tipos de registros DNS são expostos na linha de comando. Registros adicionais como PTR, TXT, SOA, etc. podem ser especificados usando a flag --file e um cabeçalho de registro apropriado. Veja a seção arquivo de definições externas abaixo para detalhes.
Por fim, vamos observar como a aplicação trata consultas do tipo ANY:
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 --fakemail mail.fake.com --fakealias www.fake.com --fakens ns.fake.com -q
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[*] Cozinhando todas as respostas A para apontar para 127.0.0.1
[*] Cozinhando todas as respostas AAAA para apontar para ::1
[*] Cozinhando todas as respostas MX para apontar para mail.fake.com
[*] Cozinhando todas as respostas CNAME para apontar para www.fake.com
[*] Cozinhando todas as respostas NS para apontar para ns.fake.com
[00:17:29] 127.0.0.1: cozinhando a resposta do tipo 'ANY' para google.com com todos os registros falsos conhecidos.
Consultas de registro DNS ANY resultam no DNSChef retornando todos os registros falsos que conhece para um domínio aplicável. Aqui está a saída que o programa verá:
$ host -t ANY google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address ::1
google.com mail is handled by 10 mail.fake.com.
google.com is an alias for www.fake.com.
google.com name server ns.fake.com.
Usando o exemplo acima, considere que você só quer interceptar solicitações para thesprawl.org e deixar consultas para todos os outros domínios, como webfaction.com, sem modificação. Você pode usar o parâmetro --fakedomains conforme ilustrado abaixo:
# ./dnschef.py --fakeip 127.0.0.1 --fakedomains thesprawl.org -q
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[*] Cozinhando respostas para apontar para 127.0.0.1 correspondendo a: thesprawl.org
[00:23:37] 127.0.0.1: cozinhando a resposta do tipo 'A' para thesprawl.org para 127.0.0.1
[00:23:52] 127.0.0.1: fazendo proxy da resposta do tipo 'A' para mx9.webfaction.com
No exemplo acima, a solicitação para thesprawl.org foi falsificada; no entanto, a solicitação para mx9.webfaction.com foi mantida inalterada. Filtrar domínios é muito útil quando você tenta isolar uma única aplicação sem quebrar o restante.
NOTA: O DNSChef não verificará se o domínio existe ou não antes de falsificar a resposta. Se você especificou um domínio, ele sempre resolverá para um valor falso, independentemente de existir ou não.
Em outra situação, você pode precisar falsificar respostas para todas as solicitações, exceto uma lista definida de domínios. Você pode realizar esta tarefa usando o parâmetro --truedomains da seguinte forma:
# ./dnschef.py --fakeip 127.0.0.1 --truedomains thesprawl.org,*.webfaction.com -q
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[*] Cozinhando respostas para apontar para 127.0.0.1 não correspondendo a: *.webfaction.com, thesprawl.org
[00:27:57] 127.0.0.1: fazendo proxy da resposta do tipo 'A' para mx9.webfaction.com
[00:28:05] 127.0.0.1: cozinhando a resposta do tipo 'A' para google.com para 127.0.0.1
Há várias coisas acontecendo no exemplo acima. Primeiro, observe o uso de um curinga (*). Todos os domínios correspondentes a *.webfaction.com serão correspondidos reversamente e resolvidos para seus valores verdadeiros. A solicitação para 'google.com' retornou 127.0.0.1 porque não estava na lista de domínios excluídos.
NOTA: Os curingas são específicos de posição. Uma máscara do tipo *.thesprawl.org corresponderá a www.thesprawl.org, mas não a www.test.thesprawl.org. No entanto, uma máscara do tipo ..thesprawl.org corresponderá a thesprawl.org, www.thesprawl.org e www.test.thesprawl.org.
Pode haver situações onde definir um único registro DNS falso para todos os domínios correspondentes não seja suficiente. Você pode usar um arquivo externo com uma coleção de pares DOMÍNIO=REGISTRO definindo exatamente para onde deseja que a solicitação vá.
Por exemplo, vamos criar o seguinte arquivo de definições e chamá-lo de dnschef.ini:
[A]
*.google.com=192.0.2.1
thesprawl.org=192.0.2.2
*.wordpress.*=192.0.2.3
Observe o cabeçalho da seção [A], ele define o tipo de registro para o DNSChef. Agora vamos observar atentamente a saída de várias consultas:
# ./dnschef.py --file dnschef.ini -q
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[+] Cozinhando respostas A para domínio *.google.com com '192.0.2.1'
[+] Cozinhando respostas A para domínio thesprawl.org com '192.0.2.2'
[+] Cozinhando respostas A para domínio *.wordpress.* com '192.0.2.3'
[00:43:54] 127.0.0.1: cozinhando a resposta do tipo 'A' para google.com para 192.0.2.1
[00:44:05] 127.0.0.1: cozinhando a resposta do tipo 'A' para www.google.com para 192.0.2.1
[00:44:19] 127.0.0.1: cozinhando a resposta do tipo 'A' para thesprawl.org para 192.0.2.2
[00:44:29] 127.0.0.1: fazendo proxy da resposta do tipo 'A' para www.thesprawl.org
[00:44:40] 127.0.0.1: cozinhando a resposta do tipo 'A' para www.wordpress.org para 192.0.2.3
[00:44:51] 127.0.0.1: cozinhando a resposta do tipo 'A' para wordpress.com para 192.0.2.3
[00:45:02] 127.0.0.1: fazendo proxy da resposta do tipo 'A' para slashdot.org
Tanto google.com quanto www.google.com corresponderam à entrada *.google.com e resolveram corretamente para 192.0.2.1. Por outro lado, a solicitação www.thesprawl.org foi simplesmente proxiada em vez de modificada. Por fim, todas as variações de wordpress.com, www.wordpress.org, etc. corresponderam à máscara *.wordpress.* e resolveram corretamente para 192.0.2.3. Por último, uma consulta não definida slashdot.org foi simplesmente proxiada com uma resposta real.
Você pode especificar cabeçalhos de seção para todos os outros tipos de registro DNS suportados, incluindo aqueles não explicitamente expostos na linha de comando: [A], [AAAA], [MX], [NS], [CNAME], [PTR], [NAPTR] e [SOA]. Por exemplo, vamos definir uma nova seção [PTR] no arquivo 'dnschef.ini':
[PTR]
*.2.0.192.in-addr.arpa=fake.com
Vamos observar o comportamento do DNSChef com este novo tipo de registro:
./dnschef.py --file dnschef.ini -q
[sudo] password for iphelix:
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[+] Cozinhando respostas PTR para domínio *.2.0.192.in-addr.arpa com 'fake.com'
[00:11:34] 127.0.0.1: cozinhando a resposta do tipo 'PTR' para 1.2.0.192.in-addr.arpa para fake.com
E aqui está o que um cliente pode ver ao realizar consultas DNS reversas:
$ host 192.0.2.1 localhost
1.2.0.192.in-addr.arpa domain name pointer fake.com.
Alguns registros exigem formatação exata. Bons exemplos são SOA e NAPTR:
[SOA]
*.thesprawl.org=ns.fake.com. hostmaster.fake.com. 1 10800 3600 604800 3600
[NAPTR]
*.thesprawl.org=100 10 U E2U+sip !^.*$!sip:[email protected]! .
Veja o arquivo de exemplo dnschef.ini para exemplos adicionais.
Você pode misturar e combinar entrada de um arquivo e da linha de comando. Por exemplo, o seguinte comando usa tanto os parâmetros --file quanto --fakedomains:
# ./dnschef.py --file dnschef.ini --fakeip 6.6.6.6 --fakedomains=thesprawl.org,slashdot.org -q
[*] DNSChef iniciado na interface: 127.0.0.1
[*] Usando os seguintes servidores de nomes: 8.8.8.8
[+] Cozinhando respostas A para domínio *.google.com com '192.0.2.1'
[+] Cozinhando respostas A para domínio thesprawl.org com '192.0.2.2'
[+] Cozinhando respostas A para domínio *.wordpress.* com '192.0.2.3'
[*] Cozinhando respostas A para apontar para 6.6.6.6 correspondendo a: *.wordpress.*, *.google.com, thesprawl.org
[*] Cozinhando respostas A para apontar para 6.6.6.6 correspondendo a: slashdot.org, *.wordpress.*, *.google.com, thesprawl.org
[00:49:05] 127.0.0.1: cozinhando a resposta do tipo 'A' para google.com para 192.0.2.1
[00:49:15] 127.0.0.1: cozinhando a resposta do tipo 'A' para slashdot.org para 6.6.6.6
[00:49:31] 127.0.0.1: cozinhando a resposta do tipo 'A' para thesprawl.org para 6.6.6.6
[00:50:08] 127.0.0.1: fazendo proxy da resposta do tipo 'A' para tor.com
Observe que a definição para thesprawl.org no parâmetro da linha de comando teve precedência sobre dnschef.ini. Isso pode ser útil se você quiser sobrescrever valores no arquivo de configuração. slashdot.org ainda resolve para o endereço IP falso porque foi especificado no parâmetro --fakedomains. A solicitação tor.com é simplesmente proxiada, pois não foi especificada nem na linha de comando nem no arquivo de configuração.
Outras configurações ====================Por razões de segurança, o DNSChef escuta na interface local 127.0.0.1 (ou ::1 para IPv6) por padrão. Você pode fazer o DNSChef escutar em outra interface usando o parâmetro --interface:
# ./dnschef.py --interface 0.0.0.0 -q
[*] DNSChef started on interface: 0.0.0.0
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
[00:50:53] 192.0.2.105: proxying the response of type 'A' for thesprawl.org
ou para IPv6:
# ./dnschef.py -6 --interface :: -q
[*] Using IPv6 mode.
[*] DNSChef started on interface: ::
[*] Using the following nameservers: 2001:4860:4860::8888
[*] No parameters were specified. Running in full proxy mode
[00:57:46] 2001:db8::105: proxying the response of type 'A' for thesprawl.org
Por padrão, o DNSChef usa o servidor DNS público do Google para fazer requisições de proxy. No entanto, você pode definir uma lista personalizada de nameservers usando o parâmetro --nameservers:
# ./dnschef.py --nameservers 4.2.2.1,4.2.2.2 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 4.2.2.1, 4.2.2.2
[*] No parameters were specified. Running in full proxy mode
[00:55:08] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
É possível especificar uma porta de nameserver não padrão usando a notação IP#PORTA:
# ./dnschef.py --nameservers 192.0.2.2#5353 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 192.0.2.2#5353
[*] No parameters were specified. Running in full proxy mode
[02:03:12] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
Ao mesmo tempo, é possível iniciar o próprio DNSChef em uma porta alternativa usando o parâmetro -p porta#:
# ./dnschef.py -p 5353 -q
[*] Listening on an alternative port 5353
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
O protocolo DNS pode ser usado sobre UDP (padrão) ou TCP. O DNSChef implementa um modo TCP que pode ser ativado com a flag --tcp.
Aqui estão algumas informações sobre os internos caso você precise adaptar a ferramenta às suas necessidades. O DNSChef é construído sobre o módulo SocketServer e usa threads para ajudar a processar múltiplas requisições simultaneamente. A ferramenta foi projetada para escutar em portas TCP ou UDP (padrão é a porta 53) para requisições recebidas e encaminhar essas requisições quando necessário para um servidor DNS real via UDP.
A excelente biblioteca dnslib é usada para dissecar e remontar pacotes DNS. Ela é particularmente útil ao gerar pacotes de resposta baseados em consultas.
O DNSChef é capaz de modificar consultas para registros do tipo "A", "AAAA", "MX", "CNAME", "NS", "TXT", "PTR", "NAPTR", "SOA", "ANY". É muito fácil expandir ou modificar o comportamento para qualquer registro. Basta adicionar outra entrada if qtype == "TIPO DE REGISTRO") e dizer o que responder.
Aproveite a ferramenta e encaminhe todas as solicitações e comentários para iphelix [at] thesprawl.org.
Feliz hacking! -Peter