🚀 go-pugleaf

szopen napisał:

> Pytanie brzmi: dlaczego ubuntu zmieniło sobie DNS cichcem?

Co znaczy zmieniło i co znaczy, że akurat ubuntu?

> I jak go powstrzymać?

Co jest w pliku /etc/resolv.conf i czym on jest (zapewne
linkiem gdzieś prowadzącym)?

-- 
Jarek

On 24.04.2024 11:24, Jarosław Sokołowski wrote:
> szopen napisał:
> 
>> Pytanie brzmi: dlaczego ubuntu zmieniło sobie DNS cichcem?
> 
> Co znaczy zmieniło i co znaczy, że akurat ubuntu?

Był A, jest B... nastąpiła zmiana. Ubuntu zarządza swoimi usługami, więc ubuntu.

> 
>> I jak go powstrzymać?
> 
> Co jest w pliku /etc/resolv.conf i czym on jest (zapewne
> linkiem gdzieś prowadzącym)?

lrwxrwxrwx 1 root root 39 maj 12  2021 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

$ cat /run/systemd/resolve/stub-resolv.conf

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search router.server.lan

-- 
szopen

szopen napisał:

>> Co jest w pliku /etc/resolv.conf i czym on jest (zapewne
>> linkiem gdzieś prowadzącym)?
>
> lrwxrwxrwx 1 root root 39 maj 12  2021 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
>
> $ cat /run/systemd/resolve/stub-resolv.conf
>
> # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
> # Do not edit.
[...]
> # See man:systemd-resolved.service(8) for details about the supported modes of
> # operation for /etc/resolv.conf.
>
> nameserver 127.0.0.53
> options edns0 trust-ad
> search router.server.lan

No to trzeba dogadać się (man) z systemd żeby nie robił tego, co robi,
a nie powinien. Albo zrezygnować ze współpracy z nim, wyłączyć usługę
systemd-resolved.service lub przynajmniej pozbyć się tego linku.
W statycznym pliku /etc/resolv.conf mozna już wpisać co się chce.

-- 
Jarek

On 24.04.2024 12:03, Jarosław Sokołowski wrote:
> No to trzeba dogadać się (man) z systemd żeby nie robił tego, co robi,
> a nie powinien. Albo zrezygnować ze współpracy z nim, wyłączyć usługę
> systemd-resolved.service lub przynajmniej pozbyć się tego linku.
> W statycznym pliku /etc/resolv.conf mozna już wpisać co się chce.

No tak, tylko ja chcę czegoś innego. Chcę, żeby router mi dostarczał centralnie do komputerów/urządzeń w domu adresy 
DNS, podstawowy (mój) i zapasowy (zewnętrzny), tylko chcę, żeby póki można to system korzystał z podstawowego. I 
dopiero, gdy on zawiedzie to sprawdzał alternatywny. A on samoczynnie sobie zmienia na podstawie nieznanych mi powodów. 
Czyli chcę zmiany, ale tylko wtedy, gdy podstawowy DNS leży (bo np. aktualizuję jego kontener - jest w dokerze).
Da się tak?

-- 
szopen

szopen napisał:

>> No to trzeba dogadać się (man) z systemd żeby nie robił tego, co robi,
>> a nie powinien. Albo zrezygnować ze współpracy z nim, wyłączyć usługę
>> systemd-resolved.service lub przynajmniej pozbyć się tego linku.
>> W statycznym pliku /etc/resolv.conf mozna już wpisać co się chce.
>
> No tak, tylko ja chcę czegoś innego.

Pytanie było właśnie o to, o wybór serwera DNS.

> Chcę, żeby router mi dostarczał centralnie do komputerów/urządzeń
> w domu adresy DNS, podstawowy (mój) i zapasowy (zewnętrzny),

Tym zajmuje się serwer DHCP (może być w routerze).

> tylko chcę, żeby póki można to system korzystał z podstawowego.
> I dopiero, gdy on zawiedzie to sprawdzał alternatywny.
> A on samoczynnie sobie zmienia na podstawie nieznanych mi powodów. 
> Czyli chcę zmiany, ale tylko wtedy, gdy podstawowy DNS leży (bo np.
> aktualizuję jego kontener - jest w dokerze).
> Da się tak?

