Início / ubuntu / Perguntas / 1509678
Accepted
boernsen
Asked: 2024-04-06 16:43:58 +0800 CST

Como posso resolver o vazamento de DNS ao usar o systemd com DNSOverTLS

  • 772

Atualização 04/10/2024: Este não foi um vazamento real. Veja a resposta aceita de mpboden abaixo.

O problema:

Estou conectado a um wifi estrangeiro no Kubuntu Desktop 22.04 e quero configurar o DNS em todo o sistema para 9.9.9.9 (quad9) com DNSOverTLS. No entanto, em dnsleaktest.com ainda recebo um DNS diferente.

Testei com o Firefox com "DNS sobre HTTPS" definido como Desativado.

Em https://on.quad9.net recebo conforme o esperado :YES, You ARE using quad9

No dnsleaktest.com, porém, recebo o resultado não executado :

dnsleaktest. com

Aqui está o que eu fiz:

No NetworkManager para o wifi afetado, desabilitei o IPv6 e configurei o IPv4 como Automático (somente endereços) e coloquei uma lista vazia como servidor DNS. A configuração resultante no terminal é:

$ nmcli device
DEVICE        TYPE      STATE         CONNECTION
wlo1          wifi      connected     TP-LINK_58DE
p2p-dev-wlo1  wifi-p2p  disconnected  --
lo            loopback  unmanaged     --

$ nmcli device show wlo1
GENERAL.DEVICE:                         wlo1
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         xx:xx:xx:xx:xx:xx
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     TP-LINK_58DE
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/1
IP4.ADDRESS[1]:                         192.168.0.112/24
IP4.GATEWAY:                            192.168.0.1
IP4.ROUTE[1]:                           dst = 192.168.0.0/24, nh = 0.0.0.0, mt = 600
IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = 192.168.0.1, mt = 600
IP4.ROUTE[3]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP6.GATEWAY:                            --

Eu configurei /etc/systemd/resolved.conf como tal (apenas as últimas linhas são relevantes, mas para verificação de integridade/erro forneço o arquivo completo):

$ cat /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
DNS=9.9.9.9#dns.quad9.net
FallbackDNS=9.9.9.9#dns.quad9.net
Domains=~.
DNSSEC=yes
DNSOverTLS=yes

Depois de sudo systemctl restart systemd-resolvede sudo systemctl restart NetworkManager, esta é a configuração resultante (toda a saída é colada aqui):

$ resolvectl status
Global
           Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported
    resolv.conf mode: foreign
  Current DNS Server: 9.9.9.9#dns.quad9.net
         DNS Servers: 9.9.9.9#dns.quad9.net
Fallback DNS Servers: 9.9.9.9#dns.quad9.net
          DNS Domain: ~.

Link 2 (wlo1)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported

Em testes básicos parece funcionar:

$ resolvectl query archlinux.com
archlinux.com: 3.64.163.50                     -- link: wlo1

-- Information acquired via protocol DNS in 1.1292s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: cache network

$ dig archlinux.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> archlinux.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60948
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;archlinux.com.                 IN      A

;; ANSWER SECTION:
archlinux.com.          7200    IN      A       3.64.163.50

;; Query time: 331 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Apr 06 09:30:08 CEST 2024
;; MSG SIZE  rcvd: 58


$ ss -tuna | grep :853
tcp   TIME-WAIT 0      0           192.168.0.112:48420        9.9.9.9:853
tcp   ESTAB     0      0           192.168.0.112:49032        9.9.9.9:853

A questão restante é: Por que obtenho um DNS diferente em dnsleaktest.com?

Algumas coisas que tentei:

cd /etc/
mv resolv.conf resolv.conf-old
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
  • sudo dpkg-reconfigure resolvconf. Isto resulta em:

insira a descrição da imagem aqui

$ ls -la /etc/resolv.conf 
lrwxrwxrwx 1 root root 29 Apr  8 09:10 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

Nada ainda ajudou. Você pode me ajudar a resolver isso?

networking

1 respostas

  1. Best Answer

    Isso não parece ser um vazamento de DNS.

    O endereço IP 66.185.120.243pertence à organização WoodyNet, Inc.

    Aqui está o resultado de uma consulta Whois para 66.185.120.243 , que está listado na saída do seu teste DNSLeak:

    #
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#


