öffentliche vs. private Zone in eigenem DNS

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

öffentliche vs. private Zone in eigenem DNS

Beitrag von scientific » 09.10.2018 09:52:33

Hi Leute!

Ich hab ein VPN mit eigenem DNS. Bei Hetzner sind der DNS, Mail, LDAP und openVPN-Server .
Daheim hab ich eine Fritzbox (die leider kein openVPN kann...) und einen kleinen Einplatinen-Rechner, der als File/Backup/Print-Server dient bzw. in Zukunft dienen soll.

Die Fritz-Box hat eine eigene lokale Domain "fritz.box" und die Rechner im LAN sind über die Fritzbox einfach per HOSTNAME.fritz.box erreichbar. (also auch der Drucker und der TV, welche beide auch kein openVPN können).

Ich möchte gerne diese Namensauflösung beibehalten, und dennoch als einzigen Nameserver im VPN den vom VPN nutzen.

Meiner Meinung nach müsste ja eine Forward-Zone in bind9 reichen.

also

Code: Alles auswählen

zone "fritz.box" in {
    type forward;
    forwarders {
        192.168.178.1;
    };
};
Mein VPN ist so eingerichtet, dass alle Rechner im VPN (10.0.100.0/24) auch alle Rechner aus dem Netz 192.168.178.0/24 erreichen können.
Auf meinem Laptop, mit dem ich unterwegs bin führt ein

Code: Alles auswählen

dig printer.fritz.box @192.168.178.1
zur korrekten IP-Adresse des Druckers.
in meinem Nameserver, der die IP 10.0.100.1 hat, hab ich in Bind obigen Forward-Zone-Eintrag gemacht und bind reloaded.

Code: Alles auswählen

dig printer.fritz.box @10.0.100.1
gibt mir kein Ergebnis.
Ein Blick in den Cache von bind9 nach dieser Abfrage zeigt, dass es eine offizielle TLD box. gibt, und die dazugehörigen Einträge stehen VOR den Einträgen für fritz.box. im Cache-File

Code: Alles auswählen

rndc dumpdb -cache
füllt /var/named/data/cache_dump.db und darin kann man dann greppen.

Ich verstehe das nicht ganz. Was mach ich falsch? Wie mach ich das richtig?

Kurz zusammengefasst:
  • Wenn ich im LAN bin (ohne VPN), dann erreiche ich meinen Drucker mit printer.fritz.box, da die Fritzbox diese Domain ausliefert und den Host darin automatisch registriert.
  • Bin ich unterwegs, möchte ich über mein VPN ebenfalls die lokale Domain fritz.box mit den korrekten IP-Adressen (also jene aus dem Netz der Fritz-Box) ausgeliefert bekommen. Das VPN ermöglicht den Zugriff per IP-Adressen auf die Rechner in diesem Netz.
  • Bin ich unterwegs und hab das VPN nicht eingeschaltet, soll der vom Provider ausgelieferte DNS zum Zug kommen.
Vielen Dank für Ideen!

scientific

[EDIT]
Lösung ist hier: viewtopic.php?f=30&t=170978&p=1185662#p1185780
Zuletzt geändert von scientific am 16.10.2018 09:31:52, insgesamt 4-mal geändert.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von mat6937 » 09.10.2018 10:06:48

scientific hat geschrieben: ↑ zum Beitrag ↑
09.10.2018 09:52:33
Auf meinem Laptop, mit dem ich unterwegs bin führt ein

Code: Alles auswählen

dig printer.fritz.box @192.168.178.1
zur korrekten IP-Adresse des Druckers.

[*]Bin ich unterwegs, möchte ich über mein VPN ebenfalls die lokale Domain fritz.box mit den korrekten IP-Adressen (also jene aus dem Netz der Fritz-Box) ausgeliefert bekommen. Das VPN ermöglicht den Zugriff per IP-Adressen auf die Rechner in diesem Netz.
Du könntest doch von unterwegs (wenn Du im VPN bist) die 192.168.178.1 (die ja im VPN erreichbar ist) für die lokale Namensauflösung benutzen.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von scientific » 09.10.2018 18:26:30