Chyba nie rozumiem problemu. Ile może trwać aktualizacja czegoś
w systemie? Sekundę? To, że resolver może korzystać z kilku serwerów
nie oznacza, że któryś jest podstawowy. To sterfy DNS (domeny) mogą
mieć serwery "primary" i "secondary" -- ale to ostatnie też nie
oznacza, że są to serwery "rezerwowe". Tu widzę, że odpytywany jest
94.140.14.14, czyli dns.adguard.com (ja bym się trochę bał), mający
chyba kosić reklamodawców. Albo lokalny systemd-resolved, który ma
robić za cache dla niego.

-- 
Jarek

On 24.04.2024 14:14, Jarosław Sokołowski wrote:
>> Chcę, żeby router mi dostarczał centralnie do komputerów/urządzeń
>> w domu adresy DNS, podstawowy (mój) i zapasowy (zewnętrzny),
> 
> Tym zajmuje się serwer DHCP (może być w routerze).

Tak, i jest on w routerze. Poza tym mam serwer domowy na którym, w dokerze, mam serwer DNS o nazwie Adguard Home.
Serwer ten ma wiele zalet, w tym filtrowanie domen z reklamami, spamem, phishingiem, etc.
Chcę, aby z tego serwera korzystały komputery w domu.

Jednakże _czasami_ ten mój serwer DNS może być offline (bo robię update, bo sprzątam serwer, itp.) i wtedy fajnie jakby 
komputery korzystały z drugiego DNSa, publicznego, nie kontrolowanego przeze mnie.

>> tylko chcę, żeby póki można to system korzystał z podstawowego.
>> I dopiero, gdy on zawiedzie to sprawdzał alternatywny.
>> A on samoczynnie sobie zmienia na podstawie nieznanych mi powodów.
>> Czyli chcę zmiany, ale tylko wtedy, gdy podstawowy DNS leży (bo np.
>> aktualizuję jego kontener - jest w dokerze).
>> Da się tak?
> 
> Chyba nie rozumiem problemu. Ile może trwać aktualizacja czegoś
> w systemie? Sekundę? To, że resolver może korzystać z kilku serwerów
> nie oznacza, że któryś jest podstawowy. To sterfy DNS (domeny) mogą
> mieć serwery "primary" i "secondary" -- ale to ostatnie też nie
> oznacza, że są to serwery "rezerwowe". Tu widzę, że odpytywany jest
> 94.140.14.14, czyli dns.adguard.com (ja bym się trochę bał), mający
> chyba kosić reklamodawców. Albo lokalny systemd-resolved, który ma
> robić za cache dla niego.

Nie zauważyłeś chyba, że w moich dwóch wklejkach ze statusem resolvera jest różnica:

Current DNS Server: 192.168.1.53
[...]
Current DNS Server: 94.140.14.14

I o tę różnicę pytam. Kto mu (resolverowi) kazał zmienić ten serwer i z jakiego powodu?

-- 
szopen

szopen <szop@en.szop> writes:
[...]
>
> Nie zauważyłeś chyba, że w moich dwóch wklejkach ze statusem resolvera jest różnica:

Ja zauważyłem.
>
> Current DNS Server: 192.168.1.53
> [...]
> Current DNS Server: 94.140.14.14
>
> I o tę różnicę pytam. Kto mu (resolverowi) kazał zmienić ten serwer i z jakiego powodu?

No i dostałeś (IMO) prawidłową wskazówkę: man systemd-resolved (czy coś
w ten deseń)

Niestety ja Ci nie pomogę, bo już od dawna pozbyłem się tego czegoś na
rzecz openresolv,  dhcpcd, i dnsmasq.

KJ


-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

szopen napisał:

>>> Chcę, żeby router mi dostarczał centralnie do komputerów/urządzeń
>>> w domu adresy DNS, podstawowy (mój) i zapasowy (zewnętrzny),
>> 
>> Tym zajmuje się serwer DHCP (może być w routerze).
>
> Tak, i jest on w routerze. Poza tym mam serwer domowy na którym, w
> dokerze, mam serwer DNS o nazwie Adguard Home. Serwer ten ma wiele
> zalet, w tym filtrowanie domen z reklamami, spamem, phishingiem, etc.
> Chcę, aby z tego serwera korzystały komputery w domu.

No to ustawić serwer DHCP tak, żeby jako opcję 6 podawał IP tego serwera.

