a 62.24.64.2 ma vracet version "Apache" a zadnej cluster tam urcite neni ... takze hadam, ze mu vazne nekdo leze do DNS trafficu ...
Printable View
Tak doufam, ze to nezerou ty zas.... sloane.cz
Ja taky nekde cestou lezu pres ne.
Konkretne:geo0-1-s144.c1.pop1.pra.sloane.cz
Jinak jsem nainstaloval bind 8.4.7 (posledni osmicku) a vse funguje spravne, vse se resolvuje. Bohuzel ale o nem pisou, ze ma dost bezpecnostnich der.
Ted mi dochazi, ze to zrat nemuzou, ponevadz to ke mne prijde.
Ta odpoved proste prijde fyzicky az k mymu serveru. Viz data z etherealu, co jsem posilal.
Podle mne ty servery odpovidaj v nejakem divnem formatu.
Z tech logu je videt, ze bind disabling EDNS0, ale ve skutecnosti se stale pta v EDNS0.
George
oni to nezerou, oni odpovidaji za ty nameservery ...
192.5.5.241 ti proste nema odpovedet nic jinyho, nez TLD servery ... a ono to vraci rovnou resolvnute A a CNAME. Zaroven to vraci spatne odpovedi z 62.24.64.2, kde jsem si 100%ne jist, ze neni zadna zakernost ....
Pravdepodobne niekto niekde presmeruva vsetok traffic na porte 53. Treba to riesit s providerom.
vyzkousej schvalne
treba se prozradi ten zloduch ...Citace:
traceroute -p 53 192.5.5.241
traceroute -p 53 62.24.64.2
jinak v8 je taky reseni a na v9 by jednak melo jit globalne vypnout edns (je na to k dispozici patch) a druhak vypnout formerr (pokusi se z odpovedi vypacit co nejvic dat, i kdyz je ve spatnym formatu) ... muzes zkusit jeste toto ...
tak co si o tom myslite...
[root@server ~]# traceroute -p 53 192.5.5.241
traceroute to 192.5.5.241 (192.5.5.241), 30 hops max, 40 byte packets
1 f.root-servers.net (192.5.5.241) 5.243 ms 88.146.251.206 (88.146.251.206)
6.464 ms 10.572 ms
2 10.11.0.97 (10.11.0.97) 12.316 ms 12.873 ms 17.618 ms
3 10.11.0.13 (10.11.0.13) 17.598 ms 19.452 ms 20.429 ms
4 10.11.0.94 (10.11.0.94) 20.409 ms 22.386 ms 22.366 ms
5 ge0-1-s144.c1.pop1.pra.sloane.cz (88.146.176.33) 24.281 ms 24.264 ms 26.5
43 ms
6 v102.tr2.pop1.pra.sloane.cz (62.240.161.197) 26.523 ms 9.341 ms 15.677 ms
7 f-root1-nix.nic.cz (194.50.100.181) 17.707 ms 17.932 ms 20.431 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
[root@server ~]# traceroute 192.5.5.241
traceroute to 192.5.5.241 (192.5.5.241), 30 hops max, 40 byte packets
1 88.146.251.206 (88.146.251.206) 5.129 ms 8.318 ms 8.318 ms
2 10.11.0.97 (10.11.0.97) 12.666 ms 14.656 ms 16.442 ms
3 10.11.0.13 (10.11.0.13) 18.213 ms 21.584 ms 21.729 ms
4 10.11.0.94 (10.11.0.94) 23.163 ms 23.119 ms 25.029 ms
5 ge0-1-s144.c1.pop1.pra.sloane.cz (88.146.176.33) 25.007 ms 26.194 ms 28.030 ms
6 v102.tr2.pop1.pra.sloane.cz (62.240.161.197) 26.126 ms 23.174 ms 20.695 ms
7 f-root1-nix.nic.cz (194.50.100.181) 22.532 ms 5.858 ms 14.436 ms
8 f.root-servers.net (192.5.5.241) 16.818 ms 16.803 ms 18.518 ms
George
traceroute to 62.24.64.2 (62.24.64.2), 30 hops max, 40 byte packets
1 ns1.dkm.cz (62.24.64.2) 9.349 ms 88.146.251.206 (88.146.251.206) 9.325 ms 11.579 ms
2 10.11.0.97 (10.11.0.97) 12.819 ms 17.459 ms 17.439 ms
3 10.11.0.13 (10.11.0.13) 19.160 ms 19.143 ms 20.853 ms
4 10.11.0.94 (10.11.0.94) 20.869 ms 22.271 ms 22.250 ms
5 ge0-1-s144.c1.pop1.pra.sloane.cz (88.146.176.33) 24.021 ms 24.005 ms 27.386 ms
6 v102.tr2.pop1.pra.sloane.cz (62.240.161.197) 28.782 ms 11.505 ms 11.754 ms
7 nix2.dkm.cz (194.50.100.36) 13.626 ms 13.690 ms 16.422 ms
8 cz-prg01a-ra1-ge-0-0-0-v50.aorta.net (213.46.172.18) 16.405 ms 20.985 ms 20.966 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * *
[root@server ~]# traceroute 62.24.64.2
traceroute to 62.24.64.2 (62.24.64.2), 30 hops max, 40 byte packets
1 88.146.251.206 (88.146.251.206) 5.221 ms 5.194 ms 6.935 ms
2 10.11.0.97 (10.11.0.97) 15.744 ms 15.800 ms 21.700 ms
3 10.11.0.13 (10.11.0.13) 22.657 ms 24.094 ms 24.075 ms
4 10.11.0.94 (10.11.0.94) 26.070 ms 26.048 ms 28.005 ms
5 ge0-1-s144.c1.pop1.pra.sloane.cz (88.146.176.33) 28.081 ms 29.484 ms 29.464 ms
6 v102.tr2.pop1.pra.sloane.cz (62.240.161.197) 31.363 ms 25.742 ms 26.354 ms
7 nix2.dkm.cz (194.50.100.36) 27.506 ms 6.146 ms 14.565 ms
8 cz-prg01a-ra1-ge-0-0-0-v50.aorta.net (213.46.172.18) 14.546 ms 16.756 ms 18.449 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 *
[root@server ~]#
hm. ty tracerouty vypadaj ok. takhle na to asi neprijdem :(
edit: jeste muzem zkusit
Kód:dig +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT
[root@server log]# dig +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT
; <<>> DiG 9.4.2 <<>> +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 7414
;; flags: qr ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; Query time: 8 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Fri Mar 7 19:05:45 2008
;; MSG SIZE rcvd: 12
Ted trochu ztracim souvislosti, o co ti jde.
Nicmene mezi tim zkousim dale, a prisel jsem na to, ze ani ten bind v8 neni tak OK. neumi prelozit treba "www.microchip.com"
v ethereal vidim, ze se udp na 53 dotaze 198.175.253.201 na zminenou domenu, prijde odpoved a hned potom se TCP na p53 snazi spojit se stejnym serverem, ale ten nepotvrdi ani SYN, takze ke spojeni nedojde. To uz mi hlava nebere. Nicmene, toto je asi zase jiny problem.
Vratim asi zpatky bind v9 a zkusim, co jsi radil, ale nevim jak.
Prosim tedy trosku podrobneji, jak vypnout FORMERR, jestli to vis z hlavy, jinak taky budu hledat.
Patch snad zvladnu, i kdyz mi fedora8 defaultne cpe verzi bindu 9.5.xxx, tak tam radsi nainstaluju oficialni posledni stabilni 9.4.xxx
Mimochodem, ty traceroutery mi nepripadaj moc v pohode, kdyz
traceroute -p 53 192.5.5.241
skonci na serveru xxxxx.nic.cz
nic.cz je snad spravce TLD .cz a ne router
Diky
George
traceroute mam stejny jako georgejares (tedy ten konec samozrejme)
http://wilmer.gaast.net/downloads/bi...ns-global.diff (imho to pujde pouzit i na novejsi verze .... potreba zkusit)
ten formerr ted nemuzu najit ... vyhrabal jsem to nekde ve zdrojacich ...
skoda, ze me to tady nedela ... bych se na to docela rad sam podival :)
Edit: to ze traceroute konci v nic.cz je naprosto ok ... http://www.isc.org/ops/f-root/prg1.php
ale i ty prazsky servery odpovidaji na hostname.bind... (tim by mel server prozradit, jak se ve skutecnosti jmenuje) - podle me je neco zacarovane nekde u vas v siti ...
kterej hop mate prvni spolecnej ? ty sloany ?
Kód:; <<>> DiG 9.4.2 <<>> +norec @F.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 7414
;; flags: qr ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; Query time: 8 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Fri Mar 7 19:05:45 2008
;; MSG SIZE rcvd: 12
Zdravim,
tak jsem dnes udelal pokus:
Prvni samozrejme neodpovedel, druhy ano.Kód:dig @MUJSERVER www.bckolin.cz
dig @DNSSERVERMYHOPROVIDERA www.bckolin.cz
Co je ale zajimave, ze pomoci etherealu jsem zjistil, ze obe odpovedi jsou naprosto stejne. Jediny rozdil je v tom, ze v prvnim pripade odpovida root.server programu "bind" a ve druhem pripade odpovida DNSSERVERMYHOPROVIDERA programu "dig".
Souvislost mezi odpovedmi, ktere bind pobere a nepobere je asi takova, ze odpovedi delsi nez 512 octets (jestli to chapu dobre, tak 256 bytu) hlasi jako formerr. To znamena, jako by bind mel nejakej interni filtr na udppakety delsi nez 521 oktetu. Nevim ale kde. Firewall to nemuze byt, protoze potom by to neprolezlo ani pro "dig". Nenapada mne, co dalsiho bych k tomu dodal. Podle mne je to problem v bindu.
Ta hranice pro odpoved by mela byt 512byte a pokud je odpoved nad tuhle hranici, tak se posila truncated reply - pokud klient pozaduje uplnou informaci, musi pozadat pres tcp. Je hodne zvlastni, ze ti chodi odpovedi od root serveru, protoze ty pokud vim rekurzivni dotazy vubec neumoznuji :)
A proc tedy vsude pisou 512 oktets.
V etherealu jsem videl i UDP pakety delsi nez 512 bytu.
Jeste o ktere delce se mluvi, o delce celeho IP paketu, celeho UDP paketu nebo celeho DNS paketu...
Ty odpovedi od rootserveru chodi, nektere muj bind pobere, jine ne.
Ted mi zacala fungovat jedna domena, ale jine zas ne.
Souvislost s delkou paketu rusim. Nicmene, ted se muj bind nedotazuje root server, ale b.ns.nic.cz. Od nej prichazeji odpovedi, ktere muj bind pobira i nepobira. V etherealu to vypada vse vpohode, odpovedi jsou korektni a uplne a bez chyb.
Jinak by mne jeste zajimalo, jak ten bind vubec funguje.
Konfigurak mam ted z oficialnich stranek pro :
a v named.localhost mam:Kód:// Two corporate subnets we wish to allow queries from.
acl corpnets { 192.168.1.1/24; 127.0.0.1; };
options {
directory "/var/named"; // Working directory
allow-query { corpnets; };
// query-source port 53;
edns-udp-size 1024;
max-udp-size 1024;
// check-names ignore;
check-mx ignore;
check-wildcard no;
check-integrity no;
check-mx-cname ignore ;
check-srv-cname ignore;
check-sibling no;
};
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
file "named.localhost";
notify no;
};
Odkud si tedy bere jmena root serveru nebo serveru, kterych se ma dotazovat?Kód:$TTL 1D
@ IN SOA @ rname.invalid. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS @
A 127.0.0.1
AAAA ::1
Dle navodu na offico strankach je tahle configurace pro jednoduchy caching name server.
Ovsem ta konfigurace na toto prapodivne chovani nema zadny vyznam. Bud mam od zacatku neco blbe, nebo nevim.
Jeste bych dodal ze konfigurace serveru je:
dve sitove karty, jedna s verejnou IP a druha s vnitrni siti.
Zkusim jeste starej server a koukat se co prolejza pres router, na kterym je i bind.
Dalsi souvislosti, ktere se mi jevi jako rozdilne u odpovidajicich a neodpovidajicich server jsou ty, ze:
1) odpovidajici servery maji mensi pocet Authority RSS a Aditional RSS zaznamu
2) odpovidajici servery maji mensi TTL
Udelam takovy maly souhrn:
Jeste doplnim, ze jsem udelal pokus, kdy jsem spustil DNS na vnitrnim serveru s jednou sitovkou, ktery chodil pres branu ven (na ktere je taky DNS, ktera se chova stejne blbe jako ta vnitrni). Problemova data, ktera jsem odchytal jsou stejna na drate, ktery je mezi servrem na vnitrni siti a branou, i na drate, ktery je mezi braznou a internetem.
Abych to naznacil:
SERVER S1 , jedna sitovka 192.168.1.3 je ve vnitrni siti a bezi na nem bind
SERVER S2, dve sitovky, 192.168.1.1 pro vnitrni sit a 88.146.251.201 (verejna IP) pro internet. Slouzi jako router (a mel by slouzit i jako caching DNS server pro vnitrni sit)
Takze:
Odchytana data jsou mezi 192.168.1.3 a 192.168.1.1
Celkova komunikace:
a ted odpoved, kterou bind nepobral (zdekodovane etherealem):Kód:No. Time Source SourceMAC Destination DestMAC Protocol Info
6256 1204.086905 192.168.1.3 00:b0:d0:31:33:7e 192.5.5.241 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6257 1204.087648 192.168.1.3 00:b0:d0:31:33:7e 192.5.5.241 00:15:58:a7:2c:90 DNS Standard query NS <Root>
6259 1204.252609 192.5.5.241 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6260 1204.254732 192.168.1.3 00:b0:d0:31:33:7e 128.8.10.90 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6261 1204.336741 192.5.5.241 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response NS i.root-servers.net NS k.root-servers.net NS d.root-servers.net NS f.root-servers.net NS g.root-servers.net NS h.root-servers.net NS m.root-servers.net NS l.root-servers.net NS b.root-servers.net NS e.root-servers.net NS a.root-servers.net NS j.root-servers.net NS c.root-servers.net
6263 1204.429027 128.8.10.90 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6264 1204.430830 192.168.1.3 00:b0:d0:31:33:7e 202.12.27.33 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6268 1204.638181 202.12.27.33 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6269 1204.640034 192.168.1.3 00:b0:d0:31:33:7e 192.33.4.12 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6273 1204.831800 192.33.4.12 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6274 1204.833604 192.168.1.3 00:b0:d0:31:33:7e 192.112.36.4 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6278 1205.064535 192.112.36.4 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6279 1205.066373 192.168.1.3 00:b0:d0:31:33:7e 192.36.148.17 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6280 1205.239516 192.36.148.17 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6281 1205.241426 192.168.1.3 00:b0:d0:31:33:7e 193.0.14.129 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6282 1205.398754 193.0.14.129 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6283 1205.400567 192.168.1.3 00:b0:d0:31:33:7e 192.203.230.10 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6284 1205.549708 192.203.230.10 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6285 1205.551399 192.168.1.3 00:b0:d0:31:33:7e 128.63.2.53 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6286 1205.744772 128.63.2.53 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6287 1205.746677 192.168.1.3 00:b0:d0:31:33:7e 199.7.83.42 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6288 1205.901128 199.7.83.42 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6289 1205.902991 192.168.1.3 00:b0:d0:31:33:7e 192.228.79.201 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6290 1206.038780 192.228.79.201 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6291 1206.040635 192.168.1.3 00:b0:d0:31:33:7e 198.41.0.4 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6292 1206.205111 198.41.0.4 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6293 1206.206941 192.168.1.3 00:b0:d0:31:33:7e 192.58.128.30 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6294 1206.354802 192.58.128.30 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6295 1206.361098 192.168.1.3 00:b0:d0:31:33:7e 192.228.79.201 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6296 1206.473671 192.228.79.201 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6297 1206.475364 192.168.1.3 00:b0:d0:31:33:7e 192.58.128.30 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6298 1206.631173 192.58.128.30 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6299 1206.632937 192.168.1.3 00:b0:d0:31:33:7e 192.203.230.10 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6300 1206.755267 192.203.230.10 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6301 1206.756876 192.168.1.3 00:b0:d0:31:33:7e 199.7.83.42 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6302 1206.909498 199.7.83.42 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6303 1206.911259 192.168.1.3 00:b0:d0:31:33:7e 193.0.14.129 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6304 1207.092086 193.0.14.129 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6305 1207.093853 192.168.1.3 00:b0:d0:31:33:7e 198.41.0.4 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6306 1207.267025 198.41.0.4 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6307 1207.268740 192.168.1.3 00:b0:d0:31:33:7e 128.8.10.90 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6308 1207.441030 128.8.10.90 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6309 1207.442801 192.168.1.3 00:b0:d0:31:33:7e 192.36.148.17 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6310 1207.626405 192.36.148.17 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6311 1207.628158 192.168.1.3 00:b0:d0:31:33:7e 192.33.4.12 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6312 1207.783978 192.33.4.12 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6313 1207.785758 192.168.1.3 00:b0:d0:31:33:7e 128.63.2.53 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6314 1207.929877 128.63.2.53 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6315 1207.931629 192.168.1.3 00:b0:d0:31:33:7e 202.12.27.33 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6316 1208.096459 202.12.27.33 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6317 1208.098107 192.168.1.3 00:b0:d0:31:33:7e 192.112.36.4 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6318 1208.271924 192.112.36.4 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
6319 1208.273662 192.168.1.3 00:b0:d0:31:33:7e 192.5.5.241 00:15:58:a7:2c:90 DNS Standard query A www.bckolin.cz
6320 1208.395349 192.5.5.241 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
8175 1677.803934 192.168.1.3 00:b0:d0:31:33:7e 192.228.79.201 00:15:58:a7:2c:90 DNS Standard query A www.idnes.cz
8179 1678.311981 192.228.79.201 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c1.idnes.cz A 194.79.52.192
8180 1678.314656 192.168.1.3 00:b0:d0:31:33:7e 192.203.230.10 00:15:58:a7:2c:90 DNS Standard query A c1.idnes.cz
8181 1678.459115 192.203.230.10 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response A 194.79.52.192
8529 1687.909254 192.168.1.3 00:b0:d0:31:33:7e 192.168.1.1 00:15:58:a7:2c:90 DNS Standard query A www.idnes.cz
8531 1688.229250 192.168.1.1 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c1.idnes.cz A 194.79.52.192
a odpoved, kterou bind pobralKód:No. Time Source SourceMAC Destination DestMAC Protocol Info
6259 1204.252609 192.5.5.241 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c150un.forpsi.com A 81.2.194.150
Frame 6259 (320 bytes on wire, 320 bytes captured)
Arrival Time: Mar 9, 2008 18:19:11.542858000
Time delta from previous packet: 0.164961000 seconds
Time since reference or first frame: 1204.252609000 seconds
Frame Number: 6259
Packet Length: 320 bytes
Capture Length: 320 bytes
Protocols in frame: eth:ip:udp:dns
Ethernet II, Src: 192.168.1.1 (00:15:58:a7:2c:90), Dst: 192.168.1.3 (00:b0:d0:31:33:7e)
Destination: 192.168.1.3 (00:b0:d0:31:33:7e)
Source: 192.168.1.1 (00:15:58:a7:2c:90)
Type: IP (0x0800)
Internet Protocol, Src: 192.5.5.241 (192.5.5.241), Dst: 192.168.1.3 (192.168.1.3)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 306
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 60
Protocol: UDP (0x11)
Header checksum: 0xb619 [correct]
Source: 192.5.5.241 (192.5.5.241)
Destination: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: domain (53), Dst Port: domain (53)
Source port: domain (53)
Destination port: domain (53)
Length: 286
Checksum: 0x57da [correct]
Domain Name System (response)
Transaction ID: 0x5f6d
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 6
Additional RRs: 6
Queries
www.bckolin.cz: type A, class IN
Name: www.bckolin.cz
Type: A (Host address)
Class: IN (0x0001)
Answers
www.bckolin.cz: type CNAME, class IN, cname c150un.forpsi.com
Name: www.bckolin.cz
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 3 days, 23 hours, 4 minutes, 57 seconds
Data length: 19
Primary name: c150un.forpsi.com
c150un.forpsi.com: type A, class IN, addr 81.2.194.150
Name: c150un.forpsi.com
Type: A (Host address)
Class: IN (0x0001)
Time to live: 8 minutes, 47 seconds
Data length: 4
Addr: 81.2.194.150
Authoritative nameservers
cz: type NS, class IN, ns b.ns.nic.cz
Name: cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day, 20 hours, 4 minutes
Data length: 11
Name server: b.ns.nic.cz
cz: type NS, class IN, ns f.ns.nic.cz
Name: cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day, 20 hours, 4 minutes
Data length: 4
Name server: f.ns.nic.cz
cz: type NS, class IN, ns a.ns.nic.cz
Name: cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day, 20 hours, 4 minutes
Data length: 4
Name server: a.ns.nic.cz
cz: type NS, class IN, ns d.ns.nic.cz
Name: cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day, 20 hours, 4 minutes
Data length: 4
Name server: d.ns.nic.cz
cz: type NS, class IN, ns c.ns.nic.cz
Name: cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day, 20 hours, 4 minutes
Data length: 4
Name server: c.ns.nic.cz
cz: type NS, class IN, ns e.ns.nic.cz
Name: cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day, 20 hours, 4 minutes
Data length: 4
Name server: e.ns.nic.cz
Additional records
b.ns.nic.cz: type A, class IN, addr 217.31.205.188
Name: b.ns.nic.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 5 minutes, 19 seconds
Data length: 4
Addr: 217.31.205.188
f.ns.nic.cz: type A, class IN, addr 193.171.255.48
Name: f.ns.nic.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 15 minutes, 6 seconds
Data length: 4
Addr: 193.171.255.48
a.ns.nic.cz: type A, class IN, addr 217.31.205.180
Name: a.ns.nic.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 24 minutes, 58 seconds
Data length: 4
Addr: 217.31.205.180
d.ns.nic.cz: type A, class IN, addr 193.29.206.1
Name: d.ns.nic.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 28 minutes, 31 seconds
Data length: 4
Addr: 193.29.206.1
c.ns.nic.cz: type A, class IN, addr 195.66.241.202
Name: c.ns.nic.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 27 minutes, 49 seconds
Data length: 4
Addr: 195.66.241.202
e.ns.nic.cz: type A, class IN, addr 194.146.105.38
Name: e.ns.nic.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 18 minutes, 59 seconds
Data length: 4
Addr: 194.146.105.38
Jak jsem psal, rozdily jsou v pocetu Authority RSS a Aditional RSS zaznamuKód:No. Time Source SourceMAC Destination DestMAC Protocol Info
8179 1678.311981 192.228.79.201 00:15:58:a7:2c:90 192.168.1.3 00:b0:d0:31:33:7e DNS Standard query response CNAME c1.idnes.cz A 194.79.52.192
Frame 8179 (178 bytes on wire, 178 bytes captured)
Arrival Time: Mar 9, 2008 18:27:05.602230000
Time delta from previous packet: 0.508047000 seconds
Time since reference or first frame: 1678.311981000 seconds
Frame Number: 8179
Packet Length: 178 bytes
Capture Length: 178 bytes
Protocols in frame: eth:ip:udp:dns
Ethernet II, Src: 192.168.1.1 (00:15:58:a7:2c:90), Dst: 192.168.1.3 (00:b0:d0:31:33:7e)
Destination: 192.168.1.3 (00:b0:d0:31:33:7e)
Source: 192.168.1.1 (00:15:58:a7:2c:90)
Type: IP (0x0800)
Internet Protocol, Src: 192.228.79.201 (192.228.79.201), Dst: 192.168.1.3 (192.168.1.3)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 164
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 60
Protocol: UDP (0x11)
Header checksum: 0x6bf0 [correct]
Source: 192.228.79.201 (192.228.79.201)
Destination: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: domain (53), Dst Port: domain (53)
Source port: domain (53)
Destination port: domain (53)
Length: 144
Checksum: 0x6e0c [correct]
Domain Name System (response)
Transaction ID: 0x7fa3
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 2
Additional RRs: 2
Queries
www.idnes.cz: type A, class IN
Name: www.idnes.cz
Type: A (Host address)
Class: IN (0x0001)
Answers
www.idnes.cz: type CNAME, class IN, cname c1.idnes.cz
Name: www.idnes.cz
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 15 minutes, 55 seconds
Data length: 5
Primary name: c1.idnes.cz
c1.idnes.cz: type A, class IN, addr 194.79.52.192
Name: c1.idnes.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 15 minutes, 55 seconds
Data length: 4
Addr: 194.79.52.192
Authoritative nameservers
idnes.cz: type NS, class IN, ns ns.mafra.cz
Name: idnes.cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 22 minutes, 37 seconds
Data length: 11
Name server: ns.mafra.cz
idnes.cz: type NS, class IN, ns ns2.mafra.cz
Name: idnes.cz
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 22 minutes, 37 seconds
Data length: 6
Name server: ns2.mafra.cz
Additional records
ns.mafra.cz: type A, class IN, addr 194.79.53.77
Name: ns.mafra.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 30 minutes, 53 seconds
Data length: 4
Addr: 194.79.53.77
ns2.mafra.cz: type A, class IN, addr 194.79.55.77
Name: ns2.mafra.cz
Type: A (Host address)
Class: IN (0x0001)
Time to live: 40 minutes, 22 seconds
Data length: 4
Addr: 194.79.55.77
a v TTL u jednotlivych odpovedi (jedna se o TTL DNS protokolu, ne o TTL IP protokolu)
Podle mne tedy zadny firewall ani jadro samotny paket nezere.
Na 192.168.1.1 je bind v9.5.x a fedora5 (aktualizovana)
Na 192.168.1.3 je bind v9.4.x a fedora8 (posledni aktualizace)
Po rucni kompilaci bind v9.4.x stazene z isc.org se server choval stejne.
Jsem z toho magor. Musi to byt nekde v bindu. Ale dost dlouho.
Nechapu, ze takovyhle problem mam jenom ja. A NeMeM9aA.
Jestli chces, tak ti poslu root heslo a muzes se mi na to podivat (byl bych moc rad, hlavne kdyby se to vyresilo)
takze ...
trochu jsem si hral a zjisteni je takove, ze misto toho, aby dotaz na domenu prisel primo, prijde ze serveru
77.48.100.254 - tj. rns2.sloane.cz ...
jeste zkusim mrknout na to, proc to vadi bindu, ale hadam ze to bude nejakej konflikt v obsahu ...
Edit3: Abych predesel zmateni to co vypada jako vystup z digu je jen vnitrni dump paketu z bindu - ne vystup z digu
Edit1: takze odhaleno i v cem je problem ... trosku jsem si pohral s kodem bindu a pridal si par debugu ...
Kód:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62120
;; flags: qr rd ra ; QUESTION: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;cb.icq.com. IN A
;; ANSWER SECTION:
cb.icq.com. 319 IN CNAME cb-mv01.blue.aol.com.
cb-mv01.blue.aol.com. 1254 IN A 64.12.164.55
;; AUTHORITY SECTION:
icq.com. 168194 IN NS dns-01.icq.net.
icq.com. 168194 IN NS dns-02.icq.net.
;; ADDITIONAL SECTION:
dns-01.icq.net. 84960 IN A 64.12.51.134
dns-02.icq.net. 84305 IN A 205.188.157.234
(v hranate zavorce je obsah te promenne)Kód:((type[2] == dns_rdatatype_ns[2] ||type[2] == dns_rdatatype_soa[6]) &&!dns_name_issubdomain(qname[cb-mv01blueaolcom], name[icqcom])[0])
muj tip na interpretaci je, ze cb-mv01.blue.aol.com je v domene aol.com pro kterou nemame autoritu v tehle odpovedi...
Edit2: to potvrzuje i druha nefcni domena:
Kód:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38401
;; flags: qr rd ra ; QUESTION: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 6
;; QUESTION SECTION:
;www.bckolin.cz. IN A
;; ANSWER SECTION:
www.bckolin.cz. 327373 IN CNAME c150un.forpsi.com.
c150un.forpsi.com. 1791 IN A 81.2.194.150
;; AUTHORITY SECTION:
cz. 164959 IN NS b.ns.nic.cz.
cz. 164959 IN NS f.ns.nic.cz.
cz. 164959 IN NS a.ns.nic.cz.
cz. 164959 IN NS d.ns.nic.cz.
cz. 164959 IN NS c.ns.nic.cz.
cz. 164959 IN NS e.ns.nic.cz.
;; ADDITIONAL SECTION:
b.ns.nic.cz. 1281 IN A 217.31.205.188
f.ns.nic.cz. 392 IN A 193.171.255.48
a.ns.nic.cz. 1489 IN A 217.31.205.180
d.ns.nic.cz. 1193 IN A 193.29.206.1
c.ns.nic.cz. 1170 IN A 195.66.241.202
e.ns.nic.cz. 624 IN A 194.146.105.38
Kód:((type[2] == dns_rdatatype_ns[2] ||type[2] == dns_rdatatype_soa[6]) &&!dns_name_issubdomain(qname[c150unforpsicom], name[cz])[0])
Edit4: Vsechno napovida tomu, ze sloane (nebo nekdo jiny po ceste) presmerovava traffic na 53/UDP na rns2.sloane.cz.
mam pro to nekolik 'dukazu'
a) ping na 192.5.5.241 vykazuje ttl=58
dns odpovedi z 192.5.5.241 vykazuji ttl=60
samozrejme, ze to klidne takhle muze byt na jednom stroji, ale je to silne nepravdepodobne, protoze by to moc nedavalo smysl
b) zkousel resolvovat svoji domenu (nejakablbost.murder.cz), kterou ale nikdo predtim urcite nezkousel a zkouset nebude, pac neni pouzita tak se na nejakablbost.murder.cz zeptalo rns2.sloane.cz
Takze jsem toho binda pripojil pod jinyho ISP a fungoval spravne.
Problem tedy bude u sloane.cz, jak jiz psal FOX, kteremu jeste jednou dekuji za analyzu.
Poslal jsme reklamaci s odkazem na tuto diskuzi jak svemu primemu ISP tak primo sloane.cz, tak uvidime, jak se k tomu postavi. Doufam, ze se alespon ozvou. Zatim to resim jinym NS.
Dej sem pak vedet, jak to dopadlo, docela by me to zajimalo :)
Odpoledne mi muj ISP tynecy.net poslal mailem, ze je to presmerovani zruseny.
Ovsem stale to blbne jako predtim.
Myslim, ze FOXova analyza je spravna a ted jen musim svyho ISP dokopat k tomu, aby to predelal.
Urcite napisu, jak to dopadlo.