xDSL.at

Hi, habe hier ein sehr "spannendes" Problem. Ich habe Inode/UPC Takeit Max und verwende als dns OpenDNS.
Seit gestern ca. erreich ich (nur über diese Leitung) eztv.it nicht mehr. Ich konnte es soweit einschränken, dass
scheinbar OpenDNS in Verbindung mit meinem Provider die IP nicht richtig auflöst.

Code: Alles auswählen

nslookup eztv.it 208.67.222.222                                                                                                 19:22:15
Server:      208.67.222.222
Address:   208.67.222.222#53

Non-authoritative answer:
Name:   eztv.it
Address: 185.19.104.81


Resultat, .. Seite nicht erreichbar.
Während der selbe Befehl mit meinem Laptop via Tethering mit meinem Nexus 4 ins Internet folgendes ergibt:

Code: Alles auswählen

nslookup eztv.it 208.67.222.222                                                                                                 19:22:15
Server:      208.67.222.222
Address:   208.67.222.222#53

Non-authoritative answer:
Name:   eztv.it
Address: 185.19.104.(hier is die octet group 80 statt 81)80


Siehe, die letzte Octet Group. (80 vs. 81).
Hat jemand eine plausible Erklärung dafür? Btw, der google dns und der "original" UPC dns (195.34.133.21), liefert ebenfalls mit 185.19.104.80 die richtige Adresse zurück. Ist für mich irgendwie magicwonderland.
EDIT: code tags fressen keine color tags .

duerfte bei einzelnen opendns nameserver noch falsch (veraltet) im cache sein http://www.opendns.com/support/cache/
nach einer aenderung kommt sowas vor.

ich kann mich erinnern, dass ein webportal, bei dem ich vor jahren mitgearbeitet habe, nach einem ungeplanten providerwechsel von manchen deutschen usern drei wochen lang nicht erreicht werden konnte, weil deren nameserver immer noch die alten ip adressen lieferten.

>"...Hat jemand eine plausible Erklärung dafür?..."
jo. einfach opendns, einfach a****. und das hat nix mim caching zu tun.
hier z.b. im abschnitt "Public DNS Servers" eine kleine zusammenfassung, was der dreck von opendns, google, level3... so treibt:
https://trac.torproject.org/projects/to ... sResolvers

lg
zid

*lol* ich merk grad, meine Firma zensiert mich, komm auf den Link ned hin

du suist hackln und net linki schaun...

lg
zid

OpenDNS : IPv6 DNS.
208.67.222.222 | resolver1.opendns.com <- Blocks/Filters only malicious sites.
208.67.220.220 | resolver2.opendns.com <- Blocks/Filters only malicious sites.

Und was ist daran jetzt schlecht. Sofern die Info noch aktuell ist, ist das doch ok, dass OpenDNS malicious sites vorfiltert.
Solang sie sonst nichts "zensieren" ist doch soweit alles ok.

jutta hat geschrieben:duerfte bei einzelnen opendns nameserver noch falsch (veraltet) im cache sein http://www.opendns.com/support/cache/
nach einer aenderung kommt sowas vor.

ich kann mich erinnern, dass ein webportal, bei dem ich vor jahren mitgearbeitet habe, nach einem ungeplanten providerwechsel von manchen deutschen usern drei wochen lang nicht erreicht werden konnte, weil deren nameserver immer noch die alten ip adressen lieferten.

Müsste mir jetzt nochmal die Route anschaun, aber das klingt schon sehr merkwürdig, dass bei meiner UPC Leitung ständig ein anderer Cache von OpenDNS (der nicht aktuell ist) angesteuert wird, als über Drei (wo der richtige Cache angesteuert wird). Naja, egal. Wenn sichs nicht ändert, fliegt halt OpenDNS bei meinem bind daemon raus.
Update: @Jutta, ok dürfte wohl irgendwie ein Cache Problem sein. Ganz blick ich das jetzt nicht durch aber lt. dem OpenDNS Cache Check
http://www.opendns.com/support/cache/?domain=eztv.it&check=Check+this+domain&code=TXCSG kommt auch bei London dasselbe raus wie bei mir auf der UPC Leitung, seltsam aber naja egal.

>"...Solang sie sonst nichts "zensieren" ist doch soweit alles ok..."
frage is halt immer, welche sites ein betreiber von offenen dns-servern als "malicious" einstuft. mir z.b. is ai aus irgendwelchen (z.b. politischen) gründen ein dorn im aug. und somit kriegt jeder, der meine dns-server konsultiert, für http://www.amnesty.org die 127.0.0.1 retour, oder ich leite ihn mit einer andren ip auf eine site um, die mir in den kram paßt.
und das soll gut sein?
dns ist ein system zur namensauflösung und keine "sicherheitsarchitektur". und *genau so* soll es auch bleiben.

aja, und du hast ja diesen faden ja auch nur eröffnet, weils überhaupt keinen zoff mit opendns gibt. "niemand" hat zoff mit opendns, dir und deinem bind is sozusagen nur "fad in der birn"...

lg
zid

im aug. und somit kriegt jeder, der meine dns-server konsultiert, für http://www.amnesty.org die 127.0.0.1 retour, oder ich leite ihn mit einer andren ip auf eine site um, die mir in den kram paßt.

Aaaaaah, jetzt weiss ich warum ich da nicht mehr hin komm - so a Lauser

zid hat geschrieben:.....
aja, und du hast ja diesen faden ja auch nur eröffnet, weils überhaupt keinen zoff mit opendns gibt. "niemand" hat zoff mit opendns, dir und deinem bind is sozusagen nur "fad in der birn"...
lg
zid

Lol, so würde ichs nicht sagen. "Zoff" Der dns löst via UPC die IP falsch auf. Aber, egal. Vielleicht änder ichs mal wirklich auf einen komplett ungefilterten dns.

> Lol, so würde ichs nicht sagen. "Zoff" Der dns löst via UPC die IP falsch auf. Aber, egal. Vielleicht änder ichs mal wirklich auf einen komplett ungefilterten dns.

die leitung hat mit dem DNS zunächst überhaupt nichts zu tun. es gilt der DNS, der auf deinem rechner (oder in deinem router) eingetragen ist.

was aber passiert sein kann, ist, dass der erste eingetragene DNS ueber UPC nicht oder nicht schnell genug erreichbar war. (zb durch ein routingproblem, oder weil der DNS-server anfragen von bestimmten ip-bereichen nicht beantwortet). dann probiert dein PC nach üblicherweise 30 sekunden den zweiten eingetragenen DNS, und dann ev. den dritten. und wenn sich keiner von denen meldet, gibts eine fehlermeldung.

deshalb sollte man gelegentlich die aktualität der manuell eingetragenen nameserver überprüfen. (ich bin auch erst durch zufall draufgekommen, dass ich auf einem notebook noch einen vor jahren abgeschalteten nameserver von eunet eingetragen hatte. dass die namensauflösung manchmal etwas dauerte, hatte ich aufs wlan und das nicht mehr ganz neue notebook geschoben ...)

jutta hat geschrieben:> Lol, so würde ichs nicht sagen. "Zoff" Der dns löst via UPC die IP falsch auf. Aber, egal. Vielleicht änder ichs mal wirklich auf einen komplett ungefilterten dns.

die leitung hat mit dem DNS zunächst überhaupt nichts zu tun. es gilt der DNS, der auf deinem rechner (oder in deinem router) eingetragen ist.

was aber passiert sein kann, ist, dass der erste eingetragene DNS ueber UPC nicht oder nicht schnell genug erreichbar war. (zb durch ein routingproblem, oder weil der DNS-server anfragen von bestimmten ip-bereichen nicht beantwortet). dann probiert dein PC nach üblicherweise 30 sekunden den zweiten eingetragenen DNS

Nein. Schau mal in meinen ersten Post. Da hab ich mit nslookup eztv.it <opendns ip> das getestet. Ergebnis, auf meinem Standpc kommt bei der letzten Octet Group 81 raus, beim Laptop, den ich via. drei ins Netz gehängt habe kommt am ende ".80" raus. Warum auch immer, in dem Fall hats mit dem Provider zu tun. Inwiefern auch immer.
Da ich das mit nslookup überprüfe, kann da nicht einfach ein anderer DNS nachher probiert werden. Schließlich schick ich ja die Request zur Namensauflösung direkt an den DNS ohne den Umweg über die eingetragenen dns server in der /etc/resolv.conf (die durch den bind server von meiner FW Kiste) befüllt wird.

wenn ich am ta-biz anschluss ein traceroute nach 208.67.222.222 mache, geht das via frankfurt und dauert rund 25 ms. wenn ich es am upc-anschluss mache, geht es via london und dauert rund 70 ms. ob da jetzt load-balancing zuschlaegt oder sonst eine verwirrung laesst sich ohne mitwirkung der NOC-teams diverser provider auf der strecke wahrscheinlich nicht rausfinden.

london ist jedenfalls genau der nameserver, der laut der website von opendns *.81 sagt.

Code: Alles auswählen

traceroute to 208.67.222.222 (208.67.222.222), 30 hops max, 40 byte packets
1  91.113.248.65 (91.113.248.65)  3.922 ms  4.459 ms  5.436 ms
2  62.47.95.239 (62.47.95.239)  9.352 ms  10.920 ms  12.580 ms
3  172.19.63.165 (172.19.63.165)  13.902 ms  15.088 ms  16.797 ms
4  195.3.118.9 (195.3.118.9)  18.515 ms  20.177 ms  21.892 ms
5  195.3.68.202 (195.3.68.202)  35.906 ms 195.3.68.18 (195.3.68.18)  74.047 ms AUX2-AUX3.highway.telekom.at (195.3.68.210)  40.087 ms
6  ae1-104.fra60.ip4.tinet.net (141.136.99.57)  41.025 ms  20.525 ms  20.976 ms
7  xe-8-0-2.fra21.ip4.tinet.net (141.136.110.85)  23.257 ms xe-8-2-0.fra21.ip4.tinet.net (89.149.184.85)  24.965 ms xe-0-0-0.fra21.ip4.tinet.net (89.149.186.181)  26.096 ms
8  opendns-gw.ip4.tinet.net (77.67.95.70)  28.019 ms  29.730 ms  31.474 ms
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  *^C
srv01:/home/jutta# traceroute 208.67.222.222 -I
traceroute to 208.67.222.222 (208.67.222.222), 30 hops max, 40 byte packets
1  91.113.248.65 (91.113.248.65)  3.886 ms  4.438 ms  5.431 ms
2  62.47.95.239 (62.47.95.239)  15.447 ms  16.529 ms  18.272 ms
3  172.19.63.165 (172.19.63.165)  19.623 ms  21.316 ms  23.053 ms
4  195.3.118.9 (195.3.118.9)  24.571 ms  25.916 ms  27.638 ms
5  195.3.68.202 (195.3.68.202)  70.595 ms  70.958 ms  71.343 ms
6  ae1-104.fra60.ip4.tinet.net (141.136.99.57)  47.561 ms  22.244 ms  24.324 ms
7  xe-3-2-0.fra21.ip4.tinet.net (89.149.181.206)  26.810 ms  23.078 ms  24.773 ms
8  opendns-gw.ip4.tinet.net (77.67.95.70)  26.679 ms  22.712 ms  24.210 ms
9  resolver1.opendns.com (208.67.222.222)  25.356 ms  22.602 ms  24.236 ms
srv01:/home/jutta#

root@deb-kanzlei:/home/jutta# traceroute 208.67.222.222
traceroute to 208.67.222.222 (208.67.222.222), 30 hops max, 60 byte packets
1  192.168.0.1 (192.168.0.1)  2.996 ms  2.965 ms  5.427 ms
2  84.116.231.158 (84.116.231.158)  39.361 ms  40.626 ms  41.562 ms
3  84.116.229.177 (84.116.229.177)  43.586 ms  45.277 ms  46.695 ms
4  at-vie-xion-pe02-vl-2056.upc.at (84.116.228.205)  81.199 ms  82.916 ms  84.048 ms
5  at-vie15a-rd1-vl-2051.aorta.net (84.116.229.1)  85.692 ms  87.232 ms  89.365 ms
6  uk-lon01b-rd1-xe-7-1-2.aorta.net (84.116.134.229)  88.312 ms uk-lon01b-rd1-xe-1-0-2.aorta.net (84.116.130.253)  71.352 ms  74.723 ms
7  84.116.133.230 (84.116.133.230)  71.213 ms  72.423 ms  74.150 ms
8  gi0-2.rtr1.lon.opendns.com (195.66.225.70)  73.223 ms  74.417 ms  73.702 ms
9  * * *
10  * * *
11  * * *
12  *^C
root@deb-kanzlei:/home/jutta# traceroute 208.67.222.222 -I
traceroute to 208.67.222.222 (208.67.222.222), 30 hops max, 60 byte packets
1  192.168.0.1 (192.168.0.1)  1.897 ms  5.803 ms *
2  * * *
3  * * *
4  * * *
5  * * *
6  * uk-lon01b-rd1-xe-1-0-2.aorta.net (84.116.130.253)  72.751 ms  73.732 ms
7  84.116.133.230 (84.116.133.230)  75.020 ms  76.300 ms *
8  * * *
9  * * *
10  * * *
11  * * *
12  * resolver1.opendns.com (208.67.222.222)  71.329 ms  73.670 ms
root@deb-kanzlei:/home/jutta#