> Jednakże _czasami_ ten mój serwer DNS może być offline (bo robię
> update, bo sprzątam serwer, itp.) i wtedy fajnie jakby komputery
> korzystały z drugiego DNSa, publicznego, nie kontrolowanego przeze
> mnie.

Jeśli to trwa aż tak długo, że stanowi problem, to na ten czas zmienić
konfigurację DHCP.

> Nie zauważyłeś chyba, że w moich dwóch wklejkach ze statusem resolvera
> jest różnica:
>
> Current DNS Server: 192.168.1.53
> [...]
> Current DNS Server: 94.140.14.14

Zauważyłem. Zauważyłem nawet, że ten 94.140.14.14 nie jest zwykłym
publicznym serwerem, takim jak 1.1.1.1 albo 8.8.8.8, tylko takim,
co to "wie lepiej". Zauważyłem też we wcześniejszych opisach, że
również 192.168.1.53 wie więcej -- choćby zna strefę server.lan, a
przynajmiej host syncthing.server.lan. Nie jest najlepszym pomysłem,
by tak różne serwery traktować równorzędnie i pozostawiać przypadkowi
wybór między nimi.

> I o tę różnicę pytam. Kto mu (resolverowi) kazał zmienić ten serwer
> i z jakiego powodu?

Tym resolverem jest systemd. On nie ma żadnych ambicji ponad robienie
za "cache" w celu przyspieszenia rozwiązywania nazw. Dostał listę
serwerów (te z założenia powiny wiedzieć to samo), wybiera sobie jeden
i po nim małpuje. Nie musi mieć specjalnych powodów, by jeden zmienić
na drugi.

Ale skoro ten dns.adguard.com taki zaufany i użyteczny, to może wziąć
jakiś zwykły dnsmasq, kazać mu wierzyć odpowiedziom z 94.140.14.14
i dodać do niego lokalną strefę server.lan? Czy ten cały Adguard Home
robi coś więcej? Nie znam gościa, może to po prostu jest dnsmasq w coś
opakowany i nie najlepiej skonfigurowany?

-- 
Jarek

Pan Kamil Jońca napisał:

>> Current DNS Server: 192.168.1.53
>> [...]
>> Current DNS Server: 94.140.14.14
>>
>> I o tę różnicę pytam. Kto mu (resolverowi) kazał zmienić ten
>> serwer i z jakiego powodu?
>
> No i dostałeś (IMO) prawidłową wskazówkę: man systemd-resolved
> (czy coś w ten deseń)

To by może i dało się zdefiniować w pliku /etc/systemd/resolved.conf,
są tam zmienne "DNS" i "FallbackDNS", ale z wcześniej opisanych przeze
mnie powodów to wszystko nie wygląda to na najlepszy pomysł. W ogóle
nie wygląda na dobry.

-- 
Jarek

On 24.04.2024 20:58, Jarosław Sokołowski wrote:
>>> Tym zajmuje się serwer DHCP (może być w routerze).
>>
>> Tak, i jest on w routerze. Poza tym mam serwer domowy na którym, w
>> dokerze, mam serwer DNS o nazwie Adguard Home. Serwer ten ma wiele
>> zalet, w tym filtrowanie domen z reklamami, spamem, phishingiem, etc.
>> Chcę, aby z tego serwera korzystały komputery w domu.
> 
> No to ustawić serwer DHCP tak, żeby jako opcję 6 podawał IP tego serwera.

Serwer DHCP jest w routerze, mam w GUI dwa pola na dwa adresy DNS. Pierwszy podaję mój lokalny, drugi adguarda (o tym 
niżej).

>> Jednakże _czasami_ ten mój serwer DNS może być offline (bo robię
>> update, bo sprzątam serwer, itp.) i wtedy fajnie jakby komputery
>> korzystały z drugiego DNSa, publicznego, nie kontrolowanego przeze
>> mnie.
> 
> Jeśli to trwa aż tak długo, że stanowi problem, to na ten czas zmienić
> konfigurację DHCP.

Wyłączenie serwera jest rzadkie i trwa np. godzinę lub dwie, ale od niego zależy to, że nikt (i nic) w domu nie będzie 
miał działającego neta. Da się przeżyć, pewnie, tylko po co tworzyć sztuczne problemy?

>> Nie zauważyłeś chyba, że w moich dwóch wklejkach ze statusem resolvera
>> jest różnica:
>>
>> Current DNS Server: 192.168.1.53
>> [...]
>> Current DNS Server: 94.140.14.14
> 
> Zauważyłem. Zauważyłem nawet, że ten 94.140.14.14 nie jest zwykłym
> publicznym serwerem, takim jak 1.1.1.1 albo 8.8.8.8, tylko takim,
> co to "wie lepiej". Zauważyłem też we wcześniejszych opisach, że
> również 192.168.1.53 wie więcej -- choćby zna strefę server.lan, a
> przynajmiej host syncthing.server.lan. Nie jest najlepszym pomysłem,
> by tak różne serwery traktować równorzędnie i pozostawiać przypadkowi
> wybór między nimi.

Właśnie... nie wiedziałem, że to bazuje na przypadku i że resolver bierze sobie z czapki dowolny adres DNS z listy. 
Myślałem, że jest zasada primary/reserve(backup) i gdy nie ma podstawowego to dopiero wtedy bierze ten drugi.
Skoro jest tak jak piszesz to wszystko i tak o kant.
Ale a propos "nie najlepszego pomysłu". Serwer DNS (do tej pory zapasowy w moim mniemaniu) od adguarda jest również 
używany w moim lokalnym serwerze DNS o nazwie nomen omen Adguard Home (ale i kilka od innych dostawców). Nie ma więc 
przypadku i braku równorzędności. A co do samego Adguarda... ufam mu podobnie jak ponad 100 mln innych użytkowników tego 
oprogramowania i nie widzę powodu by go traktować jako zagrożenie.

https://hub.docker.com/r/adguard/adguardhome
https://github.com/AdguardTeam/AdGuardHome

>> I o tę różnicę pytam. Kto mu (resolverowi) kazał zmienić ten serwer
>> i z jakiego powodu?
> 
> Tym resolverem jest systemd. On nie ma żadnych ambicji ponad robienie
> za "cache" w celu przyspieszenia rozwiązywania nazw. Dostał listę
> serwerów (te z założenia powiny wiedzieć to samo), wybiera sobie jeden
> i po nim małpuje. Nie musi mieć specjalnych powodów, by jeden zmienić
> na drugi.

"Nie musi mieć powodów" jest kluczem. Byłem przekonany, że ma powód. Skoro tak, to jedyne wyjście dać mu jeden adres, 
mój lokalny. A w razie przestojów serwera.. mieć przestoje.

> Ale skoro ten dns.adguard.com taki zaufany i użyteczny, to może wziąć
> jakiś zwykły dnsmasq, kazać mu wierzyć odpowiedziom z 94.140.14.14
> i dodać do niego lokalną strefę server.lan? Czy ten cały Adguard Home
> robi coś więcej? Nie znam gościa, może to po prostu jest dnsmasq w coś
> opakowany i nie najlepiej skonfigurowany?

Robi więcej i działa na całą sieć domową, gdzie jest kilkanaście urządzeń klienckich. W powyższych linkach wszystko opisane.

-- 
szopen

szopen napisał:

> Serwer DHCP jest w routerze, mam w GUI dwa pola na dwa adresy DNS.
> Pierwszy podaję mój lokalny, drugi adguarda (o tym niżej).

No i to mi wygląda na błąd kardynalny (o tym było wyżej).

> Wyłączenie serwera jest rzadkie i trwa np. godzinę lub dwie, ale od
> niego zależy to, że nikt (i nic) w domu nie będzie miał działającego
> neta. Da się przeżyć, pewnie, tylko po co tworzyć sztuczne problemy?

Gdyby się jednak nie dało, to warto pomyśleć o tym, aby podstawowe
usługi, bez których wszystko leży, dzłałały na urządzeniach nigdy nie
wyłączanych. Jak rozumiem, przestoju samego serweta nikt by nawet nie
zauważył, można go remontować pół dnia. Więc może router jest dobrym
miejscem?

> Właśnie... nie wiedziałem, że to bazuje na przypadku i że resolver
> bierze sobie z czapki dowolny adres DNS z listy. Myślałem, że jest
> zasada primary/reserve(backup) i gdy nie ma podstawowego to dopiero
> wtedy bierze ten drugi.

Nie, usługa DNS jest dobrze przemyślana, obciążenie serwerów i ruch
w sieci poowinien być wyrównywany.

