Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: Pepa 22. 06. 2011, 10:15:01

Název: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Pepa 22. 06. 2011, 10:15:01: Zdravim vsechny!

Poradi nekdo s nasledujicim problemem?
Na domaci siti mam svuj DNS server, ktery funguje jako resolver. Je to aktualizovany stable Debian+Bind, mam vypnuty IPv6. Pridal jsem do konfigurace DNSSEC a Internet prestal fungovat. Nedojde k prelozeni jmena na IP adresu (nejede napr. ping a "dig dnssec.cz +dnssec +multi" je prazdny - QUERY: 1, ANSWER: 0). Pripojeni je pres T-Mobile (na USB je nejaky modem a vytaci se spojeni pres ppp protokol).

A ted to zajimavy. Zacal jsem experimentovat a onen DNS server s tou samou konfiguraci (BIND s DNSSEC) jsem pripojil pres O2. A zacalo to fungovat.

Takze - na O2 DNSSEC jede, na T-Mobile ne.

Taky jsem si pres tcpdump zachytil komunikaci a podival se na to.
Co je hned videt, tak u T-Mobilu je opakovane (13x) posilan dotaz "Standard query DNSKEY <Root>" na ruzne adresy (ROOT servery?) a chodi mu odtamtud odpoved "Standard query response OPT", kde ale zadny DNSKEY klic neni. Co je ale zajimavy, tak tyto odpovedi maji TTL=255(!) a v poli "Additional records" se objevuje nejaka IP adresa, ktera podle WHOIS zaznamu patri T-Mobile Czech Republic.

Jen jeste dodam, ze kdyz jsem mel pred nejakou dobou docasne IPv6 pres 6to4 tunel, tak to DNSSEC jelo i pres ten T-Mobile.

DOTAZ:
Chtel bych to DNSSEC rozchodit i s tim T-Mobilem. Mam neco spatne nastavene?
Je mozne, ze T-Mobile nejakym zpusobem pozmenuje moje DNS dotazy, takze mi znemoznuje bezpecne overeni dns dotazu pres DNSSEC?

Pepa

---------------------------

Prikladam vypis ze syslogu:

Jun 21 19:54:58 alpha named[1323]: DNS format error from 192.203.230.10#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.203.230.10#53
Jun 21 19:54:58 alpha named[1323]: DNS format error from 192.58.128.30#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.58.128.30#53
Jun 21 19:54:58 alpha named[1323]: DNS format error from 198.41.0.4#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 198.41.0.4#53
Jun 21 19:54:58 alpha named[1323]: DNS format error from 192.228.79.201#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.228.79.201#53
Jun 21 19:54:58 alpha named[1323]: DNS format error from 199.7.83.42#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 199.7.83.42#53
Jun 21 19:54:58 alpha named[1323]: DNS format error from 192.5.5.241#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.5.5.241#53
Jun 21 19:54:58 alpha named[1323]: DNS format error from 192.112.36.4#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.112.36.4#53
Jun 21 19:54:58 alpha named[1323]: DNS format error from 128.63.2.53#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:58 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 128.63.2.53#53
Jun 21 19:54:59 alpha named[1323]: DNS format error from 193.0.14.129#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:59 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 193.0.14.129#53
Jun 21 19:54:59 alpha named[1323]: DNS format error from 202.12.27.33#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:59 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 202.12.27.33#53
Jun 21 19:54:59 alpha named[1323]: DNS format error from 192.33.4.12#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:59 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.33.4.12#53
Jun 21 19:54:59 alpha named[1323]: DNS format error from 192.36.148.17#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:59 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.36.148.17#53
Jun 21 19:54:59 alpha named[1323]: DNS format error from 128.8.10.90#53 resolving ./DNSKEY: reply has no answer
Jun 21 19:54:59 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 128.8.10.90#53
Jun 21 19:54:59 alpha named[1323]: error (broken trust chain) resolving 'cz/DS/IN': 192.5.5.241#53
Jun 21 19:54:59 alpha named[1323]: error (broken trust chain) resolving 'cz/DNSKEY/IN': 194.0.14.1#53
Jun 21 19:54:59 alpha named[1323]: error (broken trust chain) resolving 'dnssec.cz/DS/IN': 194.0.13.1#53
Jun 21 19:54:59 alpha named[1323]: error (broken trust chain) resolving 'dnssec.cz/DNSKEY/IN': 194.0.12.1#53
Jun 21 19:54:59 alpha named[1323]: error (broken trust chain) resolving 'dnssec.cz/A/IN': 193.29.206.1#53

