Rexistros do resolutor DNS fronte a rexistros de conexión VPN: que garda cada un

Un rexistro do resolutor DNS e un rexistro de conexión VPN son ambos rexistros de rede, ambos útiles e non intercambiables. O resolutor recibe os nomes que se lle pediu responder. O punto de saída da VPN xestiona as conexións de túnel e rexistra o que a súa implementación decidiu rexistrar sobre elas. Poden estar no mesmo edificio, ser operados polo mesmo equipo e quedar cubertos polo mesmo aviso de privacidade, e aínda así describen eventos distintos con identificadores distintos e retención distinta. Ler un como se fose o outro é a forma en que as investigacións se torcen.

Dous rexistros, dous eventos

Unha entrada do resolutor responde a unha pregunta sobre nomeamento: este cliente pediu este nome neste momento, e a resposta foi esta. Unha entrada da VPN responde a unha pregunta sobre conectividade: este par estableceu ou perdeu un túnel, recibiu esta dirección e transferiu aproximadamente esta cantidade de datos antes de desaparecer. Ningún dos dous é un rexistro do que o usuario fixo dentro dunha sesión HTTPS, e ningún substitúe o outro.

A distinción ten unha consecuencia práctica para as promesas. Unha afirmación de que un provedor de VPN non rexistra a actividade do túnel non di nada sobre o resolutor que entrega, e a política de retención dun resolutor non di nada sobre quen se conectou ao túnel. Cada afirmación pertence ao seu propio operador e ao seu propio sistema.

Segue a consulta antes de ler calquera dos dous rexistros

Unha consulta chega a un resolutor só se o camiño realmente llo pregunta. Unha aplicación pode usar o resolutor do sistema operativo, executar o seu propio cliente DNS cifrado ou ler unha resposta na caché e non enviar nunca nada. Así que un rexistro do resolutor que non mostra nada non é proba de que un nome nunca se usase; é proba de que a este resolutor non se lle preguntou.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Ese último comando le o diario propio do resolutor local, que non é o mesmo que o rexistro do servidor ascendente. Se as túas consultas saen mediante DNS over HTTPS cara a un provedor, o stub local pode non mostrar nada mentres o provedor ten o rexistro completo, e o provedor é outro operador con outra política.

Que pode e que non pode mostrar cada rexistro

Unilos é onde está o traballo real, e unilos non sempre é posible. Un resolutor que rexistra enderezos de clientes pódese comparar cunha VPN que asigna enderezos dun grupo coñecido, e esa comparación produce un vínculo verosímil entre un nome consultado e un túnel, que segue sendo un vínculo entre dous rexistros e non un rexistro dunha persoa.

O DNS cifrado cambia o transporte, non a visibilidade no punto de saída. O resolutor segue recibindo a pregunta que responde, como RFC 8484 deixa claro, e a retención nese resolutor é unha decisión de política e non unha propiedade do protocolo.

Onde o DNS dividido e as cachés confunden a historia

Varios resolutores son normais. Un deseño de DNS dividido envía os nomes internos a un servidor interno e todo o demais a un público, así que unha soa investigación pode implicar dous rexistros que nunca se pensaron para combinarse e dous axustes de retención que nunca se pensaron para compararse. Ver consultas en ambos é proba de que o deseño funciona, non proba dunha fuga.

As cachés cortan na outra dirección. Un nome popular pode responderse desde a caché durante horas, así que o rexistro do resolutor mostra a primeira consulta e logo nada, mentres a aplicación do usuario segue resolvendo o mesmo nome tan contenta. A ausencia de entradas despois de certo momento non significa que ninguén usase o nome despois dese momento.

O tráfico de fondo é a terceira distorsión. Un teléfono que resolve un nome de telemetría ao arrincar, un navegador que resolve un dominio de suxestión de busca e un actualizador que se conecta cada hora aparecen todos nun rexistro do resolutor xunto ao nome que de verdade che importa. O volume nese rexistro non é atención, e contar consultas non é contar visitas. Un rexistro do resolutor é un rexistro de preguntas, e as preguntas son baratas de xerar.

Fai as preguntas sobre retención por separado

Para cada sistema, fai tres preguntas: quen recolle, que se recolle e canto tempo se conserva. Logo pregunta quen pode lelo e con que proceso. A discusión do RFC 8484 sobre DNS over HTTPS é un bo recordatorio de que o transporte cifrado non elimina o punto de saída, e a documentación propia do operador é a única afirmación fiable sobre o que ese punto de saída conserva.

Cando se fai unha afirmación sobre privacidade acerca de «a VPN», divídea en compoñentes antes de aceptala: o operador do túnel, o resolutor que entrega o túnel, calquera resolutor ascendente ao que cheguen esas consultas e as aplicacións do dispositivo. Cada un ten a súa propia resposta, e unha afirmación exacta para un repítese habitualmente como se cubrise os catro.

Para resolver problemas, usa a mesma división. Pregunta que aplicación fixo a consulta e que resolutor a respondeu, e mira o rexistro que realmente posúe ese evento. Adiviñar desde o outro rexistro aforra un minuto e custa unha tarde.