> Ale a propos "nie najlepszego pomysłu". Serwer DNS (do tej pory
> zapasowy w moim mniemaniu) od adguarda jest również używany
> w moim lokalnym serwerze DNS o nazwie nomen omen Adguard Home
> (ale i kilka od innych dostawców). Nie ma więc przypadku i braku
> równorzędności.

Ale publiczny serwer adguarda nie zna lokalnych domen, więc jednak
ta równość jest zachwaina.

> A co do samego Adguarda... ufam mu podobnie jak ponad 100 mln
> innych użytkowników tego oprogramowania i nie widzę powodu by
> go traktować jako zagrożenie.

Rozbawił mnie nieco opis zapobiegani phishingowi w ten sposób, że
samemu się phishing robi. Jest zatem phishing zły i jest dobry.
Jeśli ktoś z tym się zgadza, to nie ma sprawy.

> "Nie musi mieć powodów" jest kluczem. Byłem przekonany, że ma powód.
> Skoro tak, to jedyne wyjście dać mu jeden adres, mój lokalny.
> A w razie przestojów serwera.. mieć przestoje.

Router może podawać swój adres. Sam może keszować, sam sprawdzać
skąd da się czerpać wiedzę o strefach, sam przełączać. W routerach
też zwykle siedzi Linux. Przeważnie z tym samym softem, co się go
instaluje na "prawdziwych" komputerach. I przeważnie skonfigurowany
słabo -- bo klienci nie mają zbyt dużych wymagań. Ale można zrobić
to samemu.

-- 
Jarek

On 2024-04-24, szopen <szop@en.szop> wrote:
> Nie zauważyłeś chyba, że w moich dwóch wklejkach ze statusem resolvera jest różnica:
>
> Current DNS Server: 192.168.1.53
> [...]
> Current DNS Server: 94.140.14.14
>
> I o tę różnicę pytam. Kto mu (resolverowi) kazał zmienić ten serwer i 
> z jakiego powodu?

Chyba najczęściej stoi za tym networkmanager.

-- 
Marcin

On 24.04.2024 22:28, Jarosław Sokołowski wrote:
> szopen napisał:
> 
>> Serwer DHCP jest w routerze, mam w GUI dwa pola na dwa adresy DNS.
>> Pierwszy podaję mój lokalny, drugi adguarda (o tym niżej).
> 
> No i to mi wygląda na błąd kardynalny (o tym było wyżej).

Ale co jest tym błędem i czyim? Bo tego nie chwytam nadal.
Jeśli chodzi o te dwa pola z routera to jedno nazywa się "Preffered DNS server" a drugie "Alternative DNS server". To 
trochę narzuciło mi sposób myślenia o tym mechanizmie.

>> Wyłączenie serwera jest rzadkie i trwa np. godzinę lub dwie, ale od
>> niego zależy to, że nikt (i nic) w domu nie będzie miał działającego
>> neta. Da się przeżyć, pewnie, tylko po co tworzyć sztuczne problemy?
> 
> Gdyby się jednak nie dało, to warto pomyśleć o tym, aby podstawowe
> usługi, bez których wszystko leży, dzłałały na urządzeniach nigdy nie
> wyłączanych. Jak rozumiem, przestoju samego serweta nikt by nawet nie
> zauważył, można go remontować pół dnia. Więc może router jest dobrym
> miejscem?

Ale router nie ma tak zaawansowanego serwera DNS jak Adguard Home czy Pi-Hole (jego konkurent).

>> Właśnie... nie wiedziałem, że to bazuje na przypadku i że resolver
>> bierze sobie z czapki dowolny adres DNS z listy. Myślałem, że jest
>> zasada primary/reserve(backup) i gdy nie ma podstawowego to dopiero
>> wtedy bierze ten drugi.
> 
> Nie, usługa DNS jest dobrze przemyślana, obciążenie serwerów i ruch
> w sieci poowinien być wyrównywany.

Ok, nie dyskutuję z tym, wyżej wyjaśniłem skąd wzięło się moje odmienne widzenie tej materii.

>> Ale a propos "nie najlepszego pomysłu". Serwer DNS (do tej pory
>> zapasowy w moim mniemaniu) od adguarda jest również używany
>> w moim lokalnym serwerze DNS o nazwie nomen omen Adguard Home
>> (ale i kilka od innych dostawców). Nie ma więc przypadku i braku
>> równorzędności.
> 
> Ale publiczny serwer adguarda nie zna lokalnych domen, więc jednak
> ta równość jest zachwaina.

