ubuntuusers.de

Ich denke, der Eintrag bezieht sich darauf, dass dnsmasq zunächst einmal eben nicht von außen (also nicht nur lokal begrenzt) erreichbar sein soll. Der Eintrag im Debian-Wiki trifft es ganz gut finde ich:

Note that if you plan to use dnsmasq for the local system only, you should lock it down by adding the line

1	listen-address=127.0.0.1

to the dnsmasq configuration file (/etc/dnsmasq.conf).

Ich würde den Eintrag daher nicht streichen.

Unter Dnsmasq (Abschnitt „Konfiguration-als-DHCP-Server“) wird als Beispieldomain .foo.bar benutzt, unter Hinweis darauf, dass man existierende Domains wg. Konfliktgefahr nicht benutzen sollte. Seit Februar 2014 existiert .bar allerdings bei der ICANN als offizielle "generic top-level-domain". Die Domain .foo.bar ist vergeben.

Die Beispiele sollten meiner Meinung nach abgeändert werden. Eine Reihe von "Special Use Domains" wird von der IANA reserviert (bspw. die im Artikel beschriebene .local, von deren Verwendung zu Recht abgeraten wird). Anhang G zur RFC 6752 (dem auch die Reservierung von .local entstammt) schlägt zudem .intranet, .internal, .private, .corp, .home und .lan vor.

Zur Ehrenrettung: Die Konfiguration mit .foo.bar tauchte erstmals in der Revision 6173 vom 08.11.2006 auf. Zu diesem Zeitpunkt existierte .bar noch nicht. Damals war die Verwendung der TLD also noch durchaus sinnvoll. 😉

MisterX schrieb:

Unter Dnsmasq (Abschnitt „Konfiguration-als-DHCP-Server“) wird als Beispieldomain .foo.bar benutzt, unter Hinweis darauf, dass man existierende Domains wg. Konfliktgefahr nicht benutzen sollte. Seit Februar 2014 existiert .bar allerdings bei der ICANN als offizielle "generic top-level-domain". Die Domain .foo.bar ist vergeben.

Die Beispiele sollten meiner Meinung nach abgeändert werden. […]

Zur Ehrenrettung: Die Konfiguration mit .foo.bar tauchte erstmals in der Revision 6173 vom 08.11.2006 auf. Zu diesem Zeitpunkt existierte .bar noch nicht. Damals war die Verwendung der TLD also noch durchaus sinnvoll. 😉

Die Verwendung willkürlicher Domain-Bezeichnungen ist eine Unart und gar nicht erforderlich. Seit Juni 1999 (!) ist es „Best Current Practice“ in Dokumentationen die dafür vorgesehenen reservierten Namen zu verwenden, z.B.

.example

.example.com

.example.net

.example.org

Vergleiche RFC 2606 (Juni 1999) und RFC 6761 (Feb. 2013)!

Ich habe das jetzt angepasst.

Hallo,

habe hier mal das getestet-general raus genommen und trusty+xenial gesetzt. Schon alleine wegen der Bearbeitung der resolv.conf und systemd-resolved unter bionic und Konsorten.

(Es gibt Leute die meinen, man könnte mit dem dnsmasq seine DNS-Probleme auf einem bionic-System lösen...)

Gruß BillMaier

Ohne Groovy ungetestet.

frustschieber schrieb:

Ohne Groovy ungetestet.

Würde das mit Focal testen, aber auch um enige Punkte (z.B. IPv6) erweitern. Ich bitte um eine Baustelle.

DJKUhpisse schrieb:

[...] Ich bitte um eine Baustelle.

Done. Fertigstellungsdatum kannst Du ja anpassen ☺

LG
tuxifreund

Spricht was dagegen, das aufzuteilen, also DNS und DHCP/BOOTP/TFTP zu trennen? Würde dann später die Testbarkeit in meinen Augen verbessern.

Hallo,

also grundsätzlich ist alles, was die Testbarkeit verbessert, gut.

Gruß, noisefloor

Auch hier bitte ich um Rückmeldung, ob das so passt.

Hallo,

formell passt es, inhaltlich kann ich nicht viel dazu sagen.

Gruß, noisefloor

Wurde ja durch mich getestet, also ok.

Hallo! Im Abschnitt „Verwendung des Cache“ empfiehlst du das deaktivieren von systemd-resolved und das Anlegen einer statischen resolv.conf. Als einfacher würde ich das Eintragen der gewünschten DNS-Server in die /etc/dnsmasq.conf sehen, wo man die Konfiguration auch erwartet (server=…).

Die resolv.conf müsste ohne Deko und mit ipv6 so aussehen:

1
2
3
4

# /etc.resolv.conf
nameserver ::1
nameserver 127.0.0.1
options … usw.

systemd/systemd-resolved kann auch im Artikel verlinkt werden. Alternativ kann man systemd-resolved unter /etc/systemd/resolved.conf auch den localhost als einzigen DNS verpassen und die Option DNSStubListener=no setzen. Könnte dann minimal so aussehen

1
2
3
4
5
6

# /etc/systemd/resolved.conf
[Resolve]
DNS=127.0.0.1
DNS=::1
DNSSEC=yes  # falls in dnsmasq aktiviert
DNSStubListener=no

falls in Verbindung mit anderen Diensten, wie dhcpcd oder NetworkManager gearbeitet wird, die ohne entsprechende Anweisung einfach die resolv.conf löschen und ersetzen. Daher würde ich systemd-resolved aktiv lassen. Dann weiß man wenigstens, wer die Datei überschreibt.

Alles kein MUSS, nur ein KANN 😉 Naja, bis auf die ::1 in der resolv.conf.

ok, Hinweis ist drinnen, genaue Anleitung aber nicht, denn das würde in meinen Augen den Rahmen des Artikels sprengen.