DNS era algo que considerei um serviço do tipo configure e esqueça. Instalei um servidor DNS, coloquei na minha rede doméstica e esqueci. Abri o painel uma vez para verificar estatísticas e erros ocasionais e, às vezes, para solucionar problemas. Isso foi tudo. Tive registros de DNS registrados durante vários meses de execução do AdGuard Home e Pi-hole.
Experimentei LLMs locais por algumas semanas. Eu já havia tentado conceder acesso LLM local ao meu contêiner Docker para substituir meus scripts de monitoramento. Eu tinha os logs de DNS, então, por curiosidade, decidi enviar esses dados ao LLM local para ver o que ele encontraria sobre minha rede. Eu esperava algumas observações interessantes, mas descobri que minha rede é mais complexa do que pensava.
Testei 3 LLMs nativos em meu RTX 4070 Ti para trabalho real – apenas um conseguiu um lugar permanente
VRAM de 12 GB, um modelo que vale a pena manter.
Os dados estavam mais sujos do que eu esperava
Logs tinha outros planos
Quando decidi inserir meus logs DNS para o LLM local, pensei que a parte dos dados seria fácil e que o verdadeiro desafio seria processar esses dados posteriormente. Mas quando comecei a extrair registros de um mês, percebi que não havia um banco de dados organizado esperando por mim. Devido à natureza do meu trabalho, estou constantemente alternando diferentes servidores DNS para testar e escrever sobre eles. Então, as toras não estavam em um só lugar esperando que eu simplesmente agarrasse e seguisse em frente.
Eu testei e usei três servidores DNS diferentes nos últimos dois meses. Eu uso Pi-hole com dnscrypt-proxy há muito tempo. Em seguida, mudei para o AdGuard Home (AGH) para simplificar minha pilha DNS de dois contêineres. Enquanto usava o AGH, mudei para o Technitium porque muitos me recomendaram como uma alternativa melhor. Depois de testar o Technitium por uma semana, voltei para o AGH porque era poderoso e fácil de mudar para segundo plano. Então, quando tentei obter os registros desse experimento, descobri que meu histórico de DNA estava espalhado por vários contêineres.
Tornou-se outra tarefa para mim retirar todos esses logs de seus respectivos contêineres. Eu também estava preocupado se os contêineres do Docker parados ainda retinham seus dados. Após algumas sessões SSH, descobri que todos os volumes montados pelo link ainda estavam intactos. Foi um alívio. Mas a tarefa não foi concluída. Eu não tinha os registros comigo ainda.
Encontrei centenas de milhares de toras do buraco Pi no pihole-FTL.db arquivo e página inicial do AdGuard querylog.json arquivo. Mas o Technitium só me deu alguns milhares; foi estranho, considerando que eu o administraria por mais de uma semana. Eu esperava mais. Depois de olhar o arquivo de configuração do Technitium, percebi isso maxLogRecords dnsApp.config foi definido como 10000, o que significava que o Technitium já havia alternado as entradas mais antigas.
Então continuei usando apenas registros Pi-hole e AdGuard Home, mas ainda encontrei mais de 650.000 registros brutos. Depois de obter os dois logs do servidor DNS, precisei de um script Python curto que fosse suficiente para combinar e normalizar os dois conjuntos de logs em um único CSV. E eu estava pronto para alimentar um arquivo CSV em minha configuração local de LLM. Mas não foi tão fácil quanto parecia.
Substituí Pi-hole por Unbound por uma semana, e a atualização de privacidade não foi o único benefício.
Eu recomendaria substituir Pi-hole por Unbound?
677.000 linhas são demais para um prompt
Ele conectou os pontos
Estou executando Gemma 4 E4B em meu RTX 4070 Ti usando Ollama. Em uma configuração normal, eu teria apenas usado uma interface familiar como o Open WebUI ou até mesmo um painel personalizado para conectar-se ao Ollama por meio de endpoints compatíveis com OpenAI e encerrar o processo. Mas este não era um cenário comum; Eu estava lidando com mais de 650.000 registros.
Se eu fizesse matemática básica, uma linha de 50 a 80 caracteres vezes 650.000 equivaleria a cerca de 45 milhões de caracteres e, com cerca de 4 caracteres por token, seriam cerca de 12 milhões de tokens. A janela de contexto de Gemma era de 128.000 tokens. Até Claude Opus tinha 1 milhão de janelas de contexto. Não havia nenhuma maneira prática de colocar um arquivo CSV desse tamanho no LLM e esperar uma análise significativa.
Foi então que decidi procurar uma solução. Os registros de DNA bruto eram repetitivos, a maioria dos registros individualmente não tinha sentido e o valor estava no padrão de milhares de registros. Então, estou pensando em coletar tudo em um formato JSON estruturado, analisando o arquivo CSV antes de alimentá-lo para Gemma. Como decidi coletar manualmente os dados antes de alimentá-los para Gemma, troquei o Open WebUI por um painel HTML personalizado e um proxy Python leve.
Veja como o pipeline funcionou: quando carreguei um arquivo CSV bruto de mais de 650.000 para o painel, ele foi primeiro analisado e compilado inteiramente no lado do cliente usando o retorno de chamada da etapa de streaming do PapaParse em JavaScript. Este resumo JSON foi então postado em um proxy Python leve somente stdlib (sem instalação de pip, sem dependências), que o encaminhou para Gemma via Ollama. /api/chat ponto final.
A primeira versão era um único arquivo HTML (index.html) e um arquivo Python (proxy.py). Era funcional, mas simples. Se você tem acompanhado meus experimentos, já sabe que adoro o frontend React e o backend Python. Então passei uma tarde construindo-o corretamente com um frontend React (Vite + Tailwind) e um backend FastAPI. Adicionei diagramas e uma interface de chat adequada para que parecesse uma ferramenta real e não um protótipo.
Afinal, o LLM local nunca viu os mais de 650.000 registros individuais de DNA. Ele só via um resumo cuidadosamente selecionado dos registros, então, independentemente do que Gemma entendesse e reagisse, a informação não estava apenas no modelo — estava nos dados que eu preparei e alimentei nele.
O que Gemma descobriu que eu perdi
Minha rede não estava silenciosa – eu simplesmente não estava ouvindo
Os painéis DNS, sejam Pi-hole ou AdGuard, me mostraram as estatísticas, mas Gemma me mostrou as histórias reais por trás dessas estatísticas.
Quando coletei os registros e cliquei no botão Analisar com Gemma, Gemma teve a primeira resposta em segundos. Foi um rápido resumo do que está acontecendo na minha rede – principais fontes de tráfego, janelas de consulta, telemetria generalizada e algumas recomendações. Mas também revelou algumas coisas sobre minha rede sem saber detalhes específicos, e isso foi realmente impressionante.
Para contextualizar, nunca dei a Gemma nomes de dispositivos, nomes de host, rótulos de IP ou informações de fornecedores. O JSON estruturado continha os 30 principais domínios, um detalhamento por cliente, um detalhamento por hora, o número de consultas diárias e por fim o número total de consultas.
Usando esses dados de DNA agregados difusos, Gemma agrupou domínios, por exemplo firetvcaptiveportal.com, minerva.devices.a2z.come global.telemetry.insights.video.a2z.com e deduzi que eles pertenciam ao meu stick Fire TV com um IP local de 192.168.0.112. A parte interessante não era que a Amazon fosse proprietária desses domínios; foi que o modelo conectou os pontos entre eles apenas a partir de padrões de consulta sem informações claras.
Também indicou um alto volume consistente de consultas entre 4h e 7h, que quando pesquisei era consistente com sincronizações agendadas do Nextcloud, operações Samba e trabalhos automatizados em segundo plano. Nada fora do comum, mas algo que eu nunca tinha notado, já que nunca observei a atividade do DNA por hora.
Também destacou repetidas solicitações de domínios de telemetria e infraestrutura em nuvem, como Datadog e Amazon. Eu já sabia disso porque já havia notado algo semelhante no meu painel Pi-hole há alguns dias. Foram meus dispositivos inteligentes que passaram furtivamente pelas listas de bloqueio da comunidade que eu já bloqueei usando regras personalizadas. Mas o fato de poder observar que muitos dos meus dispositivos falavam mesmo quando estavam ociosos era algo que nenhum painel de controle havia me mostrado tão claramente.
Algumas perguntas complementares esclareceram minhas dúvidas restantes. Mas no final, todo o experimento mudou minha opinião sobre os registros de DNA. A partir de então, os logs não eram mais algo que eu abria apenas durante a solução de problemas. E comecei a construir minha história de registros de DNA, na qual um LLM local poderia pensar.
5 servidores DNS poderosos que você pode hospedar para turbinar sua rede doméstica
Aprimore sua jornada de auto-hospedagem com um servidor DNS adequado às suas necessidades.
Eu tinha respostas. Eu simplesmente nunca olhei
Presumi que minha rede estava silenciosa porque eu tinha apenas alguns dispositivos ativos e alguns dispositivos IoT que raramente usava. Mas acabou que “quieto” significava apenas que não havia nada obviamente errado. A maioria dos meus dispositivos, mesmo quando ociosos, estavam em constante comunicação. Sempre tive logs de DNS, mas nunca tentei lê-los, nem tive uma maneira prática de ler centenas de milhares de logs de uma só vez. O LLM local me deu a capacidade de entender a atividade DNS da semana sem enviar nada para a nuvem. Agora vejo os logs de DNS de maneira diferente e, da próxima vez que um dispositivo começar a agir de maneira estranha, saberei exatamente por onde começar.