Publiczny nie, ale Adguard Home w dokerze już tak. A Adguard Home używa wielu różnych, definiowanych przeze mnie, 
dostawców publicznych DNS i robi swój kesz, który jest używany w całej sieci lokalnej + zna moje wewnętrzne pseudodomeny.

>> A co do samego Adguarda... ufam mu podobnie jak ponad 100 mln
>> innych użytkowników tego oprogramowania i nie widzę powodu by
>> go traktować jako zagrożenie.
> 
> Rozbawił mnie nieco opis zapobiegani phishingowi w ten sposób, że
> samemu się phishing robi. Jest zatem phishing zły i jest dobry.
> Jeśli ktoś z tym się zgadza, to nie ma sprawy.

Trochę Ci ten ubaw utnę. Adguard Home poza czerpaniem danych z serwerów DNS ma mechanizm list filtrujących, które mają z 
kolei także różne źródła (definiowane) i stosuje je do tego co uzyskał już od tych publicznych dostawców, więc phishing 
potencjalny od serwera DNS jest ucinany drugą warstwą bezpieczeństwa.

>> "Nie musi mieć powodów" jest kluczem. Byłem przekonany, że ma powód.
>> Skoro tak, to jedyne wyjście dać mu jeden adres, mój lokalny.
>> A w razie przestojów serwera.. mieć przestoje.
> 
> Router może podawać swój adres. Sam może keszować, sam sprawdzać
> skąd da się czerpać wiedzę o strefach, sam przełączać. W routerach
> też zwykle siedzi Linux. Przeważnie z tym samym softem, co się go
> instaluje na "prawdziwych" komputerach. I przeważnie skonfigurowany
> słabo -- bo klienci nie mają zbyt dużych wymagań. Ale można zrobić
> to samemu.

Owszem, ale po co się z tym kopać i uzyskać tylko połowicznie to co mam w gotowym sofcie instalowanym jednym poleceniem 
w dokerze?

-- 
szopen

szopen napisał:
 
>>> Serwer DHCP jest w routerze, mam w GUI dwa pola na dwa adresy DNS.
>>> Pierwszy podaję mój lokalny, drugi adguarda (o tym niżej).
>> No i to mi wygląda na błąd kardynalny (o tym było wyżej).
>
> Ale co jest tym błędem i czyim? Bo tego nie chwytam nadal.

Równorzędne traktowanie dwóch różnych serwerów.

> Jeśli chodzi o te dwa pola z routera to jedno nazywa się
> "Preffered DNS server" a drugie "Alternative DNS server".
> To trochę narzuciło mi sposób myślenia o tym mechanizmie.

Też bym może tak pomyślał, zwłaszcza że akurat serwer DHCP mógłby
takie scenariusze obsłużyć (o czym pisałem). Ale z tego co do tej
pory przeczytałem wnioskuję, że tak nie jest -- to chyba są po
prostu adresy przekazywane przez opcję 6 DHCP.

> Ale router nie ma tak zaawansowanego serwera DNS jak Adguard Home
> czy Pi-Hole (jego konkurent).

A jaki ma?! W routerach nie widziałem niczego poza dnsmasq. Nie da
się o niem powiedzieć, że mu czegoś brakuje. Sklonowałem sobie przed
chwilą tego Adguarda z githuba. Nie żebym jakoś pracowicie analizował,
ale nie widzę tam żadnego pełnoprawnego DNS, jest tylko cache. W pliku
CHANGELOG.md da się wygrepować, że autorzy dodając funkcje wzorowali
się na zachowaniu dnsmasq.

>>> Nie ma więc przypadku i braku równorzędności.
>> Ale publiczny serwer adguarda nie zna lokalnych domen, więc jednak
>> ta równość jest zachwaina.
>
> Publiczny nie, ale Adguard Home w dokerze już tak. A Adguard Home
> używa wielu różnych, definiowanych przeze mnie, dostawców publicznych
> DNS i robi swój kesz, który jest używany w całej sieci lokalnej + zna
> moje wewnętrzne pseudodomeny.

Moja uwaga dotyczyła wyłącznie braku równorzędności. Czyli zgadzamy się.