Das beantwortet meine Frage nicht, und ist nicht praktikabel.

Ich verbinde mich von unterwegs mit dem VPN, bekomme damit den Nameserverim VPN. Und dieser sollte dann per forwarding die Domain fritz.box mit dem Netzwerk daheim auflösen...

Der eingetragene Nameserver löst ja die anderen Server im VPN auch auf, was die Fritzbox daheim nicht tut, da diese ja kein openVPN kann... damit wären dann LDAP, Mail und andere Services, deretwegen ich ja das VPN überhaupt eingerichtet habe, nicht mehr erreichbar...
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

BenutzerGa4gooPh

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von BenutzerGa4gooPh » 09.10.2018 19:24:43

Split DNS? https://www.medic-daniel.de/microsoft-w ... oder-segen
(Im Link für Webserver/DMZ erläutert.)
Mit 2 DNS-Servern und einem "richtigen" (Debian-) Router könnte man auch was mit Policy Based Routing (abhängig von Quell-IP-Adresse/"Standort" eines DNS-Clients) machen. Aber so richtig verstehe ich dein Netz nicht, vielleicht hilft es trotzdem. :wink:

Vgl. a. https://en.wikipedia.org/wiki/Split-horizon_DNS
http://jensd.be/160/linux/split-horizon ... -with-bind
https://websistent.com/configure-bind-dns-split-view/
Zuletzt geändert von BenutzerGa4gooPh am 09.10.2018 19:51:31, insgesamt 6-mal geändert.

Benutzeravatar
habakug
Moderator
Beiträge: 4313
Registriert: 23.10.2004 13:08:41
Lizenz eigener Beiträge: MIT Lizenz

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von habakug » 09.10.2018 19:35:00

Hallo,

das geht auch z.B. mit Debiandnsmasq und einer /etc/hosts.

Gruss, habakug

[1] http://shorewall.org/SplitDNS.html
( # = root | $ = user | !! = mod ) (Vor der PN) (Debianforum-Wiki) (NoPaste)

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von mat6937 » 10.10.2018 09:51:06

scientific hat geschrieben: ↑ zum Beitrag ↑
09.10.2018 18:26:30
... ist nicht praktikabel.

Ich verbinde mich von unterwegs mit dem VPN, bekomme damit den Nameserverim VPN. Und dieser sollte dann per forwarding die Domain fritz.box mit dem Netzwerk daheim auflösen...

Der eingetragene Nameserver löst ja die anderen Server im VPN auch auf, was die Fritzbox daheim nicht tut, da diese ja kein openVPN kann... ...
Die FritzBox muss kein OpenVPN können, die FritzBox muss nur per VPN erreichbar sein. Und das sollte sie z. Zt. doch sein, wenn deine anderen <*>.fritz.box-Geräte von unterwegs via VPN erreichbar sein sollen.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von scientific » 10.10.2018 10:25:23

Ich hab hier mal versucht, eine Übersicht über mein Netzwerk zu machen.

1874

Im Rechnenzentrum ist der Host mit der IP 10.0.100.1 der openVPN-Server.
Alle Rechner mit einer IP 10.0.100.* sind im VPN.
Die Hosts aus dem Rechenzentrum haben auch alle eine public IP, die ich jetzt nicht aufgeschrieben habe.

Das Problem ist jetzt, wenn ich von lap1, lap2 oder rock64 die fritz.box oder den print.fritz.box per Namensauflösung erreichen möchte, geht das nicht, solange das VPN für das jeweilige Gerät aktiv ist, da dann als DNS 10.0.100.1 und 10.0.100.2 in der /etc/resolv.conf eingetragen ist. Es müsste also ns1 und ns2 auch die Domain fritz.box auflösen können.

Ich kann durch meine vpn-Routen von jedem Rechner aus dem VPN über die IP-Adresse 192.168.178.*-Adresse auch jeden Rechner in Home erreichen, jedoch nicht über den Namen.

Also von LAP2, mit dem ich unterwegs bin, kann ich die Adresse "http://192.168.178.50" öffnen und bin auf der Management-Seite des Druckers, obwohl ich mit LAP2 im Zug unterwegs bin.

Ich hab openVPN so eingerichtet, dass die IP-Adressen des VPN, welche openVPN dynamisch vergibt, wenn sich ein Rechner anmeldet, per nsupdate dem Nameserver ns1 mitteilt, und dieser transferiert diese mittels transfer (master->slave) auf ns2. (ns2 ist der eigentliche DNS, den ich im Endeffekt im VPN als ersten publiziere)

Wenn ich die Konfiguration von bind9 richtig verstanden habe, dann müsste ich in named.conf.local "nur" eine Zone hinzufügen, die forward only auf die Fritzbox macht.

Daher habe ich in dieser Datei folgendes eingefügt:

Code: Alles auswählen

zone "fritz.box" in {
    type forward;
    forward only;
    forwarders {
        192.168.178.1;
    };
};
Um zu demonstrieren:
Ich bin jetzt auf ns1.vpn bzw. vpn.vpn (das ist ein und der selbe Host, auf dem laufen bind9 und openvpn)

Code: Alles auswählen

( 0 ✓) (SCREEN) root@vpn (10:14)
/etc/bind: (vpn.vpn) # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
....
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.0.100.1/24 brd 10.0.100.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::cfa5:96ac:2ef9:7231/64 scope link flags 800 
       valid_lft forever preferred_lft forever
Ich versuche eine Namensauflösung von rock64.vpn

Code: Alles auswählen

( 0 ✓) (SCREEN) root@vpn (10:15)
/etc/bind: (vpn.vpn) # dig rock64.vpn @10.0.100.1

; <<>> DiG 9.10.3-P4-Debian <<>> rock64.vpn @10.0.100.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33521
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rock64.vpn.                     IN      A

;; ANSWER SECTION:
rock64.vpn.              300     IN      A       10.0.100.6

;; AUTHORITY SECTION:
vpn.                    259200  IN      NS      ns2.vpn.
vpn.                    259200  IN      NS      ns1.vpn.

;; ADDITIONAL SECTION:
ns1.vpn.                259200  IN      A       10.0.100.1
ns2.vpn.                300     IN      A       10.0.100.2

;; Query time: 1 msec
;; SERVER: 10.0.100.1#53(10.0.100.1)
;; WHEN: Wed Oct 10 10:17:15 CEST 2018
;; MSG SIZE  rcvd: 122
Passt. Klappt gut, ich krieg die korrekte IP aus dem VPN.

Ich versuche eine Namensauflösung von rock64.fritz.box über den vpn.vpn (10.0.100.1)

Code: Alles auswählen

( 0 ✓) (SCREEN) root@vpn (10:14)
/etc/bind: (vpn.vpn) # dig rock64.fritz.box @10.0.100.1

; <<>> DiG 9.10.3-P4-Debian <<>> rock64.fritz.box @10.0.100.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24928
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rock64.fritz.box.               IN      A

;; Query time: 24 msec
;; SERVER: 10.0.100.1#53(10.0.100.1)
;; WHEN: Wed Oct 10 10:14:10 CEST 2018
;; MSG SIZE  rcvd: 44
Fehlgeschlagen. Obwohl ich den Zoneneintrag wie oben in der bind9-Konfig habe.

Ich versuche rock64.fritz.box dann mit der Fritzbox aufzulösen:

Code: Alles auswählen

( 0 ✓) (SCREEN) root@vpn (10:14)
/etc/bind: (vpn.vpn) # dig rock64.fritz.box @192.168.178.1

; <<>> DiG 9.10.3-P4-Debian <<>> rock64.fritz.box @192.168.178.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33459
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;rock64.fritz.box.               IN      A

;; ANSWER SECTION:
rock64.fritz.box.        9       IN      A       192.168.178.25

;; AUTHORITY SECTION:
rock64.fritz.box.        9       IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.178.1

;; Query time: 20 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Wed Oct 10 10:14:21 CEST 2018
;; MSG SIZE  rcvd: 79
Klappt. Ich krieg von rock64.fritz.box die richtige IP-Adresse (192.168.178.25) Die Fritzbox ist also vom Nameserver aus zu erreichen und eine Namensauflösung möglich.

Warum also klappt dann das Forwarding nicht?

Ich hoffe, es ist jetzt etwas klarer, was mein Anliegen ist...

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von scientific » 10.10.2018 10:53:47

Im Journal finde ich folgende Einträge:

Code: Alles auswählen

Oct 10 10:41:13 vpn.XXX named[2056]: zone fritz.box/IN: loaded serial 1539160816
...
Oct 10 10:42:43 vpn.XXX named[2056]: not found resolving 'rock64.fritz.box/A/IN': 213.133.100.100#53
Oct 10 10:42:43 vpn.XXX named[2056]: not found resolving 'rock64.fritz.box/A/IN': 213.133.98.98#53
Oct 10 10:42:43 vpn.XXX named[2056]: not found resolving 'rock64.fritz.box/A/IN': 213.133.99.99#53
Oct 10 10:42:43 vpn.XXX named[2056]: not found resolving 'rock64.fritz.box/A/IN': 208.67.222.222#53
Oct 10 10:42:43 vpn.XXX named[2056]: not found resolving 'rock64.fritz.box/A/IN': 192.168.178.1#53

XXX ist die FQDN meines Nameservers.

Warum schlägt bind zuerst in den Nameservern aus der Forwarders-Option aus named.conf.options nach?

Code: Alles auswählen

        forwarders {

                208.67.222.222;
                213.133.98.98;
                213.133.99.99;
                213.133.100.100;
        };
Und das noch in umgekehrter Reihenfolge?
Und warum funktioniert die Namensauflösung afu 192.168.178.1 nicht, wo sie aber mit dig auf der Commandline auf diesem Rechner funktioniert?
Zuletzt geändert von scientific am 10.10.2018 11:47:44, insgesamt 1-mal geändert.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von mat6937 » 10.10.2018 11:10:58

scientific hat geschrieben: ↑ zum Beitrag ↑
10.10.2018 10:53:47
Warum schlägt bind zuerst in den Nameservern aus der Forwarders-Option aus named.conf.options nach?
Evtl. mal ohne "in" versuchen:

Code: Alles auswählen

zone "fritz.box" in {
    type forward;
    forward only;
    forwarders {
        192.168.178.1;
    };
};

Code: Alles auswählen

zone "fritz.box" {
    type forward;
    forward only;
    forwarders {
        192.168.178.1;
    };
};

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von scientific » 10.10.2018 11:46:16

Eine weitere Erkenntnis:

Da ich auf der Fritzbox keinen Zugriff auf die Logs habe, hab ich auf dem Nameserver mittels tcpdump mal nachgeschaut, was da so an Datenverkehr über tun0 (also das Device für das VPN) anfällt:

Code: Alles auswählen

/etc/bind: (vpn.vpn) # tcpdump -i tun0 port 53
...
11:24:11.829474 IP 10.0.100.1.54323 > 192.168.178.1.domain: 22739 A? rock64.fritz.box. (33)
11:24:11.851092 IP 192.168.178.1.domain > 10.0.100.1.54323: 22739* 1/1/1 A 192.168.178.25 (79)
Das passiert, wenn ich folgenden Befehl auf dem selben Host absetze:

Code: Alles auswählen

( 0 ✓) (SCREEN) root@vpn (11:23)
~: # dig rock64.fritz.box @127.0.0.1

; <<>> DiG 9.10.3-P4-Debian <<>> rock64.fritz.box @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52642
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rock64.fritz.box.               IN      A

;; Query time: 187 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct 10 11:24:11 CEST 2018
;; MSG SIZE  rcvd: 44
Und das auf ens3

Code: Alles auswählen

/etc/bind: (vpn.vpn) # tcpdump -i ens3 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
11:27:23.657273 IP static.178.200.69.159.clients.your-server.de.34385 > ns3-coloc.hetzner.com.domain: 31963+% [1au] A? rock64.fritz.box. (44)
11:27:23.657591 IP ns3-coloc.hetzner.com.domain > static.178.200.69.159.clients.your-server.de.34385: 31963 NXDomain 0/8/1 (1139)
11:27:23.658034 IP static.178.200.69.159.clients.your-server.de.55651 > ns2-coloc.hetzner.net.domain: 50805+ PTR? 100.100.133.213.in-addr.arpa. (46)
11:27:23.658285 IP ns2-coloc.hetzner.net.domain > static.178.200.69.159.clients.your-server.de.55651: 50805 1/2/0 PTR ns3-coloc.hetzner.com. (140)
11:27:23.658508 IP static.178.200.69.159.clients.your-server.de.60001 > ns2-coloc.hetzner.net.domain: 45200+ PTR? 178.200.69.159.in-addr.arpa. (45)
11:27:23.659875 IP static.178.200.69.159.clients.your-server.de.49005 > ns1-coloc.hetzner.de.domain: 24999+% [1au] A? rock64.fritz.box. (44)
11:27:23.660087 IP static.178.200.69.159.clients.your-server.de.46786 > ns3-coloc.hetzner.com.domain: 12689+% [1au] AAAA? fritz.box. (38)
11:27:23.662449 IP static.178.200.69.159.clients.your-server.de.48757 > ns2-coloc.hetzner.net.domain: 24586+ PTR? 99.99.133.213.in-addr.arpa. (44)
11:27:23.662643 IP ns2-coloc.hetzner.net.domain > static.178.200.69.159.clients.your-server.de.48757: 24586 1/2/0 PTR ns2-coloc.hetzner.net. (138)
11:27:23.663394 IP static.178.200.69.159.clients.your-server.de.57927 > ns2-coloc.hetzner.net.domain: 52989+ PTR? 98.98.133.213.in-addr.arpa. (44)
11:27:23.663579 IP ns2-coloc.hetzner.net.domain > static.178.200.69.159.clients.your-server.de.57927: 52989 1/2/0 PTR ns1-coloc.hetzner.de. (135)
11:27:23.663595 IP static.178.200.69.159.clients.your-server.de.52047 > resolver1.opendns.com.domain: 59386+% [1au] A? rock64.fritz.box. (44)
11:27:23.664725 IP static.178.200.69.159.clients.your-server.de.59978 > ns2-coloc.hetzner.net.domain: 58938+ PTR? 222.222.67.208.in-addr.arpa. (45)
11:27:23.664932 IP ns2-coloc.hetzner.net.domain > static.178.200.69.159.clients.your-server.de.59978: 58938 1/3/0 PTR resolver1.opendns.com. (140)
11:27:23.785043 IP resolver1.opendns.com.domain > static.178.200.69.159.clients.your-server.de.52047: 59386 NXDomain 0/1/1 (109)
Es kommt also von der Fritzbox die richtige IP-Adresse zurück, kommt aber nie bei bind9 an.

Firewall?

Code: Alles auswählen

( 0 ✓) (SCREEN) root@vpn (11:28)
~: # iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination    
negativ
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

[SOLVED] Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von scientific » 10.10.2018 12:02:21

So noch eine Korrektur.

Ich bin schon vor einigen Versuchen von einer "Forward-zone" auf eine "Stub-Zone" umgestiegen. Die letzten Ergebnisse von tcpdump usw. stammen von den Versuchen mit der Stub-Zone.

Der originale Eintrag lautete bei mir so:

Code: Alles auswählen

zone "fritz.box" {
    type stub;
    masters { 192.168.178.1; };
    file "/etc/bind/stub-zones/db.stub.fritz.box";
};
Dann fand ich diesen Beitrag https://lists.isc.org/pipermail/bind-us ... 83244.html und den Hinweis, dass forwarding bei Stub-zonen nicht so günstig sein kann und änderte meinen Eintrag auf diesen hier ab:

Code: Alles auswählen

zone "fritz.box" {
    type stub;
    masters { 192.168.178.1; };
    file "/etc/bind/stub-zones/db.stub.fritz.box";
    forwarders { };
};

Code: Alles auswählen

rndc reload
und auf ns2.vpn das selbe ausgeführt, und schon kann ich mit meinem Browser im VPN auf den Drucker im lokalen Netz daheim mit dem FQDN http://print.vpn und die Fritzbox erreiche ich mit http://fritz.box.

Was mir aber nicht klar ist, warum bind9 den aufgelösten Hostnamen mit IP nicht übernommen hat, der mit tcpdump sichtbar wurde... erst als ich für die Stubzone das Forwarding abgedreht habe, geht es...

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von scientific » 16.10.2018 09:31:04

Doch nicht gelöst... Wieder zurück an den Start...

Ich sitze hier am Rechner 10.0.100.9 und bin über Mobilfunk mit dem Internet und mittels VPN mit meinem VPN verbunden (So wie LAP2.vpn in meiner obigen Grafik)

Und ich versuche rock64.fritz.box über 10.0.100.1 aufzulösen.
rock64.fritz.box dient dabei als VPN-Knoten in das Netz 192.168.178.0/24, wo 192.168.178.1 der Router ist.

Von meinem Rechner 10.0.100.9 ist sowohl 192.168.178.1 als auch 192.168.178.25 pingbar.

Auf allen beteiligten Hosts (10.0.100.9, 10.0.100.1, 192.168.178.25 ident mit 10.0.100.6 ist die Firewall deaktiviert.

Auf 10.0.100.1 sniffe ich mit tcpdump den Netzwerkverkehr auf tun0 auf Port 53 und bekomme dieses Ergebnis:

Code: Alles auswählen

09:15:10.097816 IP 10.0.100.9.46698 > 10.0.100.1.domain: 29534+ [1au] A? rock64.fritz.box. (56)
09:15:10.099019 IP 10.0.100.1.32786 > 192.168.178.1.domain: 34482 A? rock64.fritz.box. (33)
09:15:10.120211 IP 192.168.178.1.domain > 10.0.100.1.32786: 34482* 1/1/1 A 192.168.178.25 (79)
09:15:10.121181 IP 10.0.100.1.49008 > 192.168.178.1.domain: 34615 AAAA? fritz.box. (27)
09:15:10.121218 IP 10.0.100.1.domain > 10.0.100.9.46698: 29534 ServFail 0/0/1 (44)
09:15:10.143379 IP 192.168.178.1.domain > 10.0.100.1.49008: 34615* 0/1/0 (69)
Die Abfrage auf 10.0.100.9 dazu:

Code: Alles auswählen

$ dig virgo.fritz.box @10.0.100.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-10.P2.fc28 <<>> virgo.fritz.box @10.0.100.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52952
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;virgo.fritz.box.		IN	A

;; Query time: 105 msec
;; SERVER: 10.0.100.1#53(10.0.100.1)
;; WHEN: Di Okt 16 09:21:15 CEST 2018
;; MSG SIZE  rcvd: 44
Auf dem VPN-Server (10.0.100.1) schauen Abfragen mit dig so aus:

Code: Alles auswählen

( 0 ✓) (SCREEN) ansible@vpn (08:25)
~/ansible: (master) $ dig virgo.fritz.box @10.0.100.1

; <<>> DiG 9.10.3-P4-Debian <<>> virgo.fritz.box @10.0.100.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8352
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;virgo.fritz.box.               IN      A

;; Query time: 26 msec
;; SERVER: 10.0.100.1#53(10.0.100.1)
;; WHEN: Tue Oct 16 09:25:05 CEST 2018
;; MSG SIZE  rcvd: 44

( 0 ✓) (SCREEN) ansible@vpn (09:25)
~/ansible: (master) $ dig virgo.fritz.box @192.168.178.1

; <<>> DiG 9.10.3-P4-Debian <<>> virgo.fritz.box @192.168.178.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5626
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;virgo.fritz.box.               IN      A

;; ANSWER SECTION:
virgo.fritz.box.        9       IN      A       192.168.178.25

;; AUTHORITY SECTION:
virgo.fritz.box.        9       IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.178.1

;; Query time: 21 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Tue Oct 16 09:25:12 CEST 2018
;; MSG SIZE  rcvd: 79
Das heißt, ich kann von 10.0.100.1 eine Namensauflösung auf 192.168.178.1 manuell machen. tcpdump zeigt auch, dass bei einer Namensauflösung über 10.0.100.1 (also den lokal laufenden bind9) die korrekte IP-Adresse übertragen wird, aber bind9 erhält die Antwort nicht/oder gibt sie nicht weiter...

Das Zonefile sieht so aus:

/etc/bind9/named.conf.options:

Code: Alles auswählen

acl trusted {
    127.0.0.1;
    10.0.100.0/8;
    192.168.178.0/24;
};

acl slaves {
    10.0.100.2;
    159.69.146.155;
};

options {
        directory "/var/cache/bind";

        recursion yes;
        //additional-from-auth yes;
        //additional-from-cache yes;
        allow-recursion { trusted; };
        listen-on { 127.0.0.1; 10.0.100.1; };
        notify yes;
        #also-notify { slaves; };
        #allow-transfer { slaves; };
        #allow-update { trusted; };

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable 
        // nameservers, you probably want to use them as forwarders.  
        // Uncomment the following block, and insert the addresses replacing 
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        //forward only;
        forwarders {

                208.67.222.222;
                213.133.98.98;
                213.133.99.99;
                213.133.100.100;
        };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};
und /etc/bind9/named.conf.local

Code: Alles auswählen

zone "vpn" {
    type master;
    file "/etc/bind/vpn/db.vpn";
    allow-update { trusted; };
    allow-transfer { slaves; };
    #forwarders {};
};

zone "example.at" in {
    type master;
    file "/etc/bind/vpn/db.example.at";
    allow-update { trusted; };
    allow-transfer { slaves; };
};

zone "fritz.box" {
    type stub;
    masters { 192.168.178.1; };
    file "/etc/bind/stub-zones/db.stub.fritz.box";
    forwarders { };
};

zone "100.0.10.in-addr.arpa" {
    type master;
    file "/etc/bind/db.10.0.100";
    allow-update { trusted; };
    allow-transfer { slaves; };
};

include "/etc/bind/named.conf.blocked";

Wo liegt das Problem? Warum kann bind9 die aufgelöste Adresse von der Fritzbox nicht annehmen, obwohl sie geliefert wird?

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: Re: öffentliche vs. private Zone in eigenem DNS

Beitrag von mat6937 » 16.10.2018 10:00:42

scientific hat geschrieben: ↑ zum Beitrag ↑
16.10.2018 09:31:04
Ich sitze hier am Rechner 10.0.100.9 und bin über Mobilfunk mit dem Internet und mittels VPN mit meinem VPN verbunden (So wie LAP2.vpn in meiner obigen Grafik)

Auf 10.0.100.1 sniffe ich mit tcpdump den Netzwerkverkehr auf tun0 auf Port 53 und bekomme dieses Ergebnis:
Sniffe mal auch auf dem Rechner 10.0.100.9 auf tun0 und udp Port 53. Kommt dort was an?

Antworten