Nejede DNSSEC v síti T-Mobile

Pepa · « **kdy:** 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

Reklama

Ondřej Surý · « **Odpověď #1 kdy:** 22. 06. 2011, 10:54:43 »

Přes T-Mobile znamená, že používáte jejich forwardery nebo ne?

Pepa · « **Odpověď #2 kdy:** 22. 06. 2011, 11:19:55 »

Nepouzivam zadny forwarder. Delam si "resolving" kompletne sam.

Pepa

Ondřej Caletka · « **Odpověď #3 kdy:** 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.

Pepa · « **Odpověď #4 kdy:** 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

Reklama

Mordae · « **Odpověď #5 kdy:** 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?

Pepa · « **Odpověď #6 kdy:** 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

alfi · « **Odpověď #7 kdy:** 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..

Pepa · « **Odpověď #8 kdy:** 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

alfi · « **Odpověď #9 kdy:** 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?

Pepa · « **Odpověď #10 kdy:** 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

Ondřej Caletka · « **Odpověď #11 kdy:** 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, ten by takový problém mohl pomoci odhalit.

Ondřej Caletka · « **Odpověď #12 kdy:** 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: 34525

Vš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 ac

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

Pepa · « **Odpověď #13 kdy:** 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

Ondřej Caletka · « **Odpověď #14 kdy:** 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?

Nejede DNSSEC v síti T-Mobile

Pepa

Nejede DNSSEC v síti T-Mobile

Reklama

Ondřej Surý

Re: nejede DNSSEC v siti T-Mobile

Pepa

Re: nejede DNSSEC v siti T-Mobile

Ondřej Caletka

Re: nejede DNSSEC v siti T-Mobile

Pepa

Re: nejede DNSSEC v siti T-Mobile

Reklama

Mordae

Re: nejede DNSSEC v siti T-Mobile

Pepa

Re: nejede DNSSEC v siti T-Mobile

alfi

Re: nejede DNSSEC v siti T-Mobile

Pepa

Re: nejede DNSSEC v siti T-Mobile

alfi

Re: nejede DNSSEC v siti T-Mobile

Pepa

Re: nejede DNSSEC v siti T-Mobile

Ondřej Caletka

Re: nejede DNSSEC v siti T-Mobile

Ondřej Caletka

Re: nejede DNSSEC v siti T-Mobile

Pepa

Re: nejede DNSSEC v siti T-Mobile

Ondřej Caletka

Re: nejede DNSSEC v siti T-Mobile