---------------------------

root@alpha:~# dig dnssec.cz +dnssec +multi

; <<>> DiG 9.7.3 <<>> dnssec.cz +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41657
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.cz. IN A

;; Query time: 1794 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 21 17:45:39 2011
;; MSG SIZE rcvd: 38
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Ondřej Surý 22. 06. 2011, 10:54:43: Přes T-Mobile znamená, že používáte jejich forwardery nebo ne?
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Pepa 22. 06. 2011, 11:19:55: Nepouzivam zadny forwarder. Delam si "resolving" kompletne sam.

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Ondřej Caletka 22. 06. 2011, 11:28:20: Skoro to vypadá, jako by T-M používal transparentní DNS resolvery, možná za účelem ještě účinnější ochrany před Kinderpornem. A možná jejich transparentní resolvery stripují RRSIG záznamy...

Ani bych se nedivil, potom co jsem zjistil, co provádějí sítě T-M (včetně ADSL) s protokolem SIP.

Zkusím to taky vyzkoušt, dám vědět, jestli se mi to taky projevuje.
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Pepa 22. 06. 2011, 12:17:51: Zde je ulozeny tcpdump chybneho (pres T-Mobile) a spravneho (pres O2) DNS dotazu.

http://www.filesonic.com/file/1286694704/digDNSSEC.cap
http://www.filesonic.com/file/1286694714/digDNSSEC.txt
http://www.filesonic.com/file/1286694784/digBtDNSSEC.cap
http://www.filesonic.com/file/1286694794/digBtDNSSEC.txt

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Mordae 22. 06. 2011, 14:08:00: Citace: Ondřej Caletka 22. 06. 2011, 11:28:20
Skoro to vypadá, jako by T-M používal transparentní DNS resolvery, možná za účelem ještě účinnější ochrany před Kinderpornem. A možná jejich transparentní resolvery stripují RRSIG záznamy...

Wow, to je ovsem docela krute. Co na to oficialni telefoni linka T-Mobilu?
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Pepa 22. 06. 2011, 14:34:43: Zatim jsem T-Mobile nekontaktoval. Chtel jsem to s nekym probrat, jestli nekde nedelam blbou chybu.

Tim jste mi pripomnel, ze jsem zapomnel uvest, ze tzv. "T-Mobile Internetovy optimalizator" mam vypnuty. (tusim, že to "optimalizuje" obrazky a kdo vi co jeste...)

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: alfi 22. 06. 2011, 15:21:00: jak vypadají dotazy přímo na konkrétní servery? ppp klient na 127.0.0.1 něco dostane z dhcp, obvykle dva různé. tj. co vrací dotazy přímo na ně? (dig ... @dns_ip) chovají se stejně, každý jinak.. ? chovají se různě i podle toho, ze které sítě se přistupuje (tm vs. o2)? :-)

SERVFAIL vypadá spíš na něco rozbitého přímo v tom dns serveru.. a 127.0.0.1 to jen opakuje - a nebo je rozbitý sám..
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Pepa 22. 06. 2011, 16:52:21: Pres O2 jede DNSSEC bez problemu. To asi vypisovat nebudu.

U T-Mobilu, kdyz si zapnu DNSSEC, tak to vypada takto:

1. dotaz pres muj DNS server (resolver)

root@alpha:~# dig dnssec.cz +dnssec +multi

; <<>> DiG 9.7.3 <<>> dnssec.cz +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61536
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.cz. IN A

;; Query time: 2562 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jun 22 16:12:11 2011
;; MSG SIZE rcvd: 38

2. to same, ale navic s volbou +cd (checking disabled)

root@alpha:~# dig dnssec.cz +cd +dnssec +multi

; <<>> DiG 9.7.3 <<>> dnssec.cz +cd +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23126
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.cz. IN A

;; ANSWER SECTION:
dnssec.cz. 7200 IN A 217.31.205.51
dnssec.cz. 7200 IN RRSIG A 5 2 7200 20110701080302 (
20110617080302 55673 dnssec.cz.
P7CLJ0+De41qjuAr9GB+z80sKstkRwykB57xy7pgN8dp
43zkUtlA6z3R+JaPooD2Uut2/9iqD9DifrQJsl9DiRXZ
GTBjYVzN1CJ4e3M5Ad8siSOr8ft4lfMIn12dNg5LdQpJ
klTLqiXLv4p6wufzK3TYgRAvNdu5ZW6m2DXb5M4= )

;; AUTHORITY SECTION:
dnssec.cz. 7200 IN NS b.ns.nic.cz.
dnssec.cz. 7200 IN NS a.ns.nic.cz.
dnssec.cz. 7200 IN RRSIG NS 5 2 7200 20110701080302 (
20110617080302 55673 dnssec.cz.
JHPl5Z1NMJVDxoTYrYVa+e6lNy/4vwkVgNl01bKwcR9F
b3Yo5qAGDKtD0PCS8pzqdd8CGDz04xT1pDAkVzurvpB+
wJ5/MPhS6D5/HissMDOHSmqA1Lal1VBhWxLes2pzIlvw
0fuW0wIBzQC01xSOITZzlanBQeYNjq1u9ZAdO7w= )

;; Query time: 281 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jun 22 16:44:25 2011
;; MSG SIZE rcvd: 431

3. dotaz smerovany na jiny (open) DNS server

root@alpha:~# dig @217.31.204.130 dnssec.cz +dnssec +multi

; <<>> DiG 9.7.3 <<>> @217.31.204.130 dnssec.cz +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41934
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.cz. IN A

;; ANSWER SECTION:
dnssec.cz. 7200 IN A 217.31.205.51
dnssec.cz. 7200 IN RRSIG A 5 2 7200 20110701080302 (
20110617080302 55673 dnssec.cz.
P7CLJ0+De41qjuAr9GB+z80sKstkRwykB57xy7pgN8dp
43zkUtlA6z3R+JaPooD2Uut2/9iqD9DifrQJsl9DiRXZ
GTBjYVzN1CJ4e3M5Ad8siSOr8ft4lfMIn12dNg5LdQpJ
klTLqiXLv4p6wufzK3TYgRAvNdu5ZW6m2DXb5M4= )

;; AUTHORITY SECTION:
dnssec.cz. 7200 IN NS a.ns.nic.cz.
dnssec.cz. 7200 IN NS b.ns.nic.cz.
dnssec.cz. 7200 IN RRSIG NS 5 2 7200 20110701080302 (
20110617080302 55673 dnssec.cz.
JHPl5Z1NMJVDxoTYrYVa+e6lNy/4vwkVgNl01bKwcR9F
b3Yo5qAGDKtD0PCS8pzqdd8CGDz04xT1pDAkVzurvpB+
wJ5/MPhS6D5/HissMDOHSmqA1Lal1VBhWxLes2pzIlvw
0fuW0wIBzQC01xSOITZzlanBQeYNjq1u9ZAdO7w= )

;; Query time: 151 msec
;; SERVER: 217.31.204.130#53(217.31.204.130)
;; WHEN: Wed Jun 22 16:11:59 2011
;; MSG SIZE rcvd: 431

Jestli jste to myslel jinak, tak uvedte prosim konkretni priklad.
Jinak opravdu dobre je to videt v tech *.cap souborech, viz vyse.

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: alfi 23. 06. 2011, 10:11:18: Citace: Pepa 22. 06. 2011, 16:52:21
Jestli jste to myslel jinak, tak uvedte prosim konkretni priklad.
tm i o2 při připojení nějakou dns přidělují. používá je named jako nadřazené? a jak vypadá dotaz přímo k nim - tj. mimo 127.0.0.1?
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Pepa 23. 06. 2011, 11:48:31: Nepouzivam pridelene DNS servery. Mam vlastni server, ktery dela vyhledani domenoveho jmena sam (zacina u tzv. root serveru, ty ho odkazi na nejaky server pod nimi, atd., az se dostane k pc, ktere mu dokaze prelozit hledane jmeno na ip adresu, viz. dns na google).

Pouzivat DNS servery sveho ISP (T-Mobile) a ani jine "open" DNS servery nechci. Tecka.

Dotaz pomoci dig na jiny server jsem zkousel, viz. predchozi prispevek.
Odpoved prijde a to podepsana a overena pomoci DNSSEC. (jestli to spravne interpretuji)
Ale to mi rika, jak funguje onen dotazovany server.
Ja chci, aby spravne fungoval ten muj.