>"...Warum auch immer, in dem Fall hats mit dem Provider zu tun..."
das is richtig, frage is halt nur welcher- upc oder opendns?
nur kurz mal 2 *theoretische beispiele* (und das sind jetzt wirklich beispiele und keine unterstellungen), was da so abgehen kann:

1. upc is ein lauser und lenkt alle dns-requests auf eigene server um, die garbage liefern.
d.h. du kannst

Code: Alles auswählen

nslookup eztv.it 208.67.222.222
dig eztv.it @208.67.222.222

machen soviel du willst, upc lenkt alles mit dst-port udp/53 auf eigene server um und faket die antwort gleich doppelt: 1x bei der ip selbst und dann noch beim "Server", sodaß der user glaubt, opendns konsultiert zu haben, obwohl real opendns gar nicht im spiel war.
mach ich z.b. bei meinen gästen, um sie vor "malicious" sites wie ai, facebook u.ä. zu "schützen", kostenlos bitte...

2. opendns beantwortet dns-requests in abhängigkeit von der src-ip der requests.
d.h. es werden deine anfragen schon von opendns beantwortet, aber eben in abhängigkeit von der src-ip der anfrage, weil es z.b. aus irgendwelchen gründen eine bilaterale "vereinbarung" von upc und opendns gibt.

wie kannst du #1 und #2 aufdröseln?

- du verwendest saubere dns-server, also z.b. den vom wolfgang samsinger in tirol (85.126.4.170) oder den vom ccc in berlin (213.73.91.35).
- und dann:

Code: Alles auswählen

nslookup eztv.it 85.126.4.170
nslookup eztv.it 213.73.91.35

oder (dig is mir lieber)

dig eztv.it @85.126.4.170
dig eztv.it @213.73.91.35

wenn du mit diesen servern noch immer die falsche ip 185.19.104.81 kriegst, dann liegt das prob ziemlich sicher bei upc. kriegst du hingegen die richtige ip 185.19.104.80, dann gibts zoff bei opendns.
aja, mit dig kann man den dns-tree auch sehr schön tracen.

lg
zid

jutta hat geschrieben:wenn ich am ta-biz anschluss ein traceroute nach 208.67.222.222 mache, geht das via frankfurt und dauert rund 25 ms. wenn ich es am upc-anschluss mache, geht es via london und dauert rund 70 ms. ob da jetzt load-balancing zuschlaegt oder sonst eine verwirrung laesst sich ohne mitwirkung der NOC-teams diverser provider auf der strecke wahrscheinlich nicht rausfinden.

london ist jedenfalls genau der nameserver, der laut der website von opendns *.81 sagt.

naja ... A1 ist in dem Bereich halt zu klein. UPC als Teil von Aorta ist da schon eine andere Größe am (europ.) Markt. Jeder routet so wie er es für richtig empfindet.

noch einmal vom inode/upc-anschluss:

Code: Alles auswählen

root@hp8570:/home/jutta# dig eztv.it @85.126.4.170

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> eztv.it @85.126.4.170
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45453
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;eztv.it.         IN   A

;; ANSWER SECTION:
eztv.it.      601   IN   A   185.19.104.80

;; AUTHORITY SECTION:
eztv.it.      1501   IN   NS   gdns1.ezdns.io.
eztv.it.      1501   IN   NS   gdns2.ezdns.io.

;; ADDITIONAL SECTION:
gdns1.ezdns.io.      8330   IN   A   185.19.106.14
gdns2.ezdns.io.      8330   IN   A   185.19.106.10

;; Query time: 28 msec
;; SERVER: 85.126.4.170#53(85.126.4.170)
;; WHEN: Sat Aug 17 05:29:50 2013
;; MSG SIZE  rcvd: 121

root@hp8570:/home/jutta# dig eztv.it @208.67.222.222

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> eztv.it @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28571
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;eztv.it.         IN   A

;; ANSWER SECTION:
eztv.it.      665   IN   A   185.19.104.81

;; Query time: 39 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Aug 17 05:30:00 2013
;; MSG SIZE  rcvd: 41

root@hp8570:/home/jutta#