Namensaufloesung
Bjoern Wunschik
Ich hab hier ein etwas seltsames Problem, bei dem ich gerade nicht so
richtig weiß, wie ich es angehen soll. Die Namensauflösung von
www.urbandictionary.com funktioniert auf einer Maschine nicht, auf einer
anderen jedoch schon.
Also zwei Notebooks (eines Windows XP und eines Ubuntu 9.10) versuchen
auf www.urbandictionary.com zuzugreifen, die Windows-Büchse zeigt mir die
erwartete Startseite und die Ubuntu-Maschine sagt, daß sie die Adresse
nicht finden kann. Beide Maschinen stehen im selben /24 und benutzen den
selben Nameserver. In der hosts-Datei des Ubuntu-Rechners ist nichts
auffällig.
Wo sollte ich anfangen zu buddeln, um rauszufinden was da schiefläuft?
mfg
Björn Wunschik
rtfm
> Moin,
>
> Ich hab hier ein etwas seltsames Problem, bei dem ich gerade nicht so
> anderen jedoch schon.
>
> Also zwei Notebooks (eines Windows XP und eines Ubuntu 9.10) versuchen
> erwartete Startseite und die Ubuntu-Maschine sagt, da� sie die Adresse
> selben Nameserver. In der hosts-Datei des Ubuntu-Rechners ist nichts
>
> Wo sollte ich anfangen zu buddeln, um rauszufinden was da schiefl�uft?
Wie schaut die /etc/resolv.conf der Linuxbox aus?
Und dann mittels dig(1), host(1) und nslookup(1) mal genauer nachsehen
was da zur�ckkommt.
Kann die Linuxbox .com aufl�sen? urbandictionary.com?
Auch mal den SOA record ansehen:
dig urbandictionary.com SOA
Ich hab hier:
urbandictionary.com. 300 IN SOA ns.voxel.net.
hostmaster.voxel.net. 1271184079 10800 3600 604800 300
(in einer Zeile)
Soweit f�r's erste
rtfm
Bjoern Wunschik
> Wie schaut die /etc/resolv.conf der Linuxbox aus?
| # Generated by NetworkManager
| nameserver 192.168.0.1
192.168.0.1 ist der WLAN-Router (Speedport 500 W), der hier Dienst tut.
Soweit also richtig. Der Speedport leitet dann zu 217.65.24.98 als
primärem bzw. 212.80.224.161 als sekundärem DNS weiter. Zugangsprovider
ist Versatel.
> Und dann mittels dig(1), host(1) und nslookup(1) mal genauer nachsehen
> was da zurückkommt.
bjoern@marvin:~$ dig www.urbandictionary.com
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.0.1#53(192.168.0.1) for www.urbandictionary.com
failed: connection refused.
bjoern@marvin:~$ host www.urbandictionary.com
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.0.1#53(192.168.0.1) for www.urbandictionary.com
failed: connection refused.
bjoern@marvin:~$ nslookup www.urbandictionary.com
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.0.1#53(192.168.0.1) for www.urbandictionary.com
failed: connection refused.
Wenn ich das richtig verstehe, werden die Anfragen also abgewiesen. Aber
warum?
> Kann die Linuxbox .com auflösen? urbandictionary.com?
Bei "dig com" und "dig urbandictionary.com" werde ich jedenfalls nicht
abgewiesen und bei "dig urbandictionary.com" bekomme ich auch eine IP
(74.63.40.28). Oder meintest Du was anderes?
> Auch mal den SOA record ansehen:
>
> dig urbandictionary.com SOA
>
> Ich hab hier:
>
> urbandictionary.com. 300 IN SOA ns.voxel.net.
> hostmaster.voxel.net. 1271184079 10800 3600 604800 300
urbandictionary.com. 260 IN SOA ns.voxel.net.
hostmaster.voxel.net. 1271184079 10800 3600 604800 300
mfg
Björn Wunschik
Sven Hartge
> * rtfm schrieb:
>> Wie schaut die /etc/resolv.conf der Linuxbox aus?
> | # Generated by NetworkManager
> | nameserver 192.168.0.1
> 192.168.0.1 ist der WLAN-Router (Speedport 500 W), der hier Dienst tut.
> Soweit also richtig. Der Speedport leitet dann zu 217.65.24.98 als
> primärem bzw. 212.80.224.161 als sekundärem DNS weiter. Zugangsprovider
> ist Versatel.
>> Und dann mittels dig(1), host(1) und nslookup(1) mal genauer nachsehen
>> was da zurückkommt.
> bjoern@marvin:~$ dig www.urbandictionary.com
> ;; Truncated, retrying in TCP mode.
> ;; Connection to 192.168.0.1#53(192.168.0.1) for www.urbandictionary.com
> failed: connection refused.
Die Antwort ist sehr groß, größer als 512 Bytes. Daher muss die
Auflösung dann via TCP erfolgen. Dies kann der Speedport wohl nicht
(ergo: Software defekt! auf dem Speedport).
Mein Ergebnis folgt. Achte auf die "MSG SIZE" am Ende.
,----
| ;; Truncated, retrying in TCP mode.
|
| ; <<>> DiG 9.7.0-P1 <<>> www.urbandictionary.com
| ;; global options: +cmd
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49297
| ;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 13, ADDITIONAL: 13
|
| ;; QUESTION SECTION:
| ;www.urbandictionary.com. IN A
|
| ;; ANSWER SECTION:
| www.urbandictionary.com. 233 IN CNAME 3356.voxcdn.com.
| 3356.voxcdn.com. 60 IN CNAME content.ams2.site.voxcdn.net.
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.28
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.29
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.3
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.4
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.11
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.12
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.13
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.14
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.15
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.16
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.17
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.18
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.22
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.24
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.26
| content.ams2.site.voxcdn.net. 60 IN A 208.122.31.27
|
| ;; AUTHORITY SECTION:
| net. 169992 IN NS f.gtld-servers.net.
| net. 169992 IN NS g.gtld-servers.net.
| net. 169992 IN NS i.gtld-servers.net.
| net. 169992 IN NS m.gtld-servers.net.
| net. 169992 IN NS h.gtld-servers.net.
| net. 169992 IN NS c.gtld-servers.net.
| net. 169992 IN NS b.gtld-servers.net.
| net. 169992 IN NS e.gtld-servers.net.
| net. 169992 IN NS d.gtld-servers.net.
| net. 169992 IN NS j.gtld-servers.net.
| net. 169992 IN NS k.gtld-servers.net.
| net. 169992 IN NS l.gtld-servers.net.
| net. 169992 IN NS a.gtld-servers.net.
|
| ;; ADDITIONAL SECTION:
| a.gtld-servers.net. 60160 IN A 192.5.6.30
| a.gtld-servers.net. 86541 IN AAAA 2001:503:a83e::2:30
| c.gtld-servers.net. 93529 IN A 192.26.92.30
| d.gtld-servers.net. 86541 IN A 192.31.80.30
| e.gtld-servers.net. 72279 IN A 192.12.94.30
| f.gtld-servers.net. 15293 IN A 192.35.51.30
| g.gtld-servers.net. 15293 IN A 192.42.93.30
| h.gtld-servers.net. 86541 IN A 192.54.112.30
| i.gtld-servers.net. 88423 IN A 192.43.172.30
| j.gtld-servers.net. 41761 IN A 192.48.79.30
| k.gtld-servers.net. 69614 IN A 192.52.178.30
| l.gtld-servers.net. 72279 IN A 192.41.162.30
| m.gtld-servers.net. 41761 IN A 192.55.83.30
|
| ;; Query time: 14 msec
| ;; SERVER: 127.0.0.1#53(127.0.0.1)
| ;; WHEN: Sat Apr 24 19:13:15 2010
| ;; MSG SIZE rcvd: 806
`----
Am besten konfigurierst du den Linux-Rechner so, dass er direkt die
externen DNS benutzt und nicht den verkrüppelten Resolver auf dem
Speedport.
S°
--
Sig lost. Core dumped.
Sven Hartge
> * rtfm schrieb:
>> Wie schaut die /etc/resolv.conf der Linuxbox aus?
> | # Generated by NetworkManager
> | nameserver 192.168.0.1
> 192.168.0.1 ist der WLAN-Router (Speedport 500 W), der hier Dienst tut.
> Soweit also richtig. Der Speedport leitet dann zu 217.65.24.98 als
> primärem bzw. 212.80.224.161 als sekundärem DNS weiter. Zugangsprovider
> ist Versatel.
>> Und dann mittels dig(1), host(1) und nslookup(1) mal genauer nachsehen
>> was da zurückkommt.
> bjoern@marvin:~$ dig www.urbandictionary.com
> ;; Truncated, retrying in TCP mode.
> ;; Connection to 192.168.0.1#53(192.168.0.1) for www.urbandictionary.com
> failed: connection refused.
Die Antwort ist sehr groß, größer als 512 Bytes. Daher muss die
Auflösung dann via TCP erfolgen. Dies kann der Speedport wohl nicht
(ergo: Software defekt! auf dem Speedport).
Dieses Problem mit dem fehlenden TCP-Support für DNS-Anfragen ist recht
verbreitet bei diesen Geräten. Oder dass der Resolver sich nicht um TTLs
schert etc. Daher rate ich meist grundsätzlich davon ab, den Resolver
dieser Geräte zu benutzen.
Mein Ergebnis folgt. Achte auf die "MSG SIZE" am Ende.
,----
| ;; Truncated, retrying in TCP mode.
|
Bjoern Wunschik
> Am besten konfigurierst du den Linux-Rechner so, dass er direkt die
> externen DNS benutzt und nicht den verkrüppelten Resolver auf dem
> Speedport.
Alles klar, danke. Ich werde das probieren. Trotzdem verwundert es mich,
daß das Windows auf dem anderen Rechner eine Antwort bekommt. Benutzen
die dieses Extended DNS von dem ich gerade gelesen habe oder wie machen
die das?
mfg
Björn Wunschik
Sven Hartge
Keine Ahnung. Da müßtest du mal mit dem Sniffer wie wireshark ran um
herauszufinden, was Windows treibt.
Juergen Ilse
Moeglicherweise, vielleicht aber auch gerade nicht (waehrend Linux das
ggfs. versucht), das muesste man wohl dann mal genauer diagnostizieren ...
Evt. ist es ja so, dass Linux versucht EDNS0 zu verwenden, aber der
Support dafuer im resolver des Speedport kaputt ist, so dass Windows
nur deswegen funktioniert, weil es *kein* EDNS0 anfordert ...
Aber wie gesagt, man muesste dazu wohl naeher untersuchen, was denn nun
genau da ablaeuft.
EDNS0 ist eine Erweiterung, bei der IIRC der Client mit der Anfrage
zusammen eine "Maximalgroesse fuer eine UDP-Antwort" mitsenden kann,
und dann der Server (sofern er das kennt) eben die Default-Obergrenze
fuer UDP-Antworten nutzt, die in der Anfrage mitgegeben wurde statt
dem Default von 512 Byte. Dadurch werden (wenn es denn sowohl im Client
wie im Server implementiert ist) die Anzahl an "unvollstaendigen Ant-
worten" (die dann i.d.R. ein erneutes nachfragen per TCP ausloesen)
u.U. drastisch reduziert. Fuer den sinnvollen Einsatz von DNSSEC
wird EDNS0 erforderlich werden, denn bei DNSSEC werden fast alle
Antworten fuer die 512-Byte zu gross werden ...
Es soll allerdings auch manche DNS-Server geben, die EDNS0-Support
nicht korrekt implementieren, was dann ggfs. zu Timeouts und erneuten
Anfragn fuehren kann (naeheres weiss ich dazu allerdings nicht, ich
meine mich nur zu erinnern, so etwas auf der powerdns-Mailingliste
gelesen zu haben ...). Es waere auch eine Option, den powerdns recursor
zu installieren und diesn fuer die DNS-Aufloesung zu verwenden. Er ist
einfach zu konfigurieren und reicht fuer einen "chache-only" DNS (und
ggfs. einige wenige lokale Zonen, allerdings dann ohne dynamische
Updates oder dergleichen) sollstaendig aus (und er benoetigt im Gegen-
satz zu einigen anderen "kleinen DNS-Servern" fuer das lokale Netz
keinen forwarder, da er sich ggfs. selbst von den root-Nameservern aus
durchhangelt ...). Im aktuellen powerdns recursor ist per Default IIRC
ENDS0 fuer *ausgehende* Anfragen disabled (und momentan wurde auf der
Mailingliste noch davon abgeraten, es in der Konfigurationsdatei ein-
zuschalten).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Sven Hartge
> Es soll allerdings auch manche DNS-Server geben, die EDNS0-Support
> nicht korrekt implementieren, was dann ggfs. zu Timeouts und erneuten
> Anfragn fuehren kann (naeheres weiss ich dazu allerdings nicht, ich
> meine mich nur zu erinnern, so etwas auf der powerdns-Mailingliste
> gelesen zu haben ...).
Zusätzlich dazu gibt es IDS-Lösungen bzw. Paket-Filter, die nicht
korrekt mit ENDS umgehen können und dies dann blocken oder verstümmeln.
Sehr nett für dem Admin, wenn sein Nameserver zwar EDNS kann, ihm die
Netzgruppe aber eine Firewall vor die Nase setzt, die das Protokoll
wieder kaputt macht.
Juergen P. Meier
> Moin,
>
> Ich hab hier ein etwas seltsames Problem, bei dem ich gerade nicht so
> richtig weiß, wie ich es angehen soll. Die Namensauflösung von
> www.urbandictionary.com funktioniert auf einer Maschine nicht, auf einer
> anderen jedoch schon.
Das ist ein CNAME eines CNAME eines CNAME mit so vielen A RRs, dass
einige infantile dysfunktionale Moechtegern-Applikationsfilternde
Schrottfirewalls die etwas groesseren DNS Pakete verwerfen.
Ersteres ist kaputt (der IETF Domain Name Service Standard forder
ausdruecklich, dass CNAME Records direkt auf den kanonischen Namen
verweisen sollten. Siehe RFC 1034 Abschnitt 5.2.2), letztes waere ein
Problem bei dir, falls es die Ursache ist.
Einige Resolver werden dir auch den Mittelfinger zeigen weil zu viele
CNAME Indirektionen vorhanden sind und sie sich schlicht weigern
(konform mit dem Standard!), hier Schnitzeljagt zu spielen.
> Also zwei Notebooks (eines Windows XP und eines Ubuntu 9.10) versuchen
> auf www.urbandictionary.com zuzugreifen, die Windows-Büchse zeigt mir die
> erwartete Startseite und die Ubuntu-Maschine sagt, daß sie die Adresse
> nicht finden kann. Beide Maschinen stehen im selben /24 und benutzen den
> selben Nameserver. In der hosts-Datei des Ubuntu-Rechners ist nichts
> auffällig.
Was fuer ein DNS Resolver ist auf Unbunt installiert?
> Wo sollte ich anfangen zu buddeln, um rauszufinden was da schiefläuft?
dig hilft
Ansonsten beschwere dich bei dem Idioten, der diese kaputten DNS
Eintraege verbrochen hat.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
> bjoern@marvin:~$ dig www.urbandictionary.com
> ;; Truncated, retrying in TCP mode.
> ;; Connection to 192.168.0.1#53(192.168.0.1) for www.urbandictionary.com
> failed: connection refused.
Dein DNS ist kaputt.
Du schiesst dir geraden Loecher in deine Fuesse weil du TCP Port 53
blockierst.
Holger Marzen
> bjoern@marvin:~$ dig www.urbandictionary.com
> ;; Truncated, retrying in TCP mode.
> ;; Connection to 192.168.0.1#53(192.168.0.1) for www.urbandictionary.com
> failed: connection refused.
Große Antworten kommen per TCP. Blockst Du TCP Port 53 per Paketfilter?
Bjoern Wunschik
Nein, zumindest nicht vorsätzlich.
Ich habe getan, was Sven mir riet und greife nun direkt von der Linux-
Maschine auf die externen DNS zu. Es funktioniert.
danke euch
Björn Wunschik
Bjoern Wunschik
> Bjoern Wunschik <ral...@gmx.net>:
>> bjoern@marvin:~$ dig www.urbandictionary.com
>> ;; Truncated, retrying in TCP mode.
>> ;; Connection to 192.168.0.1#53(192.168.0.1) for
>> www.urbandictionary.com failed: connection refused.
>
> Dein DNS ist kaputt.
Ja, das auf dem Speedport (es ist übrigens ein Speedport W 500V und nicht
500 W wie ich an anderer Stelle schrieb) scheint einen weg zu haben.
Langfristig werde ich wohl mal sehen, ob es eine alternative Firmware für
das Ding gibt, die solche Probleme nicht verursacht. Für den Moment ist
es durch einen Wechsel der DNS-Server getan.
> Du schiesst dir geraden Loecher in deine Fuesse weil du TCP Port 53
> blockierst.
Nicht wissentlich oder vorsätzlich. Ich habe an den Filterregeln des
Speedport nicht gedreht.
mfg
Björn Wunschik