Bind/Named Problem

    Hallo zusammen,


    Wir haben seit unserem Umzug auf einen anderen Server nun folgendes Problem, zum ersten wenn wir Subdomains anlegen werden diese nicht angelegt zum anderen beschwert sich ein Kunde das seit dem Umzug sein Backup Plugin im Word nicht mehr geht,ich weiß nicht ob es damit zusammen hängt.


    Error: Error #9038: Loopback test error: `cURL error 6: Could not resolve host: http://www.kundendomain.de; Name or service not known`. URL: `http://www.kundendomain.de/wp-admin/admin-ajax.php`. If you need to contact your web host, tell them that when PHP tries to connect back to the site at the URL `http://www.kundendomain.de/wp-admin/admin-ajax.php` via curl (or other fallback connection method built into WordPress) that it gets the error `cURL error 6: Could not resolve host: http://www.kundendomain.de; Name or service not known`. This means that WordPress' built-in simulated cron system cannot function properly, breaking some WordPress features & subsequently some plugins. There may be a problem with the server configuration (eg local DNS problems, mod_security, etc) preventing connections from working properly.


    Der Log sagt folgendes zu Hostdomain:


    Mar 18 18:19:21 srv1 named[16829]: dns_dnssec_findzonekeys2: error reading private key file XXX.net/NSEC3RSASHA1/843: file not found
    Mar 18 18:19:21 srv1 named[16829]: /var/named/dynamic/XXX.net.db.jnl: open: permission denied
    Mar 18 18:19:21 srv1 named[16829]: zone XXX.net/IN: zone_resigninc:dns_journal_open -> unexpected error



    Wir haben den DNSSEC bereits gelöscht und neu erstellt, wir haben die Domain deaktiviert und wieder aktiviert, wird haben im LC bei Bind9 das ganze neu gespeichert alles ohne Erfolg.


    Welches Problem hat der guten den da?

    drwxr-x---. 5 root named 4096 Mar 18 05:10 .
    drwxr-xr-x. 23 root root 4096 Mar 18 09:29 ..
    drwxrwx---. 2 named named 4096 Feb 15 14:16 data
    drwxrwx---. 2 named named 12288 Mar 18 18:14 dynamic
    -rw-r----- 1 root named 2076 Jan 28 2013 named.ca
    -rw-r----- 1 root named 152 Dec 15 2009 named.empty
    -rw-r----- 1 root named 152 Jun 21 2007 named.localhost
    -rw-r----- 1 root named 168 Dec 15 2009 named.loopback
    drwxrwx---. 2 named named 4096 Feb 15 14:16 slaves



    Edit:
    permission denied konnte ich beheben die datei muss "named" gehören und nicht root.


    Jetzt ist aber immer noch der Fehler:


    Mar 18 19:13:13 srv1 named[16829]: client 127.0.0.1#51572: request has invalid signature: TSIG LiveConfig: tsig verify failure (BADKEY)


    Edit2:
    Es ist auch nach wie vor so das wenn man eine Subdomain anlegt und diese aufruft ein DNS Error kommt und die Subdomain auch kein Traceroute drauf funktioniert


    Host testdomain.xxxx.net not found: 3(NXDOMAIN)

    Wie meinst du das auf beiden Servern?


    Der Key den im LC erstellt wird, hinterlegen wir auch bei InternetX ebenfalls schon 3 mal erneuert ohne Erfolg.


    Die keys.liveconfig auf dem Server bei uns ist leer...


    Fakt ist jedenfalls das Subdomains im Zonenfile nicht auftauchen wenn man Sie anlegt bzw. LiveConfig legt im bind keine zusätzlichen subdomains an oder Domain hauen direkt nen DNS Error raus, manche gehen ohne Probleme => Wie verhext


    Edit:
    Ich hab nun mal eine Domain aus LiveConfig gelöscht und neu angelegt, und was soll ich sagen? Danach ging alles wie es sein sollte.


    Woran kann das liegen? Ich hatte nun nicht vor 100 Domains zu löschen und neu anzulegen, besteht nicht die Möglichkeit Zonen und DNS Einträge komplett neu Generieren zu lassen irgendwie so das alle neu angelegt werden?

    Also bei uns gab es folgende Probleme (die DNS bei den Domains werden von LC verwaltet, nicht extern):
    - Die Keys zum AXFR Transport in keys.liveconfig haben nicht überein gestimmt, somit wurde auf den 2nd/3rd DNS keine Änderungen übernommen, Abhilfe schaffte hier mit Hilfe vom Support nur manuelles Eingreifen in die Datei
    - Die Domains wurden in zones.liveconfig nicht angelegt bzw auch hier mit falschen Keys, Abhilfe schafft hier die Domain in LC auf "externe DNS" zu stellen und anschließend wieder auf die eigene DNS Vorlage
    - Installiert wir zwar bind9 korrekt, aber meist fehlen die korrekten Berechtigungen der Verzeichnisse. Abhilfe schafft auch hier nur manuelles eingreifen (aufgetreten unter CentOS und Ubuntu, Debian setzen wir nicht ein derzeit).


    Wieso nun die Domain nicht korrekt angelegt wurde und auf "extern" und wieder zurück gestellt werden musste konnte mir auch niemand erzählen, gibt halt einfach keine Debug Möglichkeit (habe ich oft schon angemerkt).


    Wenn beim Registrar die LC DNS eingetragen wurden müssen die Keys übrigends nicht beim Registrar hinterlegt werden, das handeln die DNS unter sich aus.


    Weiterhin muss man eigentlich bei jedem installierten Paket, egal ob per liveconfig-meta oder manuell, doch stark eingreifen. Sei es nun um die Konfiguration abzusichern oder gar den wünschen entsprechend anpassen zu wollen.

    Wir nutzen ebenfalls CentOS 7 und werden von LC Verwaltet das Problem ist das es auf dem Server lief wo alles her gekommen ist und jetzt seit dem Umzug dieses Probleme auftreten und zwar bei allen 100 Domains.


    Das umstellen von Intern auf Extern bringt keinen Erfolg auch das deaktivieren und aktivieren bringt keinen Erfolg.


    Gestern habe ich dann mal eine Domain komplett gelöscht und wieder angelegt diese funktionierte dann auch wieder, das funktioniert aber nicht bei jeder Domain wie ich feststellen musste.


    Der DNSSEC Key gehört sicher auch zum Domain Provider? So steht es ja auch im Handbuch vom LiveConfig.


    Einen Kunden den wir haben berichtet das er seit der umstellen bei den E-Mails den Meldung erhält


    SMTP Protocol returned a permanent error 550 Sender domain must resolve.



    Das war vor dem Umzug auch nicht der fall, also irgendwas ist das kräftig schief gelaufen mit dem DNS und Bind und dem Umzug

    Der BIND macht jedenfalls unter CentOS in Kombination mit LC mächtig Probleme. Laut unserem Registrar muss der DNSSEC nur im DNS stehen, da wir diese per LC machen soll das ausreichen (haben wir aber noch nicht getestet).


    Einige Probleme lassen sich über das Bind Logging lösen, hier mal mein Setup:
    http://pastebin.com/raw/CxEP3PQH


    Darauf achten, dass der Ordner erstellt wird in /var/log und die Rechte named:named haben. Zusätzlich muss man manuell in /etc/named.conf noch "include "/etc/named.conf.local";" manuell eintragen.


    Teilweise gab es auch Probleme, dass Domains per "dig domain.tld @ns1.lcdns.de" aufgelöst wurde, aber scheinbar nicht veröffentlich. Am besten hier mal ggfl Firewall prüfen.


    Nen freeze, anschließende Serial Erhöhung und thaw einer Domain per "rndc" und nen anschließender reload half auch manchmal. Darauf achten, dass die Serial auch in LC eingetragen wird.


    Eine permanente Lösung ist das jedenfalls nicht, CentOS macht mit LC bei diversen anderen Tools auch Probleme. Wir werden wohl oder übel davon weg gehen müssen.

    Die Umstellung von Cent auf Debian soll wohl viel Arbeit sein? Wir wollten das auf Debian beim Umzug setzen allerdings meinte man da das es extrem viel Arbeit ist das alles anzupassen.


    Wie kann es den sein das LC die Subdomains einfach nicht anlegt in der Zone?

    Es ist von jeder Distri aus ein Wechsel extrem aufwendig da wohl überall die Pfade zBsp von FTP Server, DB, ... hinterlegt sind. Da diese sich meist unterscheiden, vor allem auch von Berechtigungen her... Da wir aber auch massiv betroffen sind werd ich nächste Woche nochmal nachhaken der Möglichkeiten.


    Entweder gibts ne Debugging Möglichkeit und entsprechende Fixes oder es muss eine Möglichkeit zum Wechsel der Distri her.


    Nach Anlegen einer Subdomain mal probiert diese per dig auf dem DNS selbst abzufragen? Vor allem wäre nützlich zu sehen was BIND macht (Logging).

    ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> testsun.xxx.de @localhost
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34841
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1


    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;testsun.xxx.de. IN A


    ;; AUTHORITY SECTION:
    xxx.de. 3600 IN SOA ns1.xxx.net. info.xxx.de. 2017031803 86400 10800 1209600 3600


    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Sun Mar 19 12:09:34 CET 2017
    ;; MSG SIZE rcvd: 125
    ---



    Ja also solche Probleme sind wirklich mist, vor allem wenn nichts geht und auch E-Mails teilweise nicht raus gehen und oder rein gehen.


    Was hat es mit dieser Meldung auf sich?
    SMTP Protocol returned a permanent error 550 Sender domain must resolve


    Grr und die Prew Version von Cent meldet 404 beim Download.... Bravo :D


    Wir glaube das u.a der 255 Zeichen TXT Fehler bei uns eingetroffen ist, was natürlich nicht erklärt warum der Kunde über seinen Externen Mail Server nun die SMTP Fehler erhält seit dem Umzug

    Kein MX Eintrag gesetzt oder nicht auflösbar bedeutet der Fehler.


    Einfach mal die Domain löschen und ohne TXT oder sonstige Spielerein testen. Bitte auch nicht auf @localhost testen sondern den öffentlichen DNS Server der auch beim Registrar hinterlegt ist.


    Ansonsten wie gesagt, BIND Logging machen.

    Doch MX ist gesetzt ein externer Mail Server des Kunden der auch bis Freitag ging bevor wir LC umgezogen haben, daran sollte es nicht liegen.


    Mails von GMX gehen z.b raus an den Kunden werden aber auch nicht zugestellt und es kommt kein Bounce zurück. Mail von unsere Domain ging bis gerade eben nicht raus da kam sofort Postfach nicht gefunden, der Fehler ist nun immerhin weg und laut Maillog gehen diese bei uns auch raus an deren Mailserver


    TXT Einträge gibt es nicht


    Vielleicht ist es auch nur ein DNS Cache Problem da wir 8.8.8.8 von Google nutzen und Google heute morgen erst die Hostname Adresse korrekt aufgelöst hat. Wir haben gestern nämlich noch mal den DNS umgestellt


    Das BIND Logging haben wir gemacht bzw. wir wissen das einige TXT Einträge Probleme machen vermutlich wegen der 255 Zeichen was im Lap ja behoben wurde, die wollten wir mal laden allerdings geht da gar nix 404 Fehler....

    Ohje die Google Public DNS in produktiven Systemen... Wir hatten damit mehr Probleme als das es was gebracht hatte. Am besten auf einen eigenen kleinen internen DNS Resolver setzen, da kann man wenigstens einfach Fehler finden die DNS bezogen sind (sofern es um die Auflösung oder Caching Problem geht).


    Die Frage ist ja nicht nur ob der MX gesetzt ist, sondern ob dieser auch nach Außen hin bekannt ist. Also nen DNS Resolver bauen, von den LC Servern diesen nutzen lassen. Und nun prüfen ob von überall her der MX Eintrag vorhanden und lesbar ist.

    Ja das sollten wir in Zukunft mal ändern den Google Resolver das war mal eine "Not" Lösung da beim letzten Server die Resolver der dort war irgendwie nicht richtig funktionierte.


    Rein aus neugier, welchen Nachteil haben den die Google Resolver?


    Inzwischen klappt der Empfangen und Versenden, es lag also wirklich am Cache.



    Subdomain anlegen unverändert evtl. bringt das Update auf die Preview Version Besserung wo der Fehler mit dem TXT Eintrag behoben ist.


    Ja wenn es irgendwann mal die Möglichkeit gibt, das Dist einfach zu wechseln, würden wir das auch Begrüßen, Cent ist da nicht wirklich mein Lieblings Dist inzwischen, sehr anfällig, auch bei migrieren auf neue Server gibt es immer wieder Probleme mit CentOS bei uns.

    Thema ist Erledigt


    Das Problem war eine leere key Datei die beim Umzug anscheint nicht richtig übernommen wurde, sowie einige TXT Einträge, das Problem konnte durch das einspielen der Beta behoben werden.


    Schade das das E-Mail Limit noch nicht funktioniert in der Beta :)


    Danke HBO für deine mithilfe :)

    Keine Ursache, aber das hat nichts mit einem Umzug zu tun. Bei einer frischen Installation hatten wir die Key Probleme auch, irgendwas wurde erstellt nur nicht das was sollte. Auch effektiv nur unter CentOS diese vielen Probleme, wieso auch immer.

    Ja das kann natürlich möglich sein, allerdings von 3 Umzügen gingen 3 auch schief, wo wir teilweise 7 Stunden und mehr für gebraucht haben weil irgendwas nicht funktionierte richtig.


    Obwohl ehrlich auch sagen muss, das ich solche Probleme mit Plesk noch nie hatte, da ging so ein Umzug wesentlich komfortabler von statten als mit LiveConfig (meine Erfahrung), und wenn ich die Möglichkeit hätte, noch mal zu wählen, würde ich LiveConfig nicht mehr nutzen wollen, wenn man mal sieht wie "komfortabel" andere Panel sind, vielleicht auch komplexer und tiefer im System und vielleicht auch anfälliger, aber dafür eine große Support Base auch, was ich recht wichtig finde.


    Bei einem wirklichen Problem ist man bei LiveConfig schnell an seine Grenzen. Support per E-Mail dauert viel zu lange. Und hier im Forum muss man wirklich Glück haben das mal jemand dazu was schreibt oder ne Lösung hat. Für etwas wo man Lizenz Gebühren zahlt, sollte der Support doch um einiges schneller reagieren, 2 oder 3 oder 7 Tagen und mehr ist da ein "no-go" für mich und verärgert mich auch wirklich, deswegen würde ich Persönlich unseren Kunden LiveConfig einfach nicht mehr empfehlen...


    Wie gesagt, danke noch mal für deine Hilfe und schönen Abend noch :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden