Wie eigene ppp0|dyn.IP in A|CNAME-Records vom eig. NS reinbekommen ???

  • Thread starter Thread starter blob
  • Start date Start date
B

blob

Guest
Wie eigene ppp0|dyn.IP in A-Records beim eig. NS reinbekommen ???

Bei einem site, zBsp. guyane.yi.org, habe ich jedesmal Probleme mit dem updaten meiner dyn. DNS wenn Leitung / Rechner / Strom abstürzen.

Deshalb habe ich jetzt dort die A-Records gelöscht, und NS-Records zu mir hin gemacht.

Den Namen mit www ... und irc ... davor (also das Wichtigste), habe ich mit dem von meinem Rechner gleichgesetzt, und somit das Problem momentan auf einen NS eines anderen, zuverlässigeren dyndns-Dienstes abgewälzt. Das funktioniert insoweit, daß mit ping der Name korrekt aufgelöst wird und echo kommt. Ich weiß aber nicht, ob von anderen Rechnern aus aufgerufen, die DNS gefunden würde (Einzelheiten in Liste unten)

Besser, und auch um den site-namen ohne was davor benutzen zu können, wäre es aber, wenn ich nicht weiterverweisen sondern selbst die DNS für mein site terminativ auflösen könnte. Wenn ich die momentane IP direkt in den A-Rekord eintippe, funktioniert das ganz korrekt, incl. mit #dig [+trace]; #dig @<mein-NS>|<yi.org-NS> <site> ; #ping usw.

Aber diese dyn. IP ändert sich ja dauernd. Wenn ich 127.0.0.1 ; localhost ; ppp0 ; monkey.is-a-geek.net. oder guyane.dyn-o-saur.com. (Namen meines Rechners bei dyndns, schon vorher upgedated) in den A-Record schreibe, geht dagegen gar nichts mehr (Fehlermeldungen server-error)

Wie kann man das denn machen ? Ich habe schon lange erfolglos rumprobiert.



### /var/named/caching-example/guyane.yi.org : ###

