Quen opera 1.1.1.1? Comprobar un enderezo DNS antes de confiar nel
Un enderezo DNS usado xunto a unha VPN non o opera necesariamente esa VPN. Identifique o resolutor e despois comprobe a ruta e a política de nomes privados por separado.
Pegou 1.1.1.1 no campo DNS da VPN, a páxina cargou e o titorial xa parece confirmado. Esa observación é máis estreita do que parece: a aplicación comportouse doutro xeito, e o cambio aínda non di nada sobre quen respondeu á consulta nin por que fallou a configuración anterior. Un titorial copiado adoita chamar «o DNS da VPN» a un enderezo público coñecido, o que é unha afirmación sobre a propiedade e non sobre a accesibilidade. Comprobar que representa o enderezo leva cinco minutos e evita un cambio permanente feito polo motivo equivocado.
Unha configuración que funciona non é unha identidade
O enderezo dun campo de configuración é un extremo, e un extremo ten un operador. Son dous feitos separados, e o segundo é o que a xente salta. Para o par que máis se copia, a resposta é pública: Cloudflare publica 1.1.1.1 e 1.0.0.1 como os seus enderezos de resolutor e enuméraos na súa referencia oficial de enderezos. Por iso o nome do operador vai xunto ao enderezo e non nun titorial aparte.
Introducir ese par cun túnel activo non converte a empresa da VPN na súa operadora nin fai que o tráfico sexa anónimo. A consulta sae do seu equipo cara a unha empresa que publica o rango de enderezos, e esa empresa pode ser respectable e aínda así non ser a parte que o titorial insinuaba. A etiqueta das instrucións e o operador real son afirmacións distintas. Ningunha das dúas di quen xestiona a ruta de rede intermedia.
Use a referencia publicada do propio resolutor para confirmar un par de enderezos ou un extremo cifrado. Unha recomendación doutro provedor pode ser lexítima, e «recomendado por», «acadado a través de» e «operado por» seguen describindo tres relacións diferentes.
Compare as tres cousas que necesita un rexistro
Un rexistro listo para revisión separa tres preguntas: quen debe recibir a consulta, se o intercambio é simple ou cifrado e que ruta debe transportala. O nome dun provedor non pode encher a segunda nin a terceira, e unha etiqueta de país non pode encher ningunha delas. Anote as tres entradas antes do cambio e compáraas despois. Esas entradas non son intercambiables, e tratalas como unha soa é como unha suposición se converte en documentación.
A comparación é o que converte unha configuración que funciona nunha decisión documentada. Sen ela, a seguinte persoa herda un enderezo sen ningún motivo anexo. Lea primeiro a terceira columna da táboa seguinte, porque é onde de feito se deteñen a maioría das explicacións seguras.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
A táboa é deliberadamente curta. A súa idea é que cada entrada responde a unha pregunta distinta e que ningún campo por si só cobre as tres.
Un reenviador local agocha a orixe real
Un dispositivo configurado para usar o seu router como DNS apunta a un reenviador. Ese enderezo identifica o seguinte destinatario da consulta, non o resolutor que finalmente a responde. Un resolutor stub local engade o mesmo paso extra, e é fácil confundilo co real porque aparece en todas as saídas de estado.
O stub reenvía a orixes que esa mesma saída tamén enumera, normalmente máis abaixo. Lea toda a cadea antes de concluír algo sobre o operador, porque a primeira liña non é toda a resposta. Se non, está nomeando a recepción como a empresa.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'O segundo comando usa o nome de eco dun resolutor, cando o operador publica un, para informar do enderezo de orixe que ve. O terceiro nomea o servidor que respondeu, que a miúdo non é o enderezo que vostede configurou. Compare as tres saídas antes de anotar un operador.
O DNS cifrado cambia que é visible, non quen o ve
DNS over HTTPS e DNS over TLS protexen o intercambio entre cliente e resolutor. O resolutor segue lendo cada nome que se lle pide, porque responder é o seu traballo. O que cambia é quen pode observar o intercambio: a rede local ve unha conexión a un só extremo en lugar dun fluxo de consultas en texto simple.
O que non cambia é a relación de confianza, que segue apuntando á organización que opera ese extremo. Un navegador coa súa propia configuración de DNS seguro pode evitar por completo o resolutor do sistema operativo. Tráteos como dúas configuracións que poden non coincidir, e non como unha soa configuración aplicada dúas veces.
Os nomes privados necesitan de novo a súa propia decisión. Un túnel de traballo pode encamiñar dominios seleccionados cara a resolutores da organización, e substituílo por un servizo público pode romper as buscas internas ou revelar nomes internos á parte equivocada. Revise a política de dominios antes de substituír a configuración de todo un adaptador.
Manteña estreita a observación
Cando compare, conserve a configuración antiga e cambie unha soa opción á vez. Anote a aplicación, a operación, a política do resolutor e se os nomes públicos e os privados permitidos aínda se resolven tras reconectar. Unha comparación con dous cambios non demostra ningún dos dous. Escriba o resultado onde o atope a seguinte persoa, xunto á propia configuración.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comSe a aplicación comeza a funcionar, manteña a afirmación tan pequena como permitan as probas. Ese cambio axudou a unha proba e non di nada sobre se o resolutor anterior actuou de mala fe, se o túnel estaba roto ou se outro dispositivo necesita o mesmo substituto. O resultado duradeiro é unha configuración cuxa operadora e propósito pode explicar.