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/.

#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

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).

A czemu twoim zdaniem powinien? xD

Offline

 

#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

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

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

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: [Rozw.] DNSoverTLS, plik /etc/hosts i wyniki dla polecenia dig(1).

Znalazłem trochę lepsiejsze wytłumaczenie w kontekście linux'a,

Offline

 

#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

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

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

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)