ubuntuusers.de

Hallo,

hexe immer noch mit meinem Ubuntu server rum und stehe auf dem Schlauch. Mein DNS will nicht und ich finde den (Denk)fehler nicht.

Ich glaube aber, ,dass mein Problem von einen grundsätzlichen Denkfehler mit Realm, Domäne, Search-Domain und den Zonen im DNS kommt.

Das wären meine Randdaten:

Server IP: 192.168.0.1

Server Name: Server01

Domäne: Frosch (Beispiel)

Internet-Domäne Frosch.org (Beispiel)

Gateway: 192.168.0.4 (Fritz Box)

Software:

Ubuntu 18.04 ohne GUI

Samba 4.7

bind9 4.7

isc-dhcp-server 4.3

Ich verwende kein resolve und keinen network manager

Dann wären meine Konfigurationen IMHO doch wie folgt:

Interfaces: (/etc/network/interfaces)

auto lo
iface lo inet loopback

#The primary Network Interface
auto eth0
iface eth0 inet static
        address 192.168.0.1/24
        gateway 192.168.0.4
        dns-nameservers 192.168.0.1

Die hosts (etc/hosts) wäre:

127.0.0.1       localhost
192.168.0.1     server01.frosch.lan server01

Und da ist meine erste Unsicherheit. Nimmt man als search domain dann so was wie Frosch.lan? Ich habe gelesen wenn man frosch.org nimmt würde das zu Problemen führen.

Dann wäre die resolv.conf (/etc/resolv.conf)

nameserver 192.168.0.1
search frosch.org
domain frosch

und die dhcpd.conf (/etc/dhcp/dhcpd.conf)

option domain-name "frosch";
authoritative;
default-lease-time 600;
max-lease-time 7200;

subnet 192.168.0.0 netmask 255.255.255.0 {
        range 192.168.0.20 192.168.0.40;
        option routers 192.168.0.4;
        option domain-name-servers 192.168.0.1;
        option domain-search "frosch.lan";
        ddns-domainname "frosch";
}

#Schlüssel für dynamisches DNS Bind Update

key ddns-key {
       algorithm HMAC-MD5;
       secret (Key Beispiel);
};

zone frosch.lan. {
       primary 192.168.0.1;
       key ddns-key;
}

zone 0.168.192.in-addr.arpa. {
       primary 192.168.0.1;
       key ddns-key;
}

Der DHCP läuft sauber, also scheint das nicht ganz falsch zu sein.

die DNS Konfiguration wäre dann wie folgt und damit klappt es überhaupt nicht, aber ich finde den Fehler nicht.

/etc/bind/named.conf.options