NetRange:       66.185.112.0 - 66.185.127.255
CIDR:           66.185.112.0/20
NetName:        WOODYN
NetHandle:      NET-66-185-112-0-1
Parent:         NET66 (NET-66-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   WoodyNet, Inc. (WOODYN)
RegDate:        2009-03-25
Updated:        2021-12-14
Ref:            https://rdap.arin.net/registry/ip/66.185.112.0


OrgName:        WoodyNet, Inc.
OrgId:          WOODYN
Address:        2351 Virginia St
City:           Berkeley
StateProv:      CA
PostalCode:     94709-1315
Country:        US
RegDate:        2001-05-16
Updated:        2022-04-28
Ref:            https://rdap.arin.net/registry/entity/WOODYN


OrgTechHandle: SHRES60-ARIN
OrgTechName:   Shrestha, Kabindra 
OrgTechPhone:  +1-415-831-3111 
OrgTechEmail:  [email protected]
OrgTechRef:    https://rdap.arin.net/registry/entity/SHRES60-ARIN

OrgAbuseHandle: BW1324-ARIN
OrgAbuseName:   Woodcock, Bill 
OrgAbusePhone:  +1-415-831-3103 
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    https://rdap.arin.net/registry/entity/BW1324-ARIN

OrgTechHandle: BW1324-ARIN
OrgTechName:   Woodcock, Bill 
OrgTechPhone:  +1-415-831-3103 
OrgTechEmail:  [email protected]
OrgTechRef:    https://rdap.arin.net/registry/entity/BW1324-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#

    De acordo com esta postagem nos Fóruns SNB, WoodyNet pertence à Quad9:

    WoodyNet é Quad9. A página inicial da Quad9.net diz que está em colaboração com a Packet Clearinghouse (pch.net).

    Olhando para o site da Quad9 , diz o seguinte:

    Bill Woodcock - Presidente Bill é o diretor executivo da Packet Clearing House, a organização não governamental internacional que constrói e dá suporte a infraestruturas críticas da Internet, incluindo pontos de troca da Internet e o núcleo do sistema de nomes de domínio.

    Referindo-se às informações Whois, Bill Woodcock está listado como o contato para Abuso e Tecnologia e os endereços de e-mail são [email protected], que é Packet Clearing House.

    Além disso, no artigo DNS To The Nines , no Medium , há a seguinte citação:

    A maneira mais fácil de verificar é executar um teste de vazamento de DNS online. Ao fazer isso, você verá que o ISP que responde é WoodyNet.

    Se você está se perguntando por que está vendo o WoodyNet, é porque Quad9 é o que chamamos de DNS anycast, que roteia automaticamente as consultas para o servidor mais próximo. Embora a Quad9 tenha servidores em mais de 100 locais em todo o mundo, ela não possui servidores próprios. Em vez disso, a Quad9 depende da Packet Clearing House (que está presente em mais de 160 pontos de troca de Internet) para hospedar servidores DNS. O Diretor Executivo da PCH é Bill Woodcock, também conhecido como Woody. Conseqüentemente, WoodyNet.

    E, finalmente, o seguinte é de uma postagem no Y Combinator de alguém que afirma ser o próprio Bill Woodcock:

    Oi. Sou Bill Woodcock, o "woody" de mesmo nome de "woodynet". E diretor executivo da PCH e presidente do conselho da Quad9. São três empresas distintas, que existem por razões diferentes e sob diferentes regulamentações fiscais (PCH e Quad9 são organizações sem fins lucrativos de benefício público, enquanto a WoodyNet existe para pagar impostos sobre transações tributáveis ​​e manter limpos os livros das organizações sem fins lucrativos) , mas eles estão intimamente relacionados.

    Nesse caso, você está vendo IPs e IN-ADDRs do WoodyNet porque o WoodyNet está fornecendo trânsito para a instância anycast do Quad9 com a qual você está conversando.

    Neste ponto, gostaria de entrar em contato com o suporte da Quad9 para confirmar que não se trata de um vazamento de DNS e que o servidor é deles.

    Entrei em contato com quad9. Eles forneceram um link para provedores de rede/testes de vazamento de DNS em seu site que afirma o seguinte:

    A Quad9 utiliza vários fornecedores de rede na nossa rede global. Ao executar um teste de vazamento de DNS, espera-se ver endereços IP pertencentes aos seguintes provedores:

    Ferramenta recomendada de teste de vazamento de DNS

    dnscheck.ferramentas

    WoodyNet (AKA PCH.net)
PCH.net
GSL Networks
i3D
EdgeUno
Equinix Metal (FKA: Packet, Packet.net, or Packethost)
Path.net (Path Network)

    Estas organizações também estão listadas na página Patrocinadores do website da Quad9: quad9.net/about/sponsors

    Se você está tentando simplesmente determinar se está usando o Quad9, pode visitar on.quad9.net em vez de confiar em um teste de vazamento de DNS. No entanto, um teste de fuga de DNS pode ser útil para garantir que está a utilizar exclusivamente o Quad9, o que é necessário para garantir que todos os seus pedidos de DNS serão protegidos pelo Quad9.

    Em relação à sua configuração

    Por padrão, /etc/resolv.confé um link simbólico para /run/systemd/resolve/stub-resolv.conf. O conteúdo deste arquivo é indicado 127.0.0.53como um servidor de nomes. Este é o resolvedor de stub de cache local.

    Você pode verificar isso baixando o Kubuntu 22.04.4 LTS ISO, instalando e executando o seguinte comando:

    ls -l /etc/resolv.conf

    A saída será:

    lrwxrwxrwx 1 root root 37 Mar 20  2023 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

    Próximo, resolvconfnão é instalado por padrão. Então você ou alguém deve ter instalado este pacote em seu sistema. Usando o mesmo ISO acima e uma nova instalação, digite which resolvconfna linha de comando e ele retornará sem nenhuma saída. resolveconfnão é necessário que você faça o que deseja.

    Se você observar a saída de resolvectl status, observe a seguinte linha na Globalseção superior:

    resolv.conf mode: foreign

    O valor nesta linha está lhe dizendo algo, que modo o /etc/resolv.confarquivo está usando. Existem quatro modos diferentes de manuseio /etc/resolv.conf:

    • Modo 1 (stub): use o resolvedor stub com domínios de pesquisa usando o link simbólico /etc/resolv.conf apontando para /run/systemd/resolve/stub-resolv.conf

    • Modo 2 (estático): use o resolvedor stub sem domínios de pesquisa usando o link simbólico /etc/resolv.conf apontando para /usr/lib/systemd/resolv.conf

    • Modo 3 (uplink): use servidores de nomes DNS uplink usando o link simbólico /etc/resolv.conf apontando para /run/systemd/resolve/resolv.conf

    • Modo 4 (estrangeiro): use servidores de nomes DNS estáticos editando /etc/resolv.conf diretamente

    Na página de manual do systemd-resolved :

    /ETC/RESOLV.CONF         top

       Four modes of handling /etc/resolv.conf (see resolv.conf(5)) are
       supported:

       •   systemd-resolved maintains the
           /run/systemd/resolve/stub-resolv.conf file for compatibility
           with traditional Linux programs. This file lists the
           127.0.0.53 DNS stub (see above) as the only DNS server. It
           also contains a list of search domains that are in use by
           systemd-resolved. The list of search domains is always kept
           up-to-date. Note that /run/systemd/resolve/stub-resolv.conf
           should not be used directly by applications, but only through
           a symlink from /etc/resolv.conf. This file may be symlinked
           from /etc/resolv.conf in order to connect all local clients
           that bypass local DNS APIs to systemd-resolved with correct
           search domains settings. This mode of operation is
           recommended.

       •   A static file /usr/lib/systemd/resolv.conf is provided that
           lists the 127.0.0.53 DNS stub (see above) as only DNS server.
           This file may be symlinked from /etc/resolv.conf in order to
           connect all local clients that bypass local DNS APIs to
           systemd-resolved. This file does not contain any search
           domains.

       •   systemd-resolved maintains the
           /run/systemd/resolve/resolv.conf file for compatibility with
           traditional Linux programs. This file may be symlinked from
           /etc/resolv.conf and is always kept up-to-date, containing
           information about all known DNS servers. Note the file
           format's limitations: it does not know a concept of
           per-interface DNS servers and hence only contains system-wide
           DNS server definitions. Note that
           /run/systemd/resolve/resolv.conf should not be used directly
           by applications, but only through a symlink from
           /etc/resolv.conf. If this mode of operation is used local
           clients that bypass any local DNS API will also bypass
           systemd-resolved and will talk directly to the known DNS
           servers.

       •   Alternatively, /etc/resolv.conf may be managed by other
           packages, in which case systemd-resolved will read it for DNS
           configuration data. In this mode of operation
           systemd-resolved is consumer rather than provider of this
           configuration file.

       Note that the selected mode of operation for this file is
       detected fully automatically, depending on whether
       /etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf
       or lists 127.0.0.53 as DNS server.

    Como você instalou o resolvconf, este aplicativo agora está gerenciando /etc/resolv.confe é o motivo pelo qual o modo está listado foreignna saída do resolvectl status.

    Quando você executou sudo dpkg-reconfigure resolvconf, a saída indicou que um link simbólico seria criado a partir /etc/resolv.confdesse ponto /run/resolvconf/resolv.conf. É aqui que a configuração padrão foi alterada.

    insira a descrição da imagem aqui

    Não estou dizendo que esta configuração esteja incorreta. Em vez disso, estou simplesmente apontando que não é o padrão e que a instalação resolvconfnão é necessária.

    • 5

relate perguntas