Re: Datei mit Root-Name-Server mit "dig" erstellen
On Tue, 14 Oct 2003 20:00:26 +0200, Michelle Konzack
<linux4michelle@freenet.de> wrote:
Am 2003-10-14 18:47:52, schrieb Thilo Engelbracht:
Hallo Liste!
In meinem LAN habe ich einen Name-Server mit BIND9 aufgesetzt. Alles
funktioniert ohne Schwierigkeiten.
Nun habe ich noch folgendes Problem: Von Zeit zu Zeit möchte ich die
Datei mit den Root-Servern aktualisieren.
Das wäre Quatsch, nimm einfach den Nameserver Deines ISPs.
??? Bist Du ISP mit ner eigenen OC3 oder sowas ???
:-) *freu*
Der Server existiert schon seit ewigkeiten (6 Jahre oder so) nicht
mehr public. Da war mal WHOIS drauf, der ebenfals abgestellt ist.
jetzt gehts los.. *sing*
;; connection timed out; no servers could be reached
Wieso tust Du sowas ???
Man zapft keine Root-Server zum PRIVATEN Vergnügen an...
Nein? Anzapfen? also illegales Entwenden ist das?
Das Ding ist Account-Geschützt.
ahh soo...
3.) Ich könnte mir event. die Datei von dem FTP-Server herunterladen -
ich möchte aber gerne die "dig"-Methode nutzen.
Wieviele hundert MByte ???
Auf dem FTP ist es kompremiert !!!
*amKaffeeverschluck* darauf habe ich gewartet!! :-))
soso.. wieviele Milliarden Root-Server gibt es denn so, damit die
Textdateien mehrere hundert MByte gross werden koennen!!? btw, stop
plonking!
Hat jemand eine Idee? Liegt es vielleicht an der "dig"-Syntax?
Ja, an Deiner! Du bist blind dem Beispiel aus dem Buch gefolgt - nimm
einfach einen anderen normalen DNS-Server, und schreib den Befehl richtig!
--> /etc/resolv.conf
Unless it is told to query a specific name server, dig will try
each of
the servers listed in /etc/resolv.conf.
Das heisst, Du bist theoretisch auch immer bei jeder Frage hochaktuell,
wenn beim Einwählen in den ISP zB. der DNS-Server erneut in die
resolv.conf eingetragen wird!
Die Root-Server kannste nicht mehr anzapfen. Die sind mittlerweile alle
blokiert und nur ein ausgewählter Kreis von Zahlenden Kunden hat dort
einen direkten account.
Was glaubt Du eigentlich, was passiert, wenn das jeder macht ?
Ja, was denn?? Ich freue mich jetzt schon auf dieses Lustspiel..
Ich denke das wäre nicht so fatal wie die letzten großen DoS-Attacken -
zumal man ja nur alle paar Monate ein Update machen bräuchte. Also da
muessen die Debian-Mirror durch das ständige apt-get update`n erheblich
mehr aushalten, zumal da richtig was an Traffic über die Leitung geht. So
ein dig braucht Zehntelsekunden.
Ach, was wäre die Liste nur ohne Dich Katastrophen-Menschen, Michelle..?
;-)
Wir brauchen solche kompremerten Tricolores - früher haette man sie
exekutiert, und dafür viele Gräben diggen lassen.
Thilo, Dein Fehler:
dig rs.internic.net . ns > dateiname ::::: so muss es heißen! ohne das @
Zeichen!!
Dann klappts auch mit dem Download ohne Header-Fehler und wir erhalten
eine "mehrere hundert, ähem.. Bytes" große Datei:
cyberdune@mars:~$ dig rs.internic.net . ns > dateiname | more dateiname
; <<>> DiG 9.2.2 <<>> rs.internic.net . ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35646
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 10, ADDITIONAL: 10
;; QUESTION SECTION:
;rs.internic.net. IN A
;; ANSWER SECTION:
rs.internic.net. 161787 IN A 198.41.0.6
;; AUTHORITY SECTION:
internic.net. 153057 IN NS sec1.apnic.net.
internic.net. 153057 IN NS sec3.apnic.net.
internic.net. 153057 IN NS svc00.apnic.net.
internic.net. 153057 IN NS a.iana-servers.net.
internic.net. 153057 IN NS b.iana-servers.org.
internic.net. 153057 IN NS c.iana-servers.net.
internic.net. 153057 IN NS ns.apnic.net.
internic.net. 153057 IN NS ns.icann.org.
internic.net. 153057 IN NS ns1.crsnic.net.
internic.net. 153057 IN NS ns2.nsiregistry.net.
;; ADDITIONAL SECTION:
sec1.apnic.net. 52045 IN A 202.12.29.59
sec3.apnic.net. 153 IN A 202.12.28.140
svc00.apnic.net. 55796 IN A 202.12.28.131
a.iana-servers.net. 123180 IN A 192.0.34.43
b.iana-servers.org. 12969 IN A 193.0.0.236
c.iana-servers.net. 37000 IN A 139.91.1.10
ns.apnic.net. 2025 IN A 203.37.255.97
ns.icann.org. 15449 IN A 192.0.34.126
ns1.crsnic.net. 37131 IN A 198.41.3.39
ns2.nsiregistry.net. 92283 IN A 198.41.3.108
;; Query time: 11 msec
;; SERVER: 213.148.130.10#53(213.148.130.10)
;; WHEN: Tue Oct 14 23:48:01 2003
;; MSG SIZE rcvd: 445
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60009
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 382509 IN NS l.root-servers.net.
. 382509 IN NS m.root-servers.net.
. 382509 IN NS i.root-servers.net.
. 382509 IN NS e.root-servers.net.
. 382509 IN NS d.root-servers.net.
. 382509 IN NS a.root-servers.net.
. 382509 IN NS h.root-servers.net.
. 382509 IN NS c.root-servers.net.
. 382509 IN NS g.root-servers.net.
. 382509 IN NS f.root-servers.net.
. 382509 IN NS b.root-servers.net.
. 382509 IN NS j.root-servers.net.
. 382509 IN NS k.root-servers.net.
;; ADDITIONAL SECTION:
l.root-servers.net. 468909 IN A 198.32.64.12
m.root-servers.net. 468909 IN A 202.12.27.33
i.root-servers.net. 468909 IN A 192.36.148.17
e.root-servers.net. 468909 IN A 192.203.230.10
d.root-servers.net. 468909 IN A 128.8.10.90
a.root-servers.net. 468909 IN A 198.41.0.4
h.root-servers.net. 468909 IN A 128.63.2.53
c.root-servers.net. 468909 IN A 192.33.4.12
g.root-servers.net. 468909 IN A 192.112.36.4
f.root-servers.net. 468909 IN A 192.5.5.241
b.root-servers.net. 468909 IN A 128.9.0.107
j.root-servers.net. 468909 IN A 192.58.128.30
k.root-servers.net. 468909 IN A 193.0.14.129
;; Query time: 10 msec
;; SERVER: 213.148.130.10#53(213.148.130.10)
;; WHEN: Tue Oct 14 23:48:01 2003
;; MSG SIZE rcvd: 436
Hier siehst Du 4 Zeilen über mir als SERVER die IP meines DNS Servers, der
befragt wird.
Michelle, dass hat also folglich mit passwortgeschützem Bereich NICHTS zu
tun, da die Anfrage gar nicht bis zu internic durchgeht! Eine Zapfanlage
oder andere dunkle und anstandslose Machenschaften kann ich hier nicht
erkennen!
Lass den Bind9 so wie er ist, Thilo. Es findet doch jeder alle Domainnames
richtig, oder!?
Gruß,
Markus
Reply to: