Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Ogłoszenie
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
- Forum Debian Users Gang
- » Sieci i serwery
- » [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
#1 2024-01-17 19:09:59
wiarus - 
Użytkownik
- wiarus
- Użytkownik
- Zarejestrowany: 2021-07-28
[Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
Cześć.
Kilka dni temu włączyłem DNSoverTLS, co można uzyskać poprzez plik /etc/systemd/resolved.conf. (Jest to zrobione tylko dla testów).
W tym pliku dostępna jest opcja ReadEtcHosts dzięki której resolver, będzie "czytał"
plik /etc/hosts. Po dodaniu większej ilości domen z kilku list i stosując
0.0.0.0 zacząłem sprawdzać, czy dodane domeny są blokowane.
Okazało się, że są blokowane. Po wpisaniu w przeglądarce dodanej do pliku hosts domeny, pojawia się
komunikat: "Niestety, nie udało się odnaleźć tej strony".
To co mnie zastanawia to polecenie dig(1) i wynik jego działania dla domen. Poniżej skrócony przykład:
,----[ [~]$ dig bugsense.com ]
| (...)
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28648
| (...)
`----
Czy status nie powinien zawierać np.: NXDOMAIN, ERROR?
Co o tym myślicie? Czy jest to problem, a może to zupełnie normalne zachowanie i wynik?
Sorry za tak naiwne pytanie.
Pozdrawiam Was!
Ostatnio edytowany przez wiarus (2024-01-18 20:20:04)
Offline
#2 2024-01-18 06:30:17
morfik - Cenzor wirtualnego świata
#3 2024-01-18 07:42:36
wiarus - Użytkownik
- wiarus
- Użytkownik
- Zarejestrowany: 2021-07-28
Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
Cześć Morfik.
Szczerze? Nie wiem, dlaczego. Po prostu skorelowałem to chyba z tym, że np. DoH włączony
w przeglądarce obejmuje, tylko jej działanie.
A skoro DoT jest włączone dla "całego systemu", to... i tu właśnie pojawia się kwestia dig(1).
W każdym razie, jest jakaś odpowiedź czy to po prostu było głupie pytanie, pozbawione
wszelkiego sensu, którego nigdy nie powinienem był zadać?
Miłego dnia, pozdro!
Offline
#4 2024-01-18 18:50:43
morfik - Cenzor wirtualnego świata
Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
No np. zgodnie z tym opisem:
Google napisał(-a):
NXDOMAIN means that the domain is non-existent, providing a DNS error message that is received by the client (Recursive DNS server). This happens when the domain has been requested but cannot be resolved to a valid IP address. All in all, NXDOMAIN error messages simply mean that the domain does not exist.
Czyli taki błąd mówi, że domena nie istnieje i dzieje się to gdy robisz zapytanie i nie można tego zapytania rozwiązać na poprawny adres IP. Ty jednak, podałeś adres 0.0.0.0, który to w linux jest adresem poprawnym:
0.0.0.0 as a target address refers variously to a non-routable host or to “this host” (RFC 5735 section 3). In practice connecting to 0.0.0.0 is, in most scenarios, equivalent to connecting to localhost. Strictly speaking it isn’t valid as a destination address, on the wire (RFC 1122 section 3.2.1.3), only as a source address, so the operating system has to ensure that a packet with destination address of 0.0.0.0 doesn’t leave the system as-is. In practice, when the Linux kernel sees a packet with a destination address of 0.0.0.0 (i.e. no destination address), it copies the source address to the destination address, and if the packet doesn’t have a source address either, it sets both to the loopback address. In both cases the packet is “sent out” over the loopback interface, so it never leaves the system.
-- https://en.wikipedia.org/wiki/0.0.0.0
-- https://unix.stackexchange.com/questions/419880/con … 419881#419881
Wiec wychodzi na to, że na linux, IP 0.0.0.0 w adresie docelowym to nic innego jak 127.0.0.1, który jest prawidłowy i nie generuje błędów. xD
Ostatnio edytowany przez morfik (2024-01-19 08:53:42)
Offline
#5 2024-01-18 20:19:15
wiarus - Użytkownik
- wiarus
- Użytkownik
- Zarejestrowany: 2021-07-28
Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
Oki, dzięki za odpowiedź. Temat można uznać za rozwiązany.
Pozdro Morfik!
Offline
#6 2024-01-19 08:51:39
morfik - Cenzor wirtualnego świata
#7 2024-01-26 16:35:41
wiarus - Użytkownik
- wiarus
- Użytkownik
- Zarejestrowany: 2021-07-28
Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
Cześć Morfik. Podzielisz się z Nami tym, co znalazłeś w odniesieniu do Linuksa? :)
—————————————
A, i jeszcze jedno pytanie: wspomniane w pierwszym poście testy dotyczą również DNSoverHTTPS włączonego w Firefoksie.
Kiedy włączone są obie metody szyfrowania DNS to oczywiście blokowanie domen z pliku /etc/hosts
nie działa.
W Firefoksie jest opcja dostępna przez about:config - chodzi o network.trr.exclude-etc-hosts
z domyślną wartością ustawioną na true. Z tego co pamiętam, zmieniłem wspomnianą wartość
na false, ale to nie zadziałało. Domeny z pliku /etc/hosts nie były blokowane.
(Być może nie zrobiłem np. restartu systemu, ale nie pamiętam tego. Restart Firefoksa miał miejsce. Raczej... Ech!)
Wie ktoś z Was, jak to zmienić? Tak, żeby obie metody szyfrowania DNS były włączone i jednocześnie blokowanie
domen było możliwe? Albo np. włączone DoH w Firefoksie a wyłączone DoT poprzez systemd-resolved.
Sorry za te pytania. Odpowiedź pewnie jest w internecie, ale w tej chwili
nie jestem w stanie szukać odpowiedzi. Oczywiście nie chodzi o to, żeby ktoś z Was specjalnie
szukał rozwiązania!!! Po prostu może znacie przyczynę i rozwiązanie opisanych problemów?
Dzięki!!!
Offline
#8 2024-01-26 20:54:30
morfik - Cenzor wirtualnego świata
Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
No tam w poprzednim poście dopisałem.
Zmiany w /etc/hosts nie wymagają restartu.
Ja nie używam systemd-resolved -- ja korzystam z dnscrypt-proxy i dnsmasq. W dnscrypt-proxy mam ustawiony DoH, bo DoT jest trochę bez sensu, tj. ma własny port i określoną strukturę pakietów, którą można odfiltrować na FW i wyciąć ten ruch nawet jak nie używasz standardowego portu. W przypadku DoH ruch jest bardzo zbliżony do ruchu https i wykorzystuje też ten port i tutaj ewentualna cenzura nie do końca może być skuteczna. Dlatego korzystaj z DoH, a DoT sobie zwyczajnie odpuść.
Mi przy takiej konfiguracji system bez poblemu blokuje domeny w /etc/hosts, które wskazują 0.0.0.0 czy 127.0.0.1, przykład:
Kod:
# ping wp.pl -c 4 PING wp.pl (212.77.98.9) 56(84) bytes of data. 64 bytes from www.wp.pl (212.77.98.9): icmp_seq=1 ttl=51 time=45.9 ms 64 bytes from www.wp.pl (212.77.98.9): icmp_seq=2 ttl=51 time=60.0 ms 64 bytes from www.wp.pl (212.77.98.9): icmp_seq=3 ttl=51 time=34.2 ms 64 bytes from www.wp.pl (212.77.98.9): icmp_seq=4 ttl=51 time=42.2 ms --- wp.pl ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 34.176/45.584/60.029/9.357 ms
Adres jest 212.77.98.9 . Teraz edytuję plik /etc/hosts i dopisuję 0.0.0.0 wp.pl i co otrzymuję?
Kod:
# ping wp.pl -c 4 PING wp.pl (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.066 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.078 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.082 ms 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.093 ms --- wp.pl ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3062ms rtt min/avg/max/mdev = 0.066/0.079/0.093/0.009 ms
Odpowiedź pochodzi z 127.0.0.1 czyli wpis w /etc/hosts został uwzględniony.
No ale to ping, a jak bym chciał odwiedzić stronę www?
Bez wpisu w /etc/hosts:
Kod:
# curl --head wp.pl HTTP/1.1 301 Moved Permanently Server: nginx Date: Fri, 26 Jan 2024 19:53:17 GMT Content-Type: text/html Content-Length: 162 Connection: keep-alive Location: https://www.wp.pl/
I z wpisem:
Kod:
# curl --head wp.pl curl: (7) Failed to connect to wp.pl port 80 after 0 ms: Couldn't connect to server
Także wszystko działa bez problemu i przekierowanie zapytania działa bez zarzutu.
Offline
#9 2024-02-04 13:47:49
wiarus - Użytkownik
- wiarus
- Użytkownik
- Zarejestrowany: 2021-07-28
Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).
Cześć Morfik.
Dzięki za niezłe rozwinięcie tematu i sorry za zwłokę z odpowiedzią!
Masz oczywiście rację jeśli chodzi o DoT, ale nie chciałem, po prostu,
żeby pozostały ruch, poza przeglądarką latał na pocie 53 itd., dlatego
wolałem już włączyć ten protokół za pomocą systemd-resolved i dodatkowo
DoH w przeglądarce (poszukam jeszcze rozwiązania tej kwestii dot. ignorowania pliku
/etc/hosts nawet, gdy opcja network.trr.exclude-etc-hosts ma wartość false itd).
Normalnie również korzystam z DNSCrypt-Proxy, ale w tym przypadku
konieczna będzie chyba "instalacja" z wykorzystaniem tar.gz, bo wersja pakietu libc6
dostępna w systemie jest za stara, żeby zainstalować przynajmniej wersję DNSCrypt-Proxy 2.0.45
za pomocą np. APT'a. Ale to kwestia na - ewentualnie - nowy temat.
Nie miałem jeszcze czasu, żeby sprawdzić wspomnianą metodę z paczką tar.gz i
najnowszą wersją DNSCrypt (mam nadzieję, że to zadziała i nie będzie problemu np. z libc6,
w razie problemów, utworzę nowy temat).
Jeszcze raz dzięki Morfik za pomoc. Pozdro!
Offline
Strony: 1
- Forum Debian Users Gang
- » Sieci i serwery
- » [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).