Pripominam, ze kdyz celou komunikace presmeruju do O2, tak se to ihned rozjede.
Spis mi to pripadne, ze T-Mobile neco blokuje.
Coz pokud by byla pravda, tak by mi dost vadilo, protoze od sveho ISP cekam, ze mi pripoji "draty" a nediva se co posilam a eventuelne nerozhoduje, jestli to, co posilam muzu posilat.

Ale mozna taky mam neco spatne u sebe. To bych prave rad zjistil.

Poslal jsem dotaz na T-Mobile, kde jsem celou situaci popsal. Jsem zjedav, jestli neco napisi.

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Ondřej Caletka 23. 06. 2011, 12:53:28: Jediné, co mě teď napadá, je že někde v síti T-M neprojdou příliš dlouhé UDP zprávy. To by vysvětlovalo záznamy v logu:
Kód: [Vybrat]
Jun 21 19:54:59 alpha named[1323]: error (FORMERR) resolving './DNSKEY/IN': 192.36.148.17#53 Jun 21 19:54:59 alpha named[1323]: DNS format error from 128.8.10.90#53 resolving ./DNSKEY: reply has no answer
Zkuste spustit na obou připojeních DNSSEC tester (http://www.dnssec-tester.cz/), ten by takový problém mohl pomoci odhalit.
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Ondřej Caletka 23. 06. 2011, 14:14:14: Tak ještě něco, stáhnul jsem si ty dumpy a jsem si jist, že T-mobile modifikuje data na cestě:

Předvedu to dvojicí shodných dotazů na shodný server i.root-servers.net s adresou 192.36.148.17. Nejprve O2:
Kód: [Vybrat]
No. Time Source Destination Protocol Info 4 0.042980 192.168.0.1 192.36.148.17 DNS Standard query DNSKEY <Root> Frame 4: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) Ethernet II, Src: CameoCom_b7:be:ee (00:40:f4:b7:be:ee), Dst: CompalEl_d3:59:53 (00:0f:b0:d3:59:53) Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.36.148.17 (192.36.148.17) User Datagram Protocol, Src Port: 34272 (34272), Dst Port: domain (53) Domain Name System (query) [Response In: 5] Transaction ID: 0xf27a Flags: 0x0010 (Standard query) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 1 Queries <Root>: type DNSKEY, class IN Name: <Root> Type: DNSKEY (DNS public key) Class: IN (0x0001) Additional records <Root>: type OPT Name: <Root> Type: OPT (EDNS0 option) UDP payload size: 4096 Higher bits in extended RCODE: 0x0 EDNS0 version: 0 Z: 0x8000 Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs) Bits 1-15: 0x0 (reserved) Data length: 0 No. Time Source Destination Protocol Info 5 0.079378 192.36.148.17 192.168.0.1 DNS Standard query response DNSKEY DNSKEY DNSKEY RRSIG Frame 5: 925 bytes on wire (7400 bits), 925 bytes captured (7400 bits) Ethernet II, Src: CompalEl_d3:59:53 (00:0f:b0:d3:59:53), Dst: CameoCom_b7:be:ee (00:40:f4:b7:be:ee) Internet Protocol, Src: 192.36.148.17 (192.36.148.17), Dst: 192.168.0.1 (192.168.0.1) User Datagram Protocol, Src Port: domain (53), Dst Port: 34272 (34272) Domain Name System (response) [Request In: 4] [Time: 0.036398000 seconds] Transaction ID: 0xf27a Flags: 0x8410 (Standard query response, No error) Questions: 1 Answer RRs: 4 Authority RRs: 0 Additional RRs: 1 Queries <Root>: type DNSKEY, class IN Name: <Root> Type: DNSKEY (DNS public key) Class: IN (0x0001) Answers <Root>: type DNSKEY, class IN Name: <Root> Type: DNSKEY (DNS public key) Class: IN (0x0001) Time to live: 2 days Data length: 136 Flags: 0x0100 Protocol: 3 Algorithm: RSA/SHA-256 Key id: 34525Všechno je v pořádku, dotaz zněl na DNSKEY, DNSKEY byl vrácen...

