ISP mi odchytává DNS provoz. Co s tím?

turris1x
dns
dnssec

#1

Zdravím, mám Turris 1.0 a bohužel od počátku mám problémy s DNS a již jsem se konečně dokopal k tomu že to MUSÍM vyřešit.

Má situace je taková, že ISP odchytává veškerý provoz na portu 53 a přesměrovává jej na vlastní servery (ISP mé zjištění potvrdil a bylo mi oznámeno že je to z bezpečnostních důvodů a nehodlají na tom nic měnit). Z tohoto důvodu jsem nucen mít zakázané DNSSEC ve forisu.

Bohužel ani vypnutí DNSSEC neřeší problémy s překladem DNS. Pokud provedu dotaz na nějakou doménu, tak napoprvé nedostanu odpověď, pokud však dotaz hned zopakuji již se mi adresa přeloží např.:

root@turris:~# nslookup pes.cz
Server:	127.0.0.1
Address:	127.0.0.1#53
*** Can't find pes.cz: No answer
*** Can't find pes.cz: No answer

root@turris:~# nslookup pes.cz
Server:		127.0.0.1
Address:	127.0.0.1#53
Name::		pes.cz
Address 1::	81.2.196.222

Problémy to způsobuje i při “opkg update”, ten taky vždy napoprvé selže protože se nepřeloží doménové jméno. Permanentně mi chodí chyby “Updater failed: unreachable https://repo.turris.cz/turris/lists/base.lua”.

Na zařízeních v síti musím mít nastaveny DNS servery od ISP (s turrissem je to nepoužitelné, a jakékoliv jiné stejnak nemají smysl protože je vše odchyceno u ISP). Pokud Turris nahradím jiným routerem běžícím na openWRT tak vše jede bez problému a stabilně jak z daného routeru tak i z všech ostatních zařízeních v síti.

V nastavení mám DNSSEC i přeposílání vypnuté, IPv6 zakázané a factory resetů již proběhlo nepočítaně.

Výpis z uci show resolver jsem umístil na https://pastebin.com/tTUPFzTf .

Co s tím, má někdo nejaký nápad aby bylo vše spolehlivé a nemusel Turris “do koše”?


#2

Jako laikovi mi připadá, že je to problém providera … jeho jméno je tajné ?


#3

Změna providera není možná?


#4

Ano je to částečně problém ISP, bohužel jsem jediný kdo má problém protože ostatní mají “hloupý router” takže nic řešit nebudou. Změna ISP() bohužel není možná - je jediný v okolí.

Na druhé straně pokud na Turrisu vypnu DNSSEC tak bych čekal že DNS pojede bez problémů - dnsmasq v čistém openWrt nemá s překladem problém.


#5
root@turris:~# nslookup pes.cz
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:      pes.cz
Address 1: 81.2.196.222
*** Can't find pes.cz: No answer

Jak se tváří jiné domény?


#6

Tak teď se zdá že vše funguje. Zkusil jsem to i na několika náhodných doménách, i zkusil Turris restartovat aby se promazala cache.

nslookup pes.cz
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:      pes.cz
Address 1: 81.2.196.222
*** Can't find pes.cz: No answer
root@turris:~# nslookup github.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:      github.com
Address 1: 192.30.253.113
Address 2: 192.30.253.112
*** Can't find github.com: No answer
root@turris:~# nslookup dixx.cz
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:      dixx.cz
Address 1: 46.28.105.2
Address 2: 2a02:2b88:1:4::16
root@turris:~# nslookup zdravymed.cz
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:      zdravymed.cz
Address 1: 46.28.105.2
Address 2: 2a02:2b88:1:4::16

Jen nechápu proc je u některých “*** Can’t find github.com: No answer”

Jinak ISP je Infos.


#7

Tipuji že ISP odchytává packety které mu nejsou adresovány.

Jako test bych použil třeba:

$ dig github.com @192.52.178.30 #k.gtld-servers.net - tedy auth. pro com

; <<>> DiG 9.10.3-P4 <<>> github.com @192.52.178.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42189
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 2
;; WARNING: recursion requested but not available

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

;; AUTHORITY SECTION:
github.com.             172800  IN      NS      ns1.p16.dynect.net.
github.com.             172800  IN      NS      ns3.p16.dynect.net.
github.com.             172800  IN      NS      ns2.p16.dynect.net.
github.com.             172800  IN      NS      ns4.p16.dynect.net.
github.com.             172800  IN      NS      ns-520.awsdns-01.net.
github.com.             172800  IN      NS      ns-421.awsdns-52.com.
github.com.             172800  IN      NS      ns-1707.awsdns-21.co.uk.
github.com.             172800  IN      NS      ns-1283.awsdns-32.org.

;; ADDITIONAL SECTION:
ns-421.awsdns-52.com.   172800  IN      A       205.251.193.165

;; Query time: 19 msec
;; SERVER: 192.52.178.30#53(192.52.178.30)
;; WHEN: Mon Mar 11 15:20:59 CET 2019
;; MSG SIZE  rcvd: 275

#8

Ano ISP odchytává vše. Pokud si na svém VPS spustím primitivní echo server na portu 53 tak to tam nedoleze.

Výsledek výše zmíněného dig je jiný - což předpokládám že je špatně, protože jeden server by měl vždy odpovědět všem stejně.

; <<>> DiG 9.11.5-P1 <<>> github.com @192.52.178.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63876
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 12

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

;; ANSWER SECTION:
github.com.		60	IN	A	192.30.253.112
github.com.		60	IN	A	192.30.253.113

;; AUTHORITY SECTION:
github.com.		375	IN	NS	ns4.p16.dynect.net.
github.com.		375	IN	NS	ns-1283.awsdns-32.org.
github.com.		375	IN	NS	ns-520.awsdns-01.net.
github.com.		375	IN	NS	ns1.p16.dynect.net.
github.com.		375	IN	NS	ns3.p16.dynect.net.
github.com.		375	IN	NS	ns2.p16.dynect.net.
github.com.		375	IN	NS	ns-421.awsdns-52.com.
github.com.		375	IN	NS	ns-1707.awsdns-21.co.uk.

;; ADDITIONAL SECTION:
ns1.p16.dynect.net.	955	IN	A	208.78.70.16
ns2.p16.dynect.net.	955	IN	A	204.13.250.16
ns3.p16.dynect.net.	955	IN	A	208.78.71.16
ns4.p16.dynect.net.	955	IN	A	204.13.251.16
ns-421.awsdns-52.com.	3307	IN	A	205.251.193.165
ns-421.awsdns-52.com.	3307	IN	AAAA	2600:9000:5301:a500::1
ns-520.awsdns-01.net.	3600	IN	A	205.251.194.8
ns-1283.awsdns-32.org.	3600	IN	A	205.251.197.3
ns-1283.awsdns-32.org.	3600	IN	AAAA	2600:9000:5305:300::1
ns-1707.awsdns-21.co.uk. 2851	IN	A	205.251.198.171
ns-1707.awsdns-21.co.uk. 2851	IN	AAAA	2600:9000:5306:ab00::1

;; Query time: 15 msec
;; SERVER: 192.52.178.30#53(192.52.178.30)
;; WHEN: Mon Mar 11 15:24:23 CET 2019
;; MSG SIZE  rcvd: 503

#9

OK, jasně. Jedna možnost by bylo DNS přes TLS, ale na to v Turris 1.x není klikátko a možná to tak ani není rozumně jednoduché nastavit. Bez toho je tedy otázka zda vůbec DNS server na Turrisu mít/používat, protože jediné co by mohl dělat je lokální cache – což asi nebude znatelný rozdíl, když každý klient cache má a ISP jistě taky.

No, pro jednoduché nastavení, mám podezření, že přeposílání s vypnutým DNSSEC by mělo chodit (škrtátka ve Foris / DNS). Je celkem jedno kam se bude posílat, protože evidentně odpovědi přijdou stejně od serverů ISP.


#10

No, nechci tady moc řešit produktové nabídky, ale myslím že mobilní operátoři (v CZ) nabízejí LTE pro fixní stanice (nebo jak bych to nazval) za relativně rozumných podmínek, na rozdíl od LTE pro mobily.


#12

Mně osobně vadí zdaleka nejvíce to odchytávání cizích packetů (vydávání se za cizí servery). I na to tedy existují různé záminky, například bezpečnostní nebo urychlující.


#13

Turris 1.x má jako DNS resolver Unbound, na který nejsem odborník, ale tady je můj odhad:

V nastavení Forisu bych zkusil vypnout DNSSEC a zapnout forwardování (přeposílání). To je nejblíž k nastavení, které ISP vynucuje pomocí přesměrování provozu.

Pokud nebude fungovat ani to, tak jedině do /etc/resolv.conf nacpat adresy od ISP a Unbound úplně opustit.


#14

Tak musím se přiznat že poslední větší test různých kombinací nastavení jsem prováděl více jak před měsícem. Když jsem však před 3 dny ještě zkusil zapnout forwarding , jak psal vcunat, začalo vše fungovat a do dneška jsem nezaznamenal žádnou chybu ani jakýkoliv problém.

Možnost použít DNS přes TLS mě vůbec nenapadla . Zkusím si s tím pohrát a zprovoznit.


#15

Tak bohužel jsem se ukvapil. Na Turrisu se zda že vše funguje, ale pokud jsem na počítači nastavil jako DNS Turiis, tak to na počítači začalo dělat úplný nesmysly :

phebix@phebix-ProBook:~$ ssh a2.phebix.cz
ssh: Could not resolve hostname a2.phebix.cz: Temporary failure in name resolution

phebix@phebix-ProBook:~$ host a2.phebix.cz
a2.phebix.cz has address 37.205.11.147
a2.phebix.cz has IPv6 address 2a03:3b40:100::1:61
Host a2.phebix.cz not found: 2(SERVFAIL)

phebix@phebix-ProBook:~$ host a2.phebix.cz
a2.phebix.cz has address 37.205.11.147
a2.phebix.cz has IPv6 address 2a03:3b40:100::1:61
Host a2.phebix.cz not found: 2(SERVFAIL)

phebix@phebix-ProBook:~$ host pes.cz
pes.cz has address 81.2.196.222
Host pes.cz not found: 2(SERVFAIL)

phebix@phebix-ProBook:~$ host pes.cz
Host pes.cz not found: 2(SERVFAIL)

phebix@phebix-ProBook:~$ host pes.cz
pes.cz has address 81.2.196.222
pes.cz mail is handled by 10 mx.forpsi.com.

phebix@phebix-ProBook:~$ ssh a2.phebix.cz
// USPESNE PRIPOJENO

Výše zmíněné jsem provedl hned po sobě v jedné minutě a pokaždé jsem získal něco jiného.

Zkoušel už někdo reálně nastavit DNS over TLS? Jstli má to tomu někdo nějaké tipy / poznatky ?


#16

Mám nastaveno, Turris 1.x.
Funguje bez problémů.
Vycházel jsem z návodu na How to configure encrypted unbound DNS over TLS

Jen je potřeba myslet, že nastavení se zapíná v /etc/config/resolver

V případě otázek se klidně ptej.

/špatný odkaz opraveno


#17

@Phebix Pomohlo, nebo jak jsi dopadl ? :slight_smile:


#18

Obdivuji tvou trpělivost. Hned ve svém druhém příspěvku jsi v podstatě popsal možné řešení .
Pokud ostatní routery používající dnsmasq nemají problém, proč se dal trápit a používat nebo jiného .
Já jsem ke stejnému rozhodnutí dospěl tři týdny po tom, co mi MOX dorazil domů.
Od té doby, co jsem přepnul na dnsmasq nemám problém…


#19

Tady se jedná o úplně jiný problém než popisujete Vy a není nutné Vaše řešení popsat do čtvrtého vlákna (tři z toho v angličtině), co jsem se podíval do ostatních vláken do kterých jste přispěl, tak tam popisujete problém s lokálními hostname. I když jste použil DNSSEC na dnsmasq-u, tak jste dostával timeout for dns queries, takže ta chyba je někde jinde. Pravděpodobně na straně poskytovatele internetu. V tom případě je zkusit vypnout, případně zapnout forwardování v administračním rozhraní Foris, abychom se na to podívali, ale je nutné použít Knot Resolver, případně Unbound. Pokud Vám ani to nepomohlo, tak v dokumentaci je článek přesně pro tento typ problému, ale ani jednou jsme je od Vás neobdrželi debugovací výstup, takže o tom pouze můžeme polemizovat. Nicméně tohle sem do tohoto vlákna nepatří a je to OT.


V prvním příspěvku je uvedené, že se jedná o hijacking DNS trafficu, které je dle informací od poskytovatele internetu z bezpečnostních důvodu. Navíc se tady jedná o Unbound, který běží na routerech Turris 1.0 a Turris 1.1. Dvě možná řešení, zde již byla uvedená.

  • DNS over TLS
    Nemam to otestované, ale v Turris OS 3.11.3, která je v RC je nejnovější verze Unboundu ve které se nachází lepší podpora DoT. V tuto chvíli to není na kliknutí ve Forisu, ale v nejbližších dnech bych si to rád nastavil na svém domacím routeru.

  • vypnout DNSSEC (ve výchozím stavu by to mělo být zapnuté, ale v tomto případě je to možné řešení problému) Více informací, proč mí zapnutý DNSSEC najdete např. zde.
    A zapnout forwardování v administračním rozhraní Foris.

Jak bylo řečené, tak bych @Phebix poprosil o informaci, zda uvedená řešení pomohla. Pokud ne, tak budeme rádi, když nám pošlete debugovací výstup dle Debugging DNS problems on Turris routers.


#20

Mé poznatky, možná nikam nepovedu - ale co kdyby, víc hlav, víc rozumu…

Mě to zase připadá, že má problém s internetem jako takovým. Chvilku mu to jde, pak zase ne…, osobně bych zkusil, jestli je problém jenom v DNS a pokusil se připojovat pokud možno na IP adresy.

Možná má i problém IPv4 @ IPv6:

Zkusil jsem ssh na IPv6 a tam mi přístup byl odepřen, s ssh na IPv4 byl přístup povolen.


#21

IP adresy patří vpsFree. Na nich nejspíše turrise neprovozuje, takže toto zkoušení je k ničemu.

Řešení i popis problému již popsal Pepe.