>> Rozbawił mnie nieco opis zapobiegani phishingowi w ten sposób, że
>> samemu się phishing robi. Jest zatem phishing zły i jest dobry.
>> Jeśli ktoś z tym się zgadza, to nie ma sprawy.
>
> Trochę Ci ten ubaw utnę. Adguard Home poza czerpaniem danych
> z serwerów DNS ma mechanizm list filtrujących, które mają z kolei
> także różne źródła (definiowane) i stosuje je do tego co uzyskał
> już od tych publicznych dostawców, więc phishing potencjalny od
> serwera DNS jest ucinany drugą warstwą bezpieczeństwa.

Taka na przykład Wikipedia definiuje "phishing" jako "metodę oszustwa,
w której przestępca podszywa się pod inną osobę lub instytucję w celu
wyłudzenia poufnych informacji". Zamiana informacji zawartych w domenach
czymś własnym jak najbardziej pasuje do tej dewinicji. I żeby nie było,
sam wielokrotnie tak robiłem w *swoich* serwerach DNS. Zmieniałem te
domeny, które *dla mnie* były uciążliwe, nie polegałem na *obcych*
listach.

Gdybym był Złym Człowiekiem, to bym w pierwszej kolejności atakował
DNS-y różnych Adguardów, a nie takich żuczków jak ja. Jedna wrzutka
-- i już mamy miliony oszukanych. Nie, nie jestem przeczulony, chodzi
o to, że nie warto ponosić nawet małego ryzyka, jeśli samodzielne
rozwiązanie wymaga tylko małego wysiłku.

> Owszem, ale po co się z tym kopać i uzyskać tylko połowicznie to
> co mam w gotowym sofcie instalowanym jednym poleceniem w dokerze?

Ja uważam, że w ogóle nie warto się kopać. Chyba nie mam problemów,
które mógłby mi rozwiązać Adguard Home czy inny Pi-Hole.

-- 
Jarek

On 25.04.2024 12:45, Jarosław Sokołowski wrote:
>> Ale router nie ma tak zaawansowanego serwera DNS jak Adguard Home
>> czy Pi-Hole (jego konkurent).
> 
> A jaki ma?! W routerach nie widziałem niczego poza dnsmasq. Nie da
> się o niem powiedzieć, że mu czegoś brakuje. Sklonowałem sobie przed
> chwilą tego Adguarda z githuba. Nie żebym jakoś pracowicie analizował,
> ale nie widzę tam żadnego pełnoprawnego DNS, jest tylko cache. W pliku

No jak nie ma DNSa, skoro obsługuje requesty DNS na porcie 53?

> CHANGELOG.md da się wygrepować, że autorzy dodając funkcje wzorowali
> się na zachowaniu dnsmasq.

Dobre wzorce zawsze w cenie.

>> Trochę Ci ten ubaw utnę. Adguard Home poza czerpaniem danych
>> z serwerów DNS ma mechanizm list filtrujących, które mają z kolei
>> także różne źródła (definiowane) i stosuje je do tego co uzyskał
>> już od tych publicznych dostawców, więc phishing potencjalny od
>> serwera DNS jest ucinany drugą warstwą bezpieczeństwa.
> 
> Taka na przykład Wikipedia definiuje "phishing" jako "metodę oszustwa,
> w której przestępca podszywa się pod inną osobę lub instytucję w celu
> wyłudzenia poufnych informacji". Zamiana informacji zawartych w domenach
> czymś własnym jak najbardziej pasuje do tej dewinicji. I żeby nie było,
> sam wielokrotnie tak robiłem w *swoich* serwerach DNS. Zmieniałem te
> domeny, które *dla mnie* były uciążliwe, nie polegałem na *obcych*
> listach.

Rozumiem zagrożenie, ale właśnie przez to, że to jest projekt używany przez masę ludzi szanse na ukrycie fałszywych 
adresów jest nikłe. Poza tym musiałbym akurat otworzyć ten adres jaki właśnie podstawiono i to nim reszta świata to 
wykryje i wznieci alarm. Nikła szansa. Czuję się z tym dobrze.

> Gdybym był Złym Człowiekiem, to bym w pierwszej kolejności atakował
> DNS-y różnych Adguardów, a nie takich żuczków jak ja. Jedna wrzutka
> -- i już mamy miliony oszukanych. Nie, nie jestem przeczulony, chodzi
> o to, że nie warto ponosić nawet małego ryzyka, jeśli samodzielne
> rozwiązanie wymaga tylko małego wysiłku.