Nyní ten samý dotaz na tu samou adresu přes T-M:
Kód: [Vybrat]
No. Time Source Destination Protocol Info 29 2.700126 89.24.27.50 192.36.148.17 DNS Standard query DNSKEY <Root> Frame 29: 72 bytes on wire (576 bits), 72 bytes captured (576 bits) Linux cooked capture Internet Protocol, Src: 89.24.27.50 (89.24.27.50), Dst: 192.36.148.17 (192.36.148.17) User Datagram Protocol, Src Port: 65418 (65418), Dst Port: domain (53) Source port: 65418 (65418) Destination port: domain (53) Length: 36 Checksum: 0x732b [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (query) [Response In: 30] Transaction ID: 0x02ff Flags: 0x0010 (Standard query) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 1 Queries <Root>: type DNSKEY, class IN Name: <Root> Type: DNSKEY (DNS public key) Class: IN (0x0001) Additional records <Root>: type OPT Name: <Root> Type: OPT (EDNS0 option) UDP payload size: 4096 Higher bits in extended RCODE: 0x0 EDNS0 version: 0 Z: 0x8000 Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs) Bits 1-15: 0x0 (reserved) Data length: 0 0000 00 04 02 00 00 00 00 00 00 00 00 00 00 00 08 00 ................ 0010 45 00 00 38 29 62 00 00 40 11 88 d3 59 18 1b 32 E..8)b..@...Y..2 0020 c0 24 94 11 ff 8a 00 35 00 24 73 2b 02 ff 00 10 .$.....5.$s+.... 0030 00 01 00 00 00 00 00 01 00 00 30 00 01 00 00 29 ..........0....) 0040 10 00 00 00 80 00 00 00 ........ No. Time Source Destination Protocol Info 30 2.785972 192.36.148.17 89.24.27.50 DNS Standard query response OPT Frame 30: 88 bytes on wire (704 bits), 88 bytes captured (704 bits) Linux cooked capture Internet Protocol, Src: 192.36.148.17 (192.36.148.17), Dst: 89.24.27.50 (89.24.27.50) User Datagram Protocol, Src Port: domain (53), Dst Port: 65418 (65418) Source port: domain (53) Destination port: 65418 (65418) Length: 52 Checksum: 0xe84d [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (response) [Request In: 29] [Time: 0.085846000 seconds] Transaction ID: 0x02ff Flags: 0x8580 (Standard query response, No error) Questions: 1 Answer RRs: 1 Authority RRs: 0 Additional RRs: 1 Queries <Root>: type DNSKEY, class IN Name: <Root> Type: DNSKEY (DNS public key) Class: IN (0x0001) Answers <Root>: type OPT Name: <Root> Type: OPT (EDNS0 option) UDP payload size: 4096 Higher bits in extended RCODE: 0x0 EDNS0 version: 0 Z: 0x8000 Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs) Bits 1-15: 0x0 (reserved) Data length: 0 Additional records <Root>: type A, class IN, addr 62.141.6.172 Name: <Root> Type: A (Host address) Class: IN (0x0001) Time to live: 18 hours, 12 minutes, 15 seconds Data length: 4 Addr: 62.141.6.172 (62.141.6.172) 0000 00 00 02 00 00 00 00 00 00 00 00 00 00 00 08 00 ................ 0010 45 00 00 48 85 99 00 00 ff 11 6d 8b c0 24 94 11 E..H......m..$.. 0020 59 18 1b 32 00 35 ff 8a 00 34 e8 4d 02 ff 85 80 Y..2.5...4.M.... 0030 00 01 00 01 00 00 00 01 00 00 30 00 01 00 00 29 ..........0....) 0040 10 00 00 00 80 00 00 00 c0 0c 00 01 00 01 00 00 ................ 0050 ff ff 00 04 3e 8d 06 acDotaz zněl stejně, v odpovědi chybí DNSKEY, naopak sekce ADDITIONAL tvrdí, že root zóna má A záznam (!!!) s adresou 62.141.6.172.

Můžete hádat třikrát, na jakou reverzní adresu se tato IP adresa mapuje:
Kód: [Vybrat]
$ host 62.141.6.172 172.6.141.62.in-addr.arpa domain name pointer ums.internet.t-mobile.cz.
T-Mobile vás tedy připojil k něčemu, čemu se nedá říkat Internet. Zbývá vám tedy jediné - reklamovat, reklamovat, reklamovat, když to nepůjde tak odejít. Od takovéhoto NATování je jen krůček k tomu aby Vám příště dělali MitM na SSL komunikaci či podobná zvěrstva.
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Pepa 23. 06. 2011, 14:31:05: ad MTU)
To me taky uz napadlo. Z odposlechnute komunikace je videt, ze prichozi udp paket, ktery je u T-Mobile blokovan(?), je pres O2 dorucen a ma velikost 925 Bytu. Ale u T-Mobilu jsem nasel jiny doruceny prichozi paket o velikosti 985 Bytu (tj. vetsi).

MTU mam nastaven na 1500 a nemam pocit, ze bych mel jine problemy s komunikaci.

ad dumpy)
Jsem vdecny za Vas nazor a dekuji za cas, ktery jste tomu venoval.
Vychazi mi ten samy zaver, ale preci jen jsem pripoustel moznou chybu na me strane.
Pokusim se ted vyargumentovat u T-Mobile napravu. Uvidim.

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Ondřej Caletka 26. 06. 2011, 17:56:33: Teď jsem otestoval připojení přes T-Mobile EDGE a tam k výše popsanému prasení nedochází. O jaký jde přesně druh připojení? Je to 4G, nebo ADSL?
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Ondřej Caletka 27. 06. 2011, 18:45:23: Tak ještě jednou já: Teď jsem otestoval připojení přes UMTS-TDD alias Internet 4G a musím bohužel potvrdit to, co zde bylo napsáno.

T-Mobile u služby Internet 4G transparentně proxuje a zároveň podvrhuje systém DNS!

Klient může požádat jakoukoli adresu o překlad kořenové zóny, vždy dostane prázdnou odpověď pouze s GLUE záznamem
Kód: [Vybrat]
. 65535 IN A 62.141.6.172
Následuje pár needitovaných příkladů:
Kód: [Vybrat]
oskar@esprimo ~ $ dig +dnssec @1.2.3.4 aaaa ; <<>> DiG 9.7.3 <<>> +dnssec @1.2.3.4 aaaa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49355 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ADDITIONAL SECTION: . 65535 IN A 62.141.6.172 ;; Query time: 123 msec ;; SERVER: 1.2.3.4#53(1.2.3.4) ;; WHEN: Mon Jun 27 18:21:44 2011 ;; MSG SIZE rcvd: 44 oskar@esprimo ~ $ dig +dnssec @1.2.3.4 a ; <<>> DiG 9.7.3 <<>> +dnssec @1.2.3.4 a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29406 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ADDITIONAL SECTION: . 65535 IN A 62.141.6.172 ;; Query time: 100 msec ;; SERVER: 1.2.3.4#53(1.2.3.4) ;; WHEN: Mon Jun 27 18:21:46 2011 ;; MSG SIZE rcvd: 44 oskar@esprimo ~ $ dig . @2.2.8.3 txt ; <<>> DiG 9.7.3 <<>> . @2.2.8.3 txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48758 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN TXT ;; ANSWER SECTION: . 65535 IN A 62.141.6.172 ;; Query time: 94 msec ;; SERVER: 2.2.8.3#53(2.2.8.3) ;; WHEN: Mon Jun 27 18:40:25 2011 ;; MSG SIZE rcvd: 33 oskar@esprimo ~ $ host . . has address 62.141.6.172 . has address 62.141.6.172 . has address 62.141.6.172Bohužel, vzhledem k tomu, že jde o proxování transparentní, nedá se to vyřešit (kromě reklamace a doufání, že to spraví) jinak než šifrovaným tunelem.
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Mordae 28. 06. 2011, 08:00:29: Opravdu by me zajimalo jejich vyjadreni. Nezapomel jsi na nas, ze ne? :-)
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Pepa 28. 06. 2011, 11:54:13: To Ondrej Caletka: U me se pripojuji na 4G.

To Mordae: Nezapomnel jsem. Poslal jsem T-Mobilu podrobny popis problemu + dumpy komunikace (zaslano 22.6. - pred 6 dny). Zatim zadna konkretni odezva. Dnes odjizdim na dovolenou, po navratu 7.7. dam vedet, co je noveho.

Pepa
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Pepa 28. 06. 2011, 13:08:45: Jeste bych dodal laickou interpretaci dobre zvoleneho prikladu p. Caletky:

Je jedno na ktery DNS server je poslan vas dotaz, v siti T-Mobile je tento dotaz VZDY(?) zpracovan jejich pocitaci a odpoved vracena vam. Tj. sit T-Mobile neni co se tyce DNS dotazu transparentni a T-Mobile v prekladu domenovych jmen postavil velkou cinskou zed.

Dukaz - provedu srovnani opet s O2 (ADSL), ktera je pro mne v tuto chvili dostupna jako etanol spravne fungujici site:

dotaz smerovany na neexistujici DNS server (na adrese 1.2.3.4 neni DNS server):
- u O2 opravdu zjistite, ze toto neni DNS server (no servers could be reached)
Kód: [Vybrat]
root@root:~# dig @1.2.3.4 a ; <<>> DiG 9.7.0-P1 <<>> @1.2.3.4 a ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
- u T-Mobilu vam vrati jakousi (QUERY: 1, ANSWER: 1) odpoved...
Kód: [Vybrat]
root@alpha:~# dig @1.2.3.4 a ; <<>> DiG 9.7.3 <<>> @1.2.3.4 a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43339 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 65535 IN A 62.141.6.172 ;; Query time: 122 msec ;; SERVER: 1.2.3.4#53(1.2.3.4) ;; WHEN: Tue Jun 28 12:49:08 2011 ;; MSG SIZE rcvd: 33
To byl dotaz u nexestujiciho serveru - v siti T-Mobile se deji zazraky a vraci se odpoved.
Podme se ale podivat, jestli je tato odpoved spravna...
Tentokrat se zeptame u "Velkeho bratra", pana Googla:

- O2 - takto ma vypadat spravna odpoved
Kód: [Vybrat]
root@root:~# dig @8.8.8.8 a ; <<>> DiG 9.7.0-P1 <<>> @8.8.8.8 a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48215 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 1396 IN NS m.root-servers.net. . 1396 IN NS l.root-servers.net. . 1396 IN NS i.root-servers.net. . 1396 IN NS e.root-servers.net. . 1396 IN NS b.root-servers.net. . 1396 IN NS f.root-servers.net. . 1396 IN NS h.root-servers.net. . 1396 IN NS j.root-servers.net. . 1396 IN NS c.root-servers.net. . 1396 IN NS d.root-servers.net. . 1396 IN NS a.root-servers.net. . 1396 IN NS k.root-servers.net. . 1396 IN NS g.root-servers.net. ;; Query time: 25 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Jun 28 12:12:44 2011 ;; MSG SIZE rcvd: 228
- a co si vymysli T-Mobile... (opet podivny odkaz na jakysi T-Mobile server - 62.141.6.172)
Kód: [Vybrat]
root@alpha:~# dig @8.8.8.8 a ; <<>> DiG 9.7.3 <<>> @8.8.8.8 a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26124 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 65535 IN A 62.141.6.172 ;; Query time: 77 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Jun 28 12:22:55 2011 ;; MSG SIZE rcvd: 33
No, snad je to trochu nazorne.

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Jenda 28. 06. 2011, 14:39:09: Citace: Ondřej Caletka 26. 06. 2011, 17:56:33
Teď jsem otestoval připojení přes T-Mobile EDGE a tam k výše popsanému prasení nedochází. O jaký jde přesně druh připojení? Je to 4G, nebo ADSL?
Otestoval jsem GPRS (mám Twist) a tam k tomu také nedochází. Asi cenzurují jen UMTS, GPRS/EDGE je totiž tak pomalé, že přes to žádné dětské porno stahovat nejde :-D.
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Santiago 28. 06. 2011, 14:53:52: > Bohužel, vzhledem k tomu, že jde o proxování transparentní, nedá se to vyřešit (kromě reklamace a doufání, že to spraví) jinak než šifrovaným tunelem.

Jeste by to mozna slo resit zalobou - par. 182 Porušení tajemství dopravovaných zpráv bod (1b).
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Santiago 28. 06. 2011, 14:54:46: Tedy ne zalobou, ale trestnim oznamenim.
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Pepa 28. 06. 2011, 15:39:43: Citace
Otestoval jsem GPRS (mám Twist) a tam k tomu také nedochází. Asi cenzurují jen UMTS, GPRS/EDGE je totiž tak pomalé, že přes to žádné dětské porno stahovat nejde :-D.
Aby jste se nedivil, kouknete na http://blok.hrach.eu/ . Podle tamnejsiho seznamu T-Mobile dela(!) cenzuru. Ma ale oporu v legislative a pokud blokuje jednotliva url, nemam s tim problem.

Zde se ale bavime o tom, ze T-Mobile mrsi moji komunikaci s hlavnimi(!) DNS servery Internetu. S hlavnimi, paternimi, root-servery! Vstupuji do komunikace a posilaji podvrzene odpovedi.

Jen pripomenu, ze mi kvuli tomu pak nejede DNSSEC. Tim to cele zacalo... :-)