$TTL 120
$ORIGIN localhost.
guyane.yi.org. 120 IN SOA guyane.yi.org. blob.monkey.is-a-geek.net (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum

120 IN NS monkey.is-a-geek.net.
120 IN NS guyane.dyn-o-saur.com.
guyane.yi.org. 120 IN A 127.0.0.1
www.guyane.yi.org. 120 IN CNAME monkey.is-a-geek.net.
irc.guyane.yi.org. 120 IN CNAME monkey.is-a-geek.net.




### site mit www davor: ###


#ping www.guyane.yi.org -->
PING monkey.is-a-geek.net (193.248.72.123) 56(84) bytes of data.
64 bytes from 193.248.72.123: icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from 193.248.72.123: icmp_seq=2 ttl=64 time=0.144 ms
64 bytes from 193.248.72.123: icmp_seq=3 ttl=64 time=0.143 ms
64 bytes from 193.248.72.123: icmp_seq=4 ttl=64 time=0.145 ms
64 bytes from 193.248.72.123: icmp_seq=5 ttl=64 time=0.147 ms

--- monkey.is-a-geek.net ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 0.116/0.139/0.147/0.011 ms


#dig www.guyane.yi.org -->
; <<>> DiG 9.3.2-P2 <<>> +trace www.guyane.yi.org
;; global options: printcmd
. 16552 IN NS B.ROOT-SERVERS.NET.
. 16552 IN NS C.ROOT-SERVERS.NET.
. 16552 IN NS D.ROOT-SERVERS.NET.
. 16552 IN NS E.ROOT-SERVERS.NET.
. 16552 IN NS F.ROOT-SERVERS.NET.
. 16552 IN NS G.ROOT-SERVERS.NET.
. 16552 IN NS H.ROOT-SERVERS.NET.
. 16552 IN NS I.ROOT-SERVERS.NET.
. 16552 IN NS J.ROOT-SERVERS.NET.
. 16552 IN NS K.ROOT-SERVERS.NET.
. 16552 IN NS L.ROOT-SERVERS.NET.
. 16552 IN NS M.ROOT-SERVERS.NET.
. 16552 IN NS A.ROOT-SERVERS.NET.
;; Received 228 bytes from 80.10.246.5#53(80.10.246.5) in 496 ms

org. 172800 IN NS TLD2.ULTRADNS.NET.
org. 172800 IN NS TLD3.ULTRADNS.org.
org. 172800 IN NS TLD4.ULTRADNS.org.
org. 172800 IN NS TLD5.ULTRADNS.INFO.
org. 172800 IN NS TLD6.ULTRADNS.CO.UK.
org. 172800 IN NS TLD1.ULTRADNS.NET.
;; Received 349 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 2365 ms

yi.org. 86400 IN NS fumo-viridus.crackerjack.net.
yi.org. 86400 IN NS connubialis.crackerjack.net.
;; Received 103 bytes from 204.74.113.1#53(TLD2.ULTRADNS.NET) in 1100 ms

guyane.yi.org. 300 IN NS guyane.dyn-o-saur.com.
guyane.yi.org. 300 IN NS monkey.is-a-geek.net.
;; Received 104 bytes from 72.55.129.45#53(connubialis.crackerjack.net) in 292 ms

www.guyane.yi.org. 120 IN CNAME monkey.is-a-geek.net.
is-a-geek.net. 86169 IN NS ns4.dyndns.org.
is-a-geek.net. 86169 IN NS ns5.dyndns.org.
is-a-geek.net. 86169 IN NS ns1.dyndns.org.
is-a-geek.net. 86169 IN NS ns2.dyndns.org.
is-a-geek.net. 86169 IN NS ns3.dyndns.org.
;; Received 246 bytes from 193.248.72.123#53(guyane.dyn-o-saur.com) in 1096 ms



### site ohne www : ###


#dig guyane.yi.org -->
; <<>> DiG 9.3.2-P2 <<>> +trace guyane.yi.org

.... dgl; nur am Schluss:

guyane.yi.org. 120 IN A 127.0.0.1
guyane.yi.org. 120 IN NS guyane.dyn-o-saur.com.
guyane.yi.org. 120 IN NS monkey.is-a-geek.net.
;; Received 116 bytes from 193.248.72.123#53(guyane.dyn-o-saur.com) in 996 ms
 
Last edited by a moderator:
Wie ein $INCLUDE in SOA-Record einfügen ???

Ich habe das Problem nun insoweit gelöst, dass ich die momentane dyn.IP gemäß #ifconfig ppp0 zusammen mit IN A in eine Datei schreibe, und diese mit $INCLUDE stets aufrufe. Das funktioniert jetzt auch, nach Neustart von Rechner / kppp usw.

Allerdings klappt dasselbe nicht mit der Serien-Nr. im SOA-Record. Hierbei kommt in named.run immer eine Fehlermeldung, daß die Nr. falsch ist. Weiß jemand, warum, und wie man das besser machen kann ?? Deshalb ist momentan noch der Schönheitsfehler vorhanden, daß ich momentan die Serien-Nr. gleich lasse, und ich weiß nicht, ob das schadet. In named.conf habe ich ein also-notify an die NS meines Providers und andere wichtige NS eingebaut, und der slave-NS ist sowieso gleich dem master-NS nur ein anderer Name meines eigenen Rechners.


An der wohl/fast endgültigen Lösung, s.u., sieht man auch die zwei wesentlichen Wege, das Problem des updates der dyn. IP beim Registrierer/NS der domain loszuwerden, also ohne solche Sachen wie rundns oder ez-ipupdate benutzen zu müssen:
a) Abwälzen auf die bereits erfolgte erteilte dyn. IP stns. des Providers und deren schon erfolgte Mitteilung an mich selbst; diese dyn.IP per A-Record unmittelbar dem eigenen NS und domain zuordnen. "Update" der dyn. IP nur durch Schreiben der dyn.IP im eigenen Rechner (direkt in DNS-Record, oder via include in irgendeine Datei). Wenn der eigene NS gleich dem eigenen Rechner ist, auch kein zweiter (glue-)A-Record nötig. Diese Lösung benutze ich effektiv (wobei nur der letzte der 3 NS unten relevant ist) [Verwendung von guyane.yi.org. selbst].
b) Falls schon bei einem dyndns Update erfolgt (etwa bei dyndns, wo aber nur 5 domains kostenlos sind), alle sonstigen domains, NS usw. mit CNAME darauf mappen; dazu keinerlei weiterer "Update"/irgendwohinschreiben der dyn.IP (wohl auch nicht der Serien-Nr. oder sonstwas des DNS-Records) nötig, auch nicht im eigenen Rechner. Die domain kann dann als dummy zBsp nach 127.0.0.1 gehen, www. ... , irc. ... usw mapt man dagegen mit CNAME zur domain des ersten dyndns. Unten: s. beide letzten, kommentierte Zeilen, sowie die beiden ersten Einträge als NS (eigentlich überflüssig neben der Alternative gem. Lösung a, dritter NS-Eintrag) [monkey...net; guyane...com]





$TTL 120
$ORIGIN guyane.yi.org. ; zur Vermeidung von chaos, alles explizit statt mit @
guyane.yi.org. 120 IN SOA monkey.is-a-geek.net. root.monkey.is-a-geek.net (
2007011802 ; $INCLUDE dieser Zeile funktioniert irgendwie nicht :(
1H ; refresh
15M ; retry
1W ; expiry
1H ) ; minimum

120 IN NS monkey.is-a-geek.net. ; ueberfl. falls nachfgd. Selbstbezug
120 IN NS guyane.dyn-o-saur.com.
120 IN NS guyane.yi.org. ; oder halt auch direkt die dyn.IP
$INCLUDE /var/named/caching-example/dynIP
www.guyane.yi.org. 120 IN CNAME guyane.yi.org.
irc.guyane.yi.org. 120 IN CNAME guyane.yi.org.
; www.guyane.yi.org. 120 IN CNAME monkey.is-a-geek.net. ; dann guyane.yi.org dummy, Aufloesung nicht noetig, zBsp IN A 127.0.0.1
; irc.guyane.yi.org. 120 IN CNAME monkey.is-a-geek.net. ; dgl.
 
Last edited by a moderator:
Zunächst beim NS richtige IP wird nach einiger Zeit falsch

Mein NS hat noch ein komisches Problem.


Nach jeder Neuverbindung (oder Neustart von named) wird nun die dyn. IP richtig aufgelöst und mein site zunächst gefunden; ebenso mit #ping , #dig usw.

Dann aber, nach Zeiten zwischen 20 min. und einigen Std., verschwindet diese IP, und wird stattdessen eine andere falsche (alte, von einer früheren Verbindung) verwendet, so als ob die neue korrekte IP nur temporär benutzt wurde. Mein site wird daher weder im browser noch mit #ping oder #dig weiter gefunden, auch mit #dig @<richtige-dyn.IP> <mein-site> ist diese Änderung, erfolgt also in meinen NS und nicht in anderen.

Das passiert gleichermaßen, egal ob ich (s. voriger post) mit INCLUDE einen A- Record einlese, wo die aktuelle IP steht (mit #ifconfig ppp0 hingeschrieben wurde), oder mit CNAME mein-site auf einen anderen Namen .dyndns.com etc. schiebe (s. letzte Zeilen im vorigen post).

Woran kann denn das liegen ??
 
Mein Problem, daß anfangs NS korrekt arbeitet, dann aber nach kurzer Zeit die IP meines sites vergisst / zu einer falschen wechselt, wird trotz vielem Rumprobieren nicht besser.

Nach dieser Zeit -- im Bsp nach 240 sek -- fällt die Verbindung mit dem site weg, und kommt mit #ping, auch mit #dig <mein-NS> <mein-Site> und mit #dig +trace <mein-site> die falsche IP.

Unten die aktuelle Ausgabe, vielleicht findet jemand einen Fehler. Ich habe keinen eigentlichen slave-NS, beide Namen sind mein eigener Rechner. Im config-File steht auch ein notify zu zwei NS des örtl. Internet-Providers und zu einem vom übergeordneten NS; dabei kommt vom ersten eine Fehlermeldung. Das sollte aber kein Grund sein, da ja nach genannter Zeitdauer bereits mein eigener NS mit #dig <mein-NS> <mein-site> die falsche IP gibt.

Ich sehe nichts, was an meiner Konfiguration falsch wäre. Entweder wird die neue, korrekte IP nur vorübergehend verwendet und fällt dann weg, wonach irgendeine frühere alte IP verwendet wird. Oder irgendein anderer NS pfuscht rein und sendet zu meinem NS eine falsche IP meines sites.

Wenn ich nicht gerade experimentiere, damit mein site jedenfalls funktioniert egal wie, restarte ich momentan named via cron alle 30 sek; auf solche Kleinigkeiten wie traffic kann man da keine Rücksicht nehmen, da müssten halt schlecht funktionierende Programme wie named verbessert werden. Solange dies nicht geschieht, sollte das mE jeder so machen, dass sein site läuft egal wie, sodaß das das Netz für schlechte Betriebssysteme zusammenbricht und nur gute überleben. :D In diesem Sinne ist named wieder einmal ein typisches Beispiel der Diskusion Linux vs. Windows und warum Linux nicht vorwärts kommt und es auch nicht verdient vorwärts zu kommen. 99% der Anwender wollen nicht wissen/nachforschen, warum Programme nicht funktionieren, kompliziert sind usw; ebenso wie alle anderen Gebrauchsgegenstände haben Rechner und alle Anwendungen bedingungslos und einfach zu funktionieren, was nicht - egal warum - ab in den Müll !

Code: 
########## zone-file ###############
$TTL	120
$ORIGIN copaya.yi.org.            ; zur Vermeidung von chaos, alles explizit statt mit @ 
copaya.yi.org.		120 IN SOA	monkey.is-a-geek.net. root.monkey.is-a-geek.net (   
                                        1169469894          ; serial  <-- #date -u %s 
					120		; refresh
					120		; retry
					1W		; expiry
					120 )		; minimum    
			120 IN NS	monkey.is-a-geek.net.   ; ueberfl. falls nachfgd. Selbstbezug
                        120 IN NS       guyane.dyn-o-saur.com.
			120 IN NS       copaya.yi.org.             
                        120 IN A        193.250.208.78           ;     <-- #ifconfig ppp0  
www.copaya.yi.org.      120 IN CNAME          copaya.yi.org. 
irc.copaya.yi.org.      120 IN CNAME          copaya.yi.org. 
ns.copaya.yi.org.       120 IN CNAME          copaya.yi.org.    
; www.copaya.yi.org.     120 IN CNAME          monkey.is-a-geek.net.   ; dann copaya.yi.org dummy, Aufloesung nicht noetig
; irc.copaya.yi.org.     120 IN CNAME          monkey.is-a-geek.net.   ;       dgl.   
copaya.yi.org.              IN MX   0   copaya.yi.org. 
copaya.yi.org.              IN HINFO    i686              Slackware-11
copaya.yi.org.              IN TXT      "Server / Nameserver copaya.yi.org"			      

############ /etc/named.conf ################ 
options {
	directory "/var/named";
	multiple-cnames yes;
	/*
	 * If there is a firewall between you and nameservers you want
	 * to talk to, you might need to uncomment the query-source
	 * directive below.  Previous versions of BIND always asked
	 * questions using port 53, but BIND 8.1 uses an unprivileged
	 * port by default.
	 */
	// query-source address * port 53;
};

// 
// a caching only nameserver config
// 
zone "." IN {
	type hint;
	file "caching-example/named.ca";
};

zone "localhost" IN {
	type master;
	file "caching-example/localhost.zone";
	allow-update { none; };
};

zone "guyane.yi.org" IN {
	type master;
	also-notify {80.10.246.5; 80.10.246.136; 72.55.129.45; };
	file "caching-example/guyane.yi.org";
        allow-query {any; };
	allow-update { none; };
};

zone "copaya.yi.org" IN {
	type master;
	also-notify {80.10.246.5; 80.10.246.136; 72.55.129.45; };
	file "caching-example/copaya.yi.org";
        allow-query {any; };
	allow-update { none; };
};


zone "0.0.127.in-addr.arpa" IN {
	type master;
	file "caching-example/named.local";
	allow-update { none; };
};

############## named.run    1. file ######################
##############    anfangs funktioniert Verbindung, IP korrekt,  um 10:44:22 verschwindet
##############        aber die korrekte IP und wird durch eine andere, falsche / eine einer
##############        fr<uheren Verbindung ersetzt
22-Jan-2007 10:40:22.395 now using logging configuration from config file
22-Jan-2007 10:40:22.396 load_configuration: success
22-Jan-2007 10:40:22.396 zone 0.0.127.in-addr.arpa/IN: starting load
22-Jan-2007 10:40:22.397 zone 0.0.127.in-addr.arpa/IN: number of nodes in database: 2
22-Jan-2007 10:40:22.398 zone 0.0.127.in-addr.arpa/IN: loaded
22-Jan-2007 10:40:22.398 no journal file, but that's OK
22-Jan-2007 10:40:22.398 zone 0.0.127.in-addr.arpa/IN: journal rollforward completed successfully: no journal
22-Jan-2007 10:40:22.398 zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
22-Jan-2007 10:40:22.398 zone localhost/IN: starting load
22-Jan-2007 10:40:22.399 zone localhost/IN: number of nodes in database: 1
22-Jan-2007 10:40:22.399 zone localhost/IN: loaded
22-Jan-2007 10:40:22.399 no journal file, but that's OK
22-Jan-2007 10:40:22.399 zone localhost/IN: journal rollforward completed successfully: no journal
22-Jan-2007 10:40:22.400 zone localhost/IN: loaded serial 42
22-Jan-2007 10:40:22.400 zone copaya.yi.org/IN: starting load
22-Jan-2007 10:40:22.401 zone copaya.yi.org/IN: number of nodes in database: 4
22-Jan-2007 10:40:22.401 zone copaya.yi.org/IN: loaded
22-Jan-2007 10:40:22.401 no journal file, but that's OK
22-Jan-2007 10:40:22.401 zone copaya.yi.org/IN: journal rollforward completed successfully: no journal
22-Jan-2007 10:40:22.402 zone copaya.yi.org/IN: loaded serial 1169469894
22-Jan-2007 10:40:22.402 zone guyane.yi.org/IN: starting load
22-Jan-2007 10:40:22.403 zone guyane.yi.org/IN: number of nodes in database: 4
22-Jan-2007 10:40:22.403 zone guyane.yi.org/IN: loaded
22-Jan-2007 10:40:22.403 no journal file, but that's OK
22-Jan-2007 10:40:22.403 zone guyane.yi.org/IN: journal rollforward completed successfully: no journal
22-Jan-2007 10:40:22.407 zone guyane.yi.org/IN: loaded serial 1169469894

... 

22-Jan-2007 10:40:22.412 fctx 0x8119be0(guyane.dyn-o-saur.com/A'): start
22-Jan-2007 10:40:22.412 fctx 0x8119be0(guyane.dyn-o-saur.com/A'): try
22-Jan-2007 10:40:22.412 fctx 0x8119be0(guyane.dyn-o-saur.com/A'): cancelqueries
22-Jan-2007 10:40:22.412 fctx 0x8119be0(guyane.dyn-o-saur.com/A'): getaddresses
22-Jan-2007 10:40:22.413 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.413 res 0x80de7e0: priming
22-Jan-2007 10:40:22.413 createfetch: . NS
22-Jan-2007 10:40:22.413 fctx 0x8114838(./NS'): create
22-Jan-2007 10:40:22.413 fctx 0x8114838(./NS'): join
22-Jan-2007 10:40:22.413 fetch 0x80c17c0 (fctx 0x8114838(./NS)): created
22-Jan-2007 10:40:22.413 dns_adb_createfind: found A for name 0x8118730 in db  <-- vermutlich IPs früherer
22-Jan-2007 10:40:22.413 res 0x80de7e0: dns_resolver_prime                                      Verbindungen irgendwo 
22-Jan-2007 10:40:22.413 dns_adb_createfind: found A for name 0x8118678 in db      abgespeichert,  WIE WIRD
22-Jan-2007 10:40:22.413 res 0x80de7e0: dns_resolver_prime                                     MAN DIE GANZ LOS ???
22-Jan-2007 10:40:22.413 dns_adb_createfind: found A for name 0x81185c0 in db
22-Jan-2007 10:40:22.413 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.413 dns_adb_createfind: found A for name 0x8118508 in db
22-Jan-2007 10:40:22.413 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.413 dns_adb_createfind: found A for name 0x8118450 in db
22-Jan-2007 10:40:22.413 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.413 dns_adb_createfind: found A for name 0x8118398 in db
22-Jan-2007 10:40:22.413 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.413 dns_adb_createfind: found A for name 0x81182e0 in db
22-Jan-2007 10:40:22.414 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.414 dns_adb_createfind: found A for name 0x8118228 in db
22-Jan-2007 10:40:22.414 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.414 dns_adb_createfind: found A for name 0x8118170 in db
22-Jan-2007 10:40:22.414 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.414 dns_adb_createfind: found A for name 0x81180b8 in db
22-Jan-2007 10:40:22.414 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.414 dns_adb_createfind: found A for name 0x8118000 in db
22-Jan-2007 10:40:22.414 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.414 dns_adb_createfind: found A for name 0x8117f48 in db
22-Jan-2007 10:40:22.414 res 0x80de7e0: dns_resolver_prime
22-Jan-2007 10:40:22.414 dns_adb_createfind: found A for name 0x8117e90 in db
22-Jan-2007 10:40:22.414 fctx 0x8119be0(guyane.dyn-o-saur.com/A'): query
22-Jan-2007 10:40:22.414 resquery 0x8115608 (fctx 0x8119be0(guyane.dyn-o-saur.com/A)): send
22-Jan-2007 10:40:22.415 resquery 0x8115608 (fctx 0x8119be0(guyane.dyn-o-saur.com/A)): sent
22-Jan-2007 10:40:22.415 fctx 0x8113878(guyane.dyn-o-saur.com/AAAA'): start
22-Jan-2007 10:40:22.415 fctx 0x8113878(guyane.dyn-o-saur.com/AAAA'): try
22-Jan-2007 10:40:22.415 fctx 0x8113878(guyane.dyn-o-saur.com/AAAA'): cancelqueries
22-Jan-2007 10:40:22.415 fctx 0x8113878(guyane.dyn-o-saur.com/AAAA'): getaddresses
22-Jan-2007 10:40:22.415 fctx 0x8113878(guyane.dyn-o-saur.com/AAAA'): query
22-Jan-2007 10:40:22.415 resquery 0x811a570 (fctx 0x8113878(guyane.dyn-o-saur.com/AAAA)): send
22-Jan-2007 10:40:22.416 resquery 0x811a570 (fctx 0x8113878(guyane.dyn-o-saur.com/AAAA)): sent
22-Jan-2007 10:40:22.416 resquery 0x8115608 (fctx 0x8119be0(guyane.dyn-o-saur.com/A)): senddone
22-Jan-2007 10:40:22.416 resquery 0x811a570 (fctx 0x8113878(guyane.dyn-o-saur.com/AAAA)): senddone
22-Jan-2007 10:40:22.416 zone copaya.yi.org/IN: sending notify to 80.10.246.5#53
...

22-Jan-2007 10:40:26.285 fctx 0x8126690(ns5.dyndns.org/A'): cancelqueries
22-Jan-2007 10:40:26.285 fctx 0x8126690(ns5.dyndns.org/A'): destroy
22-Jan-2007 10:40:26.285 fctx 0x8119be0(guyane.dyn-o-saur.com/A'): finddone
22-Jan-2007 10:40:26.285 fctx 0x8119be0(guyane.dyn-o-saur.com/A'): destroy
22-Jan-2007 10:40:26.285 dns_adb_destroyfind on find 0x80c0c08
22-Jan-2007 10:40:26.285 fctx 0x8113878(guyane.dyn-o-saur.com/AAAA'): finddone
22-Jan-2007 10:40:26.285 fctx 0x8113878(guyane.dyn-o-saur.com/AAAA'): destroy
22-Jan-2007 10:40:26.285 dns_adb_destroyfind on find 0x8116f90

... (gekürzt)...

22-Jan-2007 10:41:55.358 client 80.12.255.5#26357: UDP request      <-- (unklar woher das kommt)
22-Jan-2007 10:41:55.358 client 80.12.255.5#26357: using view '_default'
22-Jan-2007 10:41:55.358 client 80.12.255.5#26357: request is not signed
22-Jan-2007 10:41:55.358 client 80.12.255.5#26357: recursion available
22-Jan-2007 10:41:55.358 client 80.12.255.5#26357: query
22-Jan-2007 10:41:55.358 client 80.12.255.5#26357: query 'www.copaya.yi.org/A/IN' approved
22-Jan-2007 10:41:55.359 client 80.12.255.5#26357: send
22-Jan-2007 10:41:55.359 client 80.12.255.5#26357: sendto
22-Jan-2007 10:41:55.359 client 80.12.255.5#26357: senddone
22-Jan-2007 10:41:55.359 client 80.12.255.5#26357: next
22-Jan-2007 10:41:55.359 client 80.12.255.5#26357: endrequest
22-Jan-2007 10:41:55.359 client @0x80d7588: udprecv
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: UDP request
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: using view '_default'
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: request is not signed
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: recursion available
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: query
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: query 'copaya.yi.org/A/IN' approved
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: send
22-Jan-2007 10:41:55.678 client 80.12.255.5#26357: sendto
22-Jan-2007 10:41:55.679 client 80.12.255.5#26357: senddone
22-Jan-2007 10:41:55.679 client 80.12.255.5#26357: next
22-Jan-2007 10:41:55.679 client 80.12.255.5#26357: endrequest
22-Jan-2007 10:41:55.679 client @0x80d7588: udprecv
22-Jan-2007 10:42:22.410 expiring v4 for name 0x8124860
22-Jan-2007 10:42:22.410 killing name 0x8124860
22-Jan-2007 10:42:52.415 expiring v4 for name 0x8120138
22-Jan-2007 10:42:52.415 expiring v6 for name 0x8120138
22-Jan-2007 10:42:52.415 killing name 0x8120138
22-Jan-2007 10:43:22.420 expiring v4 for name 0x811fb78
22-Jan-2007 10:43:22.420 killing name 0x811fb78
22-Jan-2007 10:44:22.429 expiring v4 for name 0x8124bf8
22-Jan-2007 10:44:22.429 expiring v6 for name 0x8124bf8
22-Jan-2007 10:44:22.429 killing name 0x8124bf8             <----  ab hierverschwindet die korrekte IP
22-Jan-2007 10:50:52.490 expiring v4 for name 0x811fc30           und wird eine andere, frühere, verwendet
22-Jan-2007 10:50:52.490 killing name 0x811fc30
22-Jan-2007 10:50:52.490 expiring v4 for name 0x8118958
22-Jan-2007 10:50:52.490 killing name 0x8118958
22-Jan-2007 10:53:22.513 expiring v4 for name 0x8124580
22-Jan-2007 10:53:22.513 killing name 0x8124580
22-Jan-2007 10:53:22.513 expiring v4 for name 0x8124d68
22-Jan-2007 10:53:22.513 killing name 0x8124d68
22-Jan-2007 10:53:52.518 expiring v4 for name 0x8124b40
22-Jan-2007 10:53:52.518 killing name 0x8124b40


############### named.run   2. file     Diese Datei wird nicht bei jedem Start von named erzeugt sondern nur manchmal
22-Jan-2007 10:40:22.370 starting BIND 9.3.2-P2 -d 5
22-Jan-2007 10:40:22.371 found 1 CPU, using 1 worker thread
22-Jan-2007 10:40:22.380 loading configuration from '/etc/named.conf'
22-Jan-2007 10:40:22.381 /etc/named.conf:3: option 'multiple-cnames' is obsolete
22-Jan-2007 10:40:22.382 set maximum stack size to 4294967295: success
22-Jan-2007 10:40:22.382 set maximum data size to 4294967295: success
22-Jan-2007 10:40:22.382 set maximum core size to 4294967295: success
22-Jan-2007 10:40:22.382 set maximum open files to 1024: success
22-Jan-2007 10:40:22.383 listening on IPv4 interface lo, 127.0.0.1#53
22-Jan-2007 10:40:22.383 clientmgr @0x80a84b0: create
22-Jan-2007 10:40:22.384 clientmgr @0x80a84b0: createclients
22-Jan-2007 10:40:22.384 clientmgr @0x80a84b0: create new
22-Jan-2007 10:40:22.384 client @0x80d31c8: create
22-Jan-2007 10:40:22.384 binding TCP socket: address in use
22-Jan-2007 10:40:22.385 listening on IPv4 interface eth0, 192.168.0.1#53
22-Jan-2007 10:40:22.385 clientmgr @0x80d4f80: create
22-Jan-2007 10:40:22.385 clientmgr @0x80d4f80: createclients
22-Jan-2007 10:40:22.385 clientmgr @0x80d4f80: create new
22-Jan-2007 10:40:22.385 client @0x80d5398: create
22-Jan-2007 10:40:22.385 binding TCP socket: address in use
22-Jan-2007 10:40:22.385 listening on IPv4 interface ppp0, 193.250.208.78#53
22-Jan-2007 10:40:22.386 clientmgr @0x80d7170: create
22-Jan-2007 10:40:22.386 clientmgr @0x80d7170: createclients
22-Jan-2007 10:40:22.386 clientmgr @0x80d7170: create new
22-Jan-2007 10:40:22.386 client @0x80d7588: create
22-Jan-2007 10:40:22.386 binding TCP socket: address in use
22-Jan-2007 10:40:22.390 res 0x80de7e0: create
22-Jan-2007 10:40:22.391 cleaning interval for adb: 8 buckets every 30 seconds, 1009 buckets in system, 3600 cl.interval
22-Jan-2007 10:40:22.391 dns_requestmgr_create
22-Jan-2007 10:40:22.391 dns_requestmgr_create: 0x80e2108
22-Jan-2007 10:40:22.391 dns_requestmgr_whenshutdown
22-Jan-2007 10:40:22.392 res 0x80fb300: create
22-Jan-2007 10:40:22.393 cleaning interval for adb: 8 buckets every 30 seconds, 1009 buckets in system, 3600 cl.interval
22-Jan-2007 10:40:22.393 dns_requestmgr_create
22-Jan-2007 10:40:22.393 dns_requestmgr_create: 0x8112858
22-Jan-2007 10:40:22.393 dns_requestmgr_whenshutdown
22-Jan-2007 10:40:22.394 couldn't add command channel 127.0.0.1#953: address in use
22-Jan-2007 10:40:22.394 couldn't add command channel ::1#953: address in use
 
Last edited by a moderator:
Frage: Wie kann man sicher Prozesse named anhalten ?

Wie kann man sicher alle lfnd. Prozesse von named anhalten? Mit #killall -QUIT named oder #kill <proc-nr> geht es jedenfalls nicht sicher.


Sehr wahrscheinlich weiss ich jetzt den Grund für das komische Verhalten von named. Es laufen mehrere Versionen, außerdem mardns. Grund zumindest für das Erste ist, daß bereits laufende Versionen von beiden (u.a. die beim booten gestarteten) beim Neu-/Wiederstart (zBsp nach Abbruch der Verbindung) nicht anhalten.

Gut dass ich die Geduld verloren habe und named alle 20 sek. neu gestartet habe (s. vorigen post). Dadurch fiel mir auf, daß vorherige Prozesse nicht abgebrochen wurden und weiterlaufen, und dann nach Ablauf der TTL (oder des Doppelten davon) des zuletzt gestarteten Prozesses, deren alte Versionen der IP irgendwie wieder gültig werden - meist die zZt des bootens. Um das endgültig zu beheben, würde ich gerne wissen, wie man named sicher stoppen kann.
 
Danke, probier ich gleich mal aus und berichte als Nachtrag. Momentan ist named - was jetzt nur 1x läuft - nach Stunden noch OK, mit richtiger IP und das site noch funktionierend, sodaß das Problem wohl wirklich gefunden wurde.

Nachtrag: ... und auch die Lösung. Funktioniert :freu: ! /etc/rc.d/rc.bind enthält (abgesehen von der hier überflüssigen dauernden Abfrage ob named installiert ist, und einem vollkommen nutzlosen Programm #rndc) auch nur #killall named, #sleep 1, sodaß ich diese beiden direkt verwende. Wenn named mehrfach läuft, löscht #killall ... anscheinend nur die letzte Version, diese aber sicher, nicht nur zufällig wie #killall -QUIT ...

Das ist ein anderes Problem mit Linux: Scheinbar gibt es keine Anweisung, die Prozesse nach Namen sicher und unbedingt löscht; sporadisch funktioniert es, oder nicht. Das betrifft auch hier den Neustart zahlreicher Sachen nach Absturz von Fax-Modem/Leitung/kppp. ymessenger und amsn sind früher mit #killall -QUIT ... verschwunden; in der letzten Zeit nicht mehr und sind dann nach Neustart doppelt da, usw. Daß Programme Signale 'abfangen' können, mag zwar manchmal sinnvoll sein, aber es muß auch einen Befehl geben, um sie unbedingt loszuwerden, ob das Programm will oder nicht. Wenn man stirbt, wird man ja auch nicht um seine Meinung gefragt; wo kämen wir denn da hin, da wollte ja niemand sterben.


Noch eine andere Frage. Bei mir läuft auch httpd 11x . Scheinbar schadet das nicht, aber ist das normal ??
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top