Wymaga sporego właśnie! Bo...

>> Owszem, ale po co się z tym kopać i uzyskać tylko połowicznie to
>> co mam w gotowym sofcie instalowanym jednym poleceniem w dokerze?
> 
> Ja uważam, że w ogóle nie warto się kopać. Chyba nie mam problemów,
> które mógłby mi rozwiązać Adguard Home czy inny Pi-Hole.

...Adguard Home czy Pi-Hole przede wszystkim zajmuje się upierdzielaniem requestów reklamowych i śledzących*. I to jest 
ich główny cel. Jak to zrobić na własną rękę i przy małym wysiłku?

* - u mnie obecnie >5% requestów jest ubijanych, a komputery/browsery działają jak działały. I jeszcze pewnie mniej 
zasobów zżerają per website.

-- 
szopen

szopen napisał:

>>> Ale router nie ma tak zaawansowanego serwera DNS jak Adguard Home
>>> czy Pi-Hole (jego konkurent).
>> A jaki ma?! W routerach nie widziałem niczego poza dnsmasq. Nie da
>> się o niem powiedzieć, że mu czegoś brakuje. Sklonowałem sobie przed
>> chwilą tego Adguarda z githuba. Nie żebym jakoś pracowicie analizował,
>> ale nie widzę tam żadnego pełnoprawnego DNS, jest tylko cache. W pliku
> No jak nie ma DNSa, skoro obsługuje requesty DNS na porcie 53?

Przekazuje zapytania do "prawdziwych" serwerów, a jak raz zapytał,
a termin przydatności do spożycia odpowiedzi nie minął, to odpowiada
z pamięci.

>> CHANGELOG.md da się wygrepować, że autorzy dodając funkcje wzorowali
>> się na zachowaniu dnsmasq.
> Dobre wzorce zawsze w cenie.

$ man dnsmasq
      dnsmasq - A lightweight DHCP and caching DNS server.

Ten też był projektowany do tego samego celu -- "caching DNS server".

>> Gdybym był Złym Człowiekiem, to bym w pierwszej kolejności atakował
>> DNS-y różnych Adguardów, a nie takich żuczków jak ja. Jedna wrzutka
>> -- i już mamy miliony oszukanych. Nie, nie jestem przeczulony, chodzi
>> o to, że nie warto ponosić nawet małego ryzyka, jeśli samodzielne
>> rozwiązanie wymaga tylko małego wysiłku.
>
> Wymaga sporego właśnie! Bo...
[...]
> ...Adguard Home czy Pi-Hole przede wszystkim zajmuje się upierdzielaniem
> requestów reklamowych i śledzących*. I to jest ich główny cel.
> Jak to zrobić na własną rękę i przy małym wysiłku?

Ja po prostu śledziłem zapytania DNS, w których widać nazwy serwerów.
Te uciążliwe (z reguły da się je rozpoznać po nazwie) dodawałem jakimś
skryptem jako strefę lokalnego serwera bind9, która prowdziła w buraczki.
Nie wkładałem w to żadnego wysiłku, a skutek był dobry. Ale to dawno było,
jakieś dwadzieścia lat temu.

> * - u mnie obecnie >5% requestów jest ubijanych, a komputery/browsery
> działają jak działały.

Teraz w zupełności wystarczają mi blokery w przeglądarce.

> I jeszcze pewnie mniej zasobów zżerają per website.

Zapewne. I to uznaję za wadę, którą mają również wymienione blokery.
Kiedyś argumentem za cięciem reklam było również przyspieszenie działania
w wolnej sieci, albo nawet obniżenie kosztów, gdy płaci się za transfer.
Dzisiaj szybkość nie jest żadną barierą, za to serwisy WWW orientują się,
że ktoś odcedza informacje od śmieci i czasem nerwowo na to reagują.

Czymś naprawdę przydatnym byłby pośredniczący serwer http (jak squid),
który pobiera *wszystko*, łącznie z reklamami, ale dalej przekazuje
tylko to, co może mieć jakąś wartość. Kilka razy zabierałem się za
napisanie czegoś podobnego, ale jakoś mi się nie chce. A może ktoś coś
wie o jakimś gotowcu?

-- 
Jarek