Pepa
Název: Re: nejede DNSSEC v siti T-Mobile
Přispěvatel: Jenda 28. 06. 2011, 15:47:22: Citace: Pepa 28. 06. 2011, 15:39:43
Citace
Otestoval jsem GPRS (mám Twist) a tam k tomu také nedochází. Asi cenzurují jen UMTS, GPRS/EDGE je totiž tak pomalé, že přes to žádné dětské porno stahovat nejde :-D.
Aby jste se nedivil, kouknete na http://blok.hrach.eu/ . Podle tamnejsiho seznamu T-Mobile dela(!) cenzuru.
Jakožto autor stránky blok.hrach.eu o tom samozřejmě vím ;-).
Citace: Pepa 28. 06. 2011, 15:39:43
Ma ale oporu v legislative
Se mi nějak nezdá…
Citace: Pepa 28. 06. 2011, 15:39:43
a pokud blokuje jednotliva url, nemam s tim problem.
Proti gustu…
Citace: Pepa 28. 06. 2011, 15:39:43
Zde se ale bavime o tom, ze T-Mobile mrsi moji komunikaci s hlavnimi(!) DNS servery Internetu. S hlavnimi, paternimi, root-servery! Vstupuji do komunikace a posilaji podvrzene odpovedi.
Zprasení internetových standardů je bohužel podmínkou alespoň trochu účinné cenzury.
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: John S 28. 06. 2011, 21:12:31: Jenže cenzua JE prasení internetu
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Jenda 07. 07. 2011, 14:33:33: Hele, co mi přišlo:

Dobré poledne,

nechali jsme prověřit kolegy vaše zjištění a rádi bychom uvedli na pravou míru, že se rozhodně nejedná o cenzurování internetu.

Problémy s fungováním DNS v síti UMTS TDD (Internet 4G), jak zde byly popsány, nejsou v žádném případě záměrem T-Mobile vnutit zákazníkovi transparentní DNS server či dokonce monitorovat nebo filtrovat DNS provoz. Jsou způsobené specifickou funkcionalitou INC síťového elementu, která využívá DNS protokol k detekci možného upgradu firmware 4G terminálů v korporátních APN. Bohužel tato funkcionalita není kompatibilní s DNSSEC, proto dochází ke zde popsaným problémům. V současnosti intenzivně zkoumáme, jak tomuto chování zamezit a zajistit, aby DNS v UMTS TDD síti fungovalo opět podle standardu.

Hezký den

Jiří Janeček
Senior specialista externí komunikace
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Pepa 07. 07. 2011, 17:19:48: To Jenda:
Gratuluji, mě vůbec neodpověděli. První dotaz na T-Mobile 22.6., dnes ráno (tj. po 14 dnech) urgence. Zatím bez odpovědi. Takový způsob komunikace se mi nelíbí.

Mimo diskusi Vám tímto vyjadřuji sympatie a podporu k webu http://blok.hrach.eu/ (palec nahoru :-).
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Jenda 07. 07. 2011, 19:00:08: Citace: Pepa 07. 07. 2011, 17:19:48
To Jenda:
Gratuluji, mě vůbec neodpověděli. První dotaz na T-Mobile 22.6., dnes ráno (tj. po 14 dnech) urgence. Zatím bez odpovědi. Takový způsob komunikace se mi nelíbí.
Mně napsali jako odpověď na zprávičku na AbcLinuxu, kterou jsem tam o tomhle vlákně napsal.
Citace: Pepa 07. 07. 2011, 17:19:48
Mimo diskusi Vám tímto vyjadřuji sympatie a podporu k webu http://blok.hrach.eu/ (palec nahoru :-).
Díky :-).
Název: Re: Nejede DNSSEC v síti T-Mobile
Přispěvatel: Pepa 15. 07. 2011, 17:57:40: OPRAVENO!

Zavolal mi dnes technik z T-Mobile a informoval mě, že už to je opraveno.
Zkusil jsem si tedy zapnout v konfiguraci DNSSEC a ejhle - už to jede.
Jen dodám, že mi pán z TM vysvětlil, proč to tak měli dříve nastaveno a jeho zdůvodnění se v podstatě shoduje s oficiální reakcí pana "Senior specialisty externí komunikace" o kousek výše.

Zdravím, přeji hezký den,
a hlavně děkuji všem zúčastněným za pomoc.