options {
        directory "/var/cache/bind";
        listen-on { any; };
        allow-recursion {127.0.0.1; ::1; };
 
        forwarders {
                8.8.8.8;
                #192.168.0.4;
        };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

/etc/bind/named.conf.local

key "ddns-key" {
       algorithm hmac-md5;
       secret "(Key Beispiel)";
};

zone "frosch.lan" {
        type master;
        file "/var/cache/bind/db.frosch.lan";
        allow-update { key "ddns-key" ; };
        allow-query {
                192.168.0.0/24;
                };
};

zone "0.168.192.in-addr.arpa"{
        type master;
        file "/var/cache/bind/db.0.168.192";
        allow-update { key "ddns-key" ; };
        allow-query {
                192.168.0.0/24;
                };
};

und die Zonen:

/var/cache/bind/db.frosch.lan

;; db.frosch.lan
;;
;; BIND forward data file for rfc1918 zone
;;
;;
$ORIGIN frosch.lan.
$TTL    86400
@        IN      SOA     server01.frosch.lan. mail.frosch.org. (
                     2019082201         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400         ; Negative Cache TTL
                        )
             IN      NS      server01.frosch.lan.
@            IN      A       192.168.0.1
server01     IN      A       192.168.0.1

localhost    IN      A       127.0.0.1
ro-pc        IN      A       192.168.0.27
RaspberryPi  IN      A       192.168.0.11

und die reverce Zone: /var/cache/bind/db.0.168.192

$ORIGIN .
$TTL 86400      ; 1 day
0.168.192.in-addr.arpa  IN SOA  server01.frosch.lan. mail.frosch.org. (
                                201908233  ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                2419200    ; expire (4 weeks)
                                172800     ; minimum (2 days)
                                )
                        NS      server01.frosch.lan.
$ORIGIN 0.0.168.192.in-addr.arpa.
1                       PTR     server01.frosch.lan.
$TTL 300        ; 5 minutes
25                      PTR     MANUELA-PC.frosch.lan.
$ORIGIN 0.168.192.in-addr.arpa.
25                      PTR     MANUELA-PC.frosch.lan.

in Samba /etc/samba/smb.conf

# Global parameters
[global]
        workgroup = FROSCH
        wins server = 192.168.0.1
        netbios name = SERVER01
        realm = FROSCH.LAN
        server role = active directory domain controller
        server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
        winbind use default domain = false
        winbind offline logon = false
        winbind separator = +

[netlogon]
        path = /var/lib/samba/sysvol/frosch.local/scripts
        read only = No

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

[Lan_t]
        comment = Lan_t
        path = /mnt/Lan_t
        read only = No
        inherit permissions = Yes
        inherit acls = Yes
        inherit owner = Yes
        guest ok = No

Wäre total dankbar, wenn da mal jemand drüber schauen könnte, vor allem unter dem Gesichtpunkt: Stimmen die Domain, Search Domain, Realm Einträge?

Wie gesagt, DHCP scheint zu laufen. DNS startet ohne Fehler, löst aber nix gescheit auf. Momentan weder Adressen im Netz noch Internet Und Samba will nicht mit "Fehler DNS".

Vielen Dank im Voraus

Ralf

Danke für die umfangreiche Hilfe, habe es selbst gelöst.. Thread kann geschlossen werden.

Für Leute die das selbe Problem haben und sich hier vor Hilfangeboten auch nicht retten können. Ab der Version 9.4.1 hat sich das allow query Verhalten beim Bind9 geändert.

https://kb.isc.org/docs/aa-00269

Vorher war erlaubt was nicht explizit verboten ist, darauf beziehen sich die ganzen Beispiele im Netz. Nun muss man Querys explizit erlauben. Daran bin ich gescheitert.

nonickatall schrieb:

Danke für die umfangreiche Hilfe, habe es selbst gelöst.. Thread kann geschlossen werden.

Das freut mich zu hören! Threads werden in der Regel nicht geschlossen. Du kannst ihn aber als gelöst markieren, was für zukünftige Hilfesuchende sogar nicht besser ist. 😉

Für Leute die das selbe Problem haben und sich hier vor Hilfangeboten auch nicht retten können.

Das ist bestimmt als spaßiger Seitenhieb gedacht, allerdings ist das ein direkter Schlag ins Gesicht aller Freiwilliger, die hier in ihrer Freizeit unentgeltlich ihre Kenntnisse und Erfahrungen einbringen. Das bedeutet unter anderem, dass jemand für dein spezielles Problem a) den Beitrag wahrnehmen, b) die passenden Kenntnisse zur Beantwortung haben und c) die Zeit für das Schreiben einer Antwort haben muss. Wenn du nicht schnell genug Antworten erhältst oder sie dir von der Qualität her nicht ausreichen, gibt es bestimmt den einen oder anderen Bezahldienst, der Support leistet - zwar nicht immer besser, aber dafür eben wesentlich teurer.

Ab der Version 9.4.1 hat sich das allow query Verhalten beim Bind9 geändert.

https://kb.isc.org/docs/aa-00269

Vorher war erlaubt was nicht explizit verboten ist, darauf beziehen sich die ganzen Beispiele im Netz. Nun muss man Querys explizit erlauben. Daran bin ich gescheitert.

An dieser Stelle bedanke ich mich im Namen der Gemeinschaft, dass du nicht nur dein Problem für gelöst erklärt hast, sondern auch noch die Ursache aufschreibst.

Nachfolgend noch eine Antworte zu einer Frage, die du am Rande in deinen ursprünglichen Beitrag eingebracht hast.

Und da ist meine erste Unsicherheit. Nimmt man als search domain dann so was wie Frosch.lan? Ich habe gelesen wenn man frosch.org nimmt würde das zu Problemen führen.

Domain und Search Domain sind zwei Parameter, die verwendet werden, wenn du einen einfachen Hostnamen ohne Domain-Anteil für eine Namenssuche angibst. Nehmen wir an, ein Client mit Domain kroete.net und Search Domain frosch.lan sowie olm.com würde einfach nur nach server01 suchen. Zuerst fragt er seinen zuständigen DNS-Server, ob er ihm die IP von server01.kroete.net geben kann. Geht nicht, weil nicht vorhanden. Danach fragt der Client den DNS-Server, wie es denn mit server01.frosch.lan aussieht, erhält eine positive Antwort und fragt nicht auch noch nach dem Olm. 😉

Diese Suchdomänen sind also bis zu einem gewissen Grad ein nützliches Werkzeug, bieten aber auch viel Potential für Durcheinander. Einerseits kann ich damit gleiche Servernamen in unterschiedlichen Umgebungen benutzen (z.B. je eine Domain für Test, Qualitätssicherung, Prod in der Softwareentwicklung), was mir irgendwie nützlich erscheint. Andererseits kann man damit natürlich auch gegen die Wand rennen, weil man dann immer z.B. server01 anruft und vielleicht gerade nicht weiß, dass man fleißig Datenbanken in Prod wegwirft, weil jemand aus Bequemlichkeit immer dieselben Passwörter verwendet. ☺