Nächste: VNC-Dienste, Vorige: Zertifikatsdienste, Nach oben: Dienste [Inhalt][Index]
Das Modul (gnu services dns)
stellt Dienste zur Verfügung, die mit
dem Domain Name System (DNS) zu tun haben. Es bietet einen
Server-Dienst an, mit dem ein autoritativer DNS-Server für mehrere
Zonen betrieben werden kann, jeweils als untergeordneter „Slave“ oder als
„Master“. Dieser Dienst benutzt Knot
DNS. Außerdem wird ein zwischenspeichernder und weiterleitender DNS-Server
für das LAN bereitgestellt, der
dnsmasq benutzt.
Eine Beispielkonfiguration eines autoritativen Servers für zwei Zonen, eine „Master“, eine „Slave“, wäre:
(define-zone-entries example.org.zone ;; Name TTL Class Type Data ("@" "" "IN" "A" "127.0.0.1") ("@" "" "IN" "NS" "ns") ("ns" "" "IN" "A" "127.0.0.1")) (define master-zone (knot-zone-configuration (domain "example.org") (zone (zone-file (origin "example.org") (entries example.org.zone))))) (define slave-zone (knot-zone-configuration (domain "plop.org") (dnssec-policy "default") (master (list "plop-master")))) (define plop-master (knot-remote-configuration (id "plop-master") (address (list "208.76.58.171")))) (operating-system ;; ... (services (cons* (service knot-service-type (knot-configuration (remotes (list plop-master)) (zones (list master-zone slave-zone)))) ;; ... %base-services)))
Dies ist der Diensttyp für den Knot-DNS-Server.
Knot DNS ist ein autoritativer DNS-Server, das heißt, er kann mehrere Zonen bedienen, also mehrere Domainnamen, die Sie von einem Registrar kaufen würden. Dieser Server ist kein „Resolver“, er dient also nur zur Auflösung von Namen, für die er autoritativ ist. Dieser Server kann so konfiguriert werden, dass er Zonen als „Master“-Server oder als „Slave“-Server bereitstellt, je nachdem, wie er für die jeweilige Zone eingestellt ist. Server für „Slave“-Zonen erhalten ihre Daten von „Master“-Servern und stellen mit ihnen einen autoritativen Server zur Verfügung. Für einen „Resolver“ macht es keinen Unterschied, ob er Namen auflöst, indem er einen „Master“ oder einen „Slave“ danach fragt.
Die folgenden Datentypen werden benutzt, um den Knot-DNS-Server zu konfigurieren:
Datentyp, der einen Schlüssel repräsentiert. Dieser Typ hat die folgenden Parameter:
id
(Vorgabe: ""
)Ein Identifikator, mit dem sich andere Konfigurationsfelder auf diesen Schlüssel beziehen können. IDs müssen eindeutig sein und dürfen nicht leer sein.
algorithm
(Vorgabe: #f
)Der Algorithmus, der benutzt werden soll. Wählen Sie zwischen #f
,
'hmac-md5
, 'hmac-sha1
, 'hmac-sha224
,
'hmac-sha256
, 'hmac-sha384
und 'hmac-sha512
.
secret
(Vorgabe: ""
)Was dabei der geheime Schlüssel sein soll.
Datentyp, der die Konfiguration einer Zugriffssteuerungsliste („Access Control List“, ACL) repräsentiert. Dieser Typ hat die folgenden Parameter:
id
(Vorgabe: ""
)Ein Identifikator, mit dem sich andere Konfigurationsfelder auf diesen Schlüssel beziehen können. IDs müssen eindeutig sein und dürfen nicht leer sein.
address
(Vorgabe: '()
)Eine geordnete Liste aus IP-Adresse, Netzwerk-Subnetzen oder Netzwerkbereichen, die jeweils als Zeichenketten angegeben werden. Die Anfrage muss zu einem davon passen. Ein leerer Wert bedeutet, dass die Adresse nicht passen muss.
key
(Vorgabe: '()
)Eine geordnete Liste von Referenzen auf Schlüssel, die jeweils als
Zeichenketten angegeben werden. Die Zeichenkette muss zu einem
Schlüsselidentifikator passen, der in einem der
knot-key-configuration
-Objekte definiert wurde. Wenn kein Schlüssel
angegeben wird, bedeutet das, dass kein Schlüssel zu dieser
Zugriffssteuerungsliste passen muss.
action
(Vorgabe: '()
)Eine geordete Liste der Aktionen, die von dieser Zugriffssteuerungsliste
zugelassen oder gesperrt werden. Mögliche Werte sind Listen aus null oder
mehr Elementen, die jeweils 'transfer
, 'notify
oder
'update
sind.
deny?
(Vorgabe: #f
)Wenn dies auf wahr steht, werden mit der Zugriffssteuerungsliste Einschränkungen festgelegt, d.h. aufgelistet Aktionen werden gesperrt. Steht es auf falsch, werden aufgelistete Aktionen zugelassen.
Datentyp, der einen Eintrag in einer Zonendatei repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
name
(Vorgabe: "@"
)Der Name des Eintrags. "@"
bezieht sich auf den Ursprung der
Zone. Namen sind relativ zum Ursprung der Zone. Zum Beispiel bezieht sich in
einer Zone example.org
der Eintrag "ns.example.org"
tatsächlich auf ns.example.org.example.org
. Namen, die auf einen
Punkt enden, sind absolut. Das bedeutet, dass sich "ns.example.org."
auf ns.example.org
bezieht.
ttl
(Vorgabe: ""
)Wie lange dieser Eintrag zwischengespeichert werden darf, d.h. seine „Time-To-Live“ (TTL). Ist sie nicht festgelegt, wird die voreingestellte TTL benutzt.
class
(Vorgabe: "IN"
)Welche Klasse der Eintrag hat. Derzeit unterstützt Knot nur "IN"
und
teilweise "CH"
.
type
(Vorgabe: "A"
)Der Typ des Eintrags. Zu den üblichen Typen gehören A (für eine IPv4-Adresse), AAAA (für eine IPv6-Adresse), NS (der Namens-Server) und MX („Mail eXchange“ für E-Mails). Viele andere Typen sind auch definiert.
data
(Vorgabe: ""
)Die Daten, die im Eintrag stehen, zum Beispiel eine IP-Adresse bei einem A-Eintrag oder ein Domain-Name bei einem NS-Eintrag. Bedenken Sie, dass Domain-Namen relativ zum Ursprung angegeben werden, außer wenn sie auf einen Punkt enden.
Datentyp, der den Inhalt einer Zonendatei repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
entries
(Vorgabe: '()
)Die Liste der Einträge. Für den SOA-Eintrag wird automatisch gesorgt, also
müssen Sie ihn nicht zur Liste der Einträge hinzufügen. In der Liste sollte
vermutlich ein Eintrag für Ihren primären autoritativen DNS-Server
stehen. Abgesehen vom direkten Aufzählen der Einträge können Sie
define-zone-entries
verwenden, um ein Objekt zu definieren, worin
eine Liste von Einträgen leichter angegeben werden kann, und was sie dann im
entries
-Feld des zone-file
angeben können.
origin
(Vorgabe: ""
)Der Name Ihrer Zone. Dieser Parameter darf nicht leer sein.
ns
(Vorgabe: "ns"
)Die Domain Ihres primären autoritativen DNS-Servers. Der Name wird relativ zum Ursprung angegeben, außer wenn er auf einen Punkt endet. Dieser primäre DNS-Server muss verpflichtend einem NS-Eintrag in der Zone entsprechen, dem eine IP-Adresse in der Liste der Einträge zugeordnet werden muss.
mail
(Vorgabe: "hostmaster"
)Eine E-Mail-Adresse, unter der man Sie als für diese Zone Verantwortlichen
(„Besitzer“/„Owner“) kontaktieren kann. Sie wird zu <mail>@<origin>
umgeschrieben.
serial
(Vorgabe: 1
)Die Seriennummer der Zone. Da sie von sowohl „Slaves“ als auch „Resolvern“ benutzt wird, um bei Änderungen auf dem Laufenden zu bleiben, ist es notwendig, dass sie niemals kleiner gemacht wird. Erhöhen Sie sie, wann immer Sie eine Änderung an Ihrer Zone durchführen.
refresh
(Vorgabe: (* 2 24 3600)
)Die Häufigkeit, wie oft Slaves eine Zonenübertragung („Zone Transfer“)
durchführen. Als Wert wird eine Anzahl von Sekunden angegeben. Sie kann über
eine Multiplikation oder mit (string->duration)
angegeben werden.
retry
(Vorgabe: (* 15 60)
)Nach welcher Zeitperiode ein Slave versuchen wird, Kontakt mit seinem Master aufzunehmen, wenn er ihn beim ersten Mal nicht erreichen kann.
expiry
(Vorgabe: (* 14 24 3600)
)Die Voreinstellung, welche TTL für Einträge verwendet werden soll. Bestehende Einträge werden für höchstens diese Zeitspanne als korrekt angesehen. Nach Ablauf dieser Zeitspanne werden „Resolver“ ihren Zwischenspeicher als ungültig markieren und erneut prüfen, ob der Eintrag noch existiert.
nx
(Vorgabe: 3600
)Die voreingestellte TTL der nicht existierenden Einträge. Sie stellt normalerweise eine kurze Verzögerung dar, weil Sie möchten, dass neue Domains für jeden schnell erkannt werden.
Datentyp, der die Konfiguration eines entfernten Servers („Remote“) repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
id
(Vorgabe: ""
)Ein Identifikator, mit dem man sich in anderen Konfigurationsfeldern auf diesen entfernten Server („Remote“) beziehen kann. IDs müssen eindeutig sein und dürfen nicht leer sein.
address
(Vorgabe: '()
)Eine geordnete Liste der Empfänger-IP-Adressen. Adressen werden der Reihe
nach durchprobiert. Optional kann eine Portnummer nach dem Trennzeichen @
angegeben werden, zum Beispiel als (list "1.2.3.4"
"2.3.4.5@53")
. Die Vorgabe ist 53.
via
(Vorgabe: '()
)Eine geordnete Liste der Quell-IP-Adressen. Eine leere Liste wird Knot eine sinnvolle Quell-IP-Adresse auswählen lassen. Optional kann eine Portnummer nach dem Trennzeichen @ angegeben werden. Die Vorgabe wird zufällig ausgewählt.
key
(Vorgabe: #f
)Ein Verweis auf einen Schlüssel („Key“), also eine Zeichenkette, die den
Identifikator eines Schlüssels enthält, der in einem
knot-key-configuration
-Feld festgelegt wurde.
Datentyp, der einen Schlüsselspeicher („Keystore“) repräsentiert, um DNSSEC-Schlüssel zu fassen. Dieser Typ verfügt über die folgenden Parameter:
id
(Vorgabe: ""
)Der Identifikator des Schlüsselspeichers. Er darf nicht leer gelassen werden.
backend
(Vorgabe: 'pem
)Die Art von Hintergrundspeicher, in dem Schlüssel eingetragen werden. Sie
kann 'pem
oder 'pkcs11
sein.
config
(Vorgabe: "/var/lib/knot/keys/keys"
)Die Zeichenkette mit der Konfiguration des Hintergrundspeichers. Ein
Beispiel für die PKCS#11 ist "pkcs11:token=knot;pin-value=1234
/gnu/store/…/lib/pkcs11/libsofthsm2.so"
. Für pem als Hintergrundspeicher
repräsentiert die Zeichenkette einen Pfad im Dateisystem.
Datentyp, der die DNSSEC-Richtlinie repräsentiert. Knot DNS kann Ihre Zonen automatisch signieren. Der Dienst kann Ihre Schlüssel automatisch erzeugen und verwalten oder Schlüssel benutzen, die Sie selbst erzeugen.
DNSSEC wird in der Regel mit zwei Schlüsseln implementiert: Ein Schlüssel, mit dem Schlüssel signiert werden („Key Signing Key“, KSK), signiert den zweiten Schlüssel, einen Schlüssel, der Zonen signiert („Zone Signing Key“, ZSK), mit dem die Zone signiert wird. Damit er als vertrauenswürdig angesehen wird, muss der KSK in der Elternzone stehen (meistens ist das eine Top-Level-Domain). Wenn Ihr Registrar DNSSEC unterstützt, müssen Sie ihm den Hash Ihres KSK übermitteln, damit er einen DS-Eintrag für Ihre Zone hinzufügen kann. Das passiert nicht automatisch und muss jedes Mal wiederholt werden, wenn Sie Ihren KSK ändern.
Die Richtlinie legt auch fest, wie lange Ihre Schlüssel gültig bleiben. Normalerweise kann der ZSK leicht geändert werden und benutzt kryptografisch schwächere Funktionen (also niedrigere Parameter), damit Einträge schnell signiert werden können, wodurch man sie oft verändern kann. Der KSK setzt jedoch eine manuelle Interaktion mit dem Registrar voraus, also werden sie weniger oft geändert und verwenden stärkere Parameter, weil mit ihnen nur ein einziger Eintrag signiert wird.
Dieser Typ verfügt über die folgenden Parameter:
id
(Vorgabe: ""
)Der Identifikator der Richtlinie. Er darf nicht leer sein.
keystore
(Vorgabe: "default"
)Eine Referenz auf einen Schlüsselspeicher („Keystore“), also eine
Zeichenkette, die den Identifikator eines Schlüsselspeichers enthält, der in
einem knot-keystore-configuration
-Feld gespeichert ist. Der
Identifikator "default"
sorgt dafür, dass der vorgegebene
Schlüsselspeicher verwendet wird (eine KASP-Datenbank, die durch diesen
Dienst eingerichtet wurde).
manual?
(Vorgabe: #f
)Ob Schlüssel manuell verwaltet werden sollen; andernfalls werden sie automatisch verwaltet.
single-type-signing?
(Vorgabe: #f
)Wenn es auf #t
steht, werden dieselben Schlüssel als KSK und ZSK
verwendet („Single-Type Signing Scheme“).
algorithm
(Vorgabe: "ecdsap256sha256"
)Ein Algorithmus für zum Signieren verwendete Schlüssel und ausgestellte Signaturen.
ksk-size
(Vorgabe: 256
)Die Länge des KSK. Beachten Sie, dass dieser Wert für den vorgegebenen Algorithmus korrekt ist, aber für andere Algorithmen nicht sicher wäre.
zsk-size
(Vorgabe: 256
)Die Länge des ZSK. Beachten Sie, dass dieser Wert für den vorgegebenen Algorithmus korrekt ist, aber für andere Algorithmen nicht sicher wäre.
dnskey-ttl
(Vorgabe: 'default
)Der TTL-Wert für DNSKEY-Einträge, die die Wurzel der Zone betreffen. Der
besondere Wert 'default
bedeutet, dass dieselbe TTL wie für den
SOA-Eintrag der Zone verwendet wird.
zsk-lifetime
(Vorgabe: (* 30 24 3600)
)Die Zeitspanne zwischen der Veröffentlichung eines ZSK und dem Anfang des nächsten Schlüsselübergangs („Key Rollover“).
propagation-delay
(Vorgabe: (* 24 3600)
)Eine zusätzliche Verlängerung, die bei jedem Schritt im Schlüsselübergang („Key Rollover“) gewartet wird. Dieser Wert sollte hoch genug sein, damit in dieser Zeit Daten vom Master-Server alle Slaves erreichen.
rrsig-lifetime
(Vorgabe: (* 14 24 3600)
)Wie lange neu ausgestellte Signaturen gültig bleiben.
rrsig-refresh
(Vorgabe: (* 7 24 3600)
)Wie lange im Voraus vor einem Auslaufen der Signatur diese Signatur erneuert werden soll.
nsec3?
(Vorgabe: #f
)Ist es auf #t
gesetzt, wird NSEC3 statt NSEC benutzt.
nsec3-iterations
(Vorgabe: 5
)Wie oft zusätzlich gehasht werden soll.
nsec3-salt-length
(Vorgabe: 8
)Wie lange das kryptografische „Salt“ sein soll, als Anzahl von Oktetten. Es wird vor dem Hashen an den Namen des ursprünglichen Besitzers angehängt.
nsec3-salt-lifetime
(Vorgabe: (* 30 24 3600)
)Wie lange das neu ausgestellte Salt-Feld gültig bleiben soll.
Datentyp, der eine durch Knot verfügbar gemachte Zone repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
domain
(Vorgabe: ""
)Die Domain, die durch diese Konfiguration zur Verfügung gestellt wird. Sie darf nicht leer sein.
file
(Vorgabe: ""
)Die Datei, in der diese Zone abgespeichert wird. Dieser Parameter wird bei Master-Zonen ignoriert. Bleibt er leer, wird die vom Domain-Namen abhängige Voreinstellung benutzt.
zone
(Vorgabe: (zone-file)
)Der Inhalt der Zonendatei. Dieser Parameter wird bei Slave-Zonen
ignoriert. Er muss ein Verbundsobjekt vom Typ zone-file
enthalten.
master
(Vorgabe: '()
)Eine Liste von als „Master“ geltenden entfernten Servern. Ist sie leer, ist diese Zone ein Master, sonst ein Slave. Es handelt sich um eine Liste von Identifikatoren entfernter Server („Remotes“).
ddns-master
(Vorgabe: #f
)Der vorrangige „Master“. Ist dies leer, wird hierfür der erste Master aus der Liste der Master benutzt.
notify
(Vorgabe: '()
)Eine Liste der Identifikatoren von entfernten Slave-Servern („Remotes“).
acl
(Vorgabe: '()
)Eine Liste von Identifikatoren von Zugriffssteuerungslisten.
semantic-checks?
(Vorgabe: #f
)Wenn dies festgelegt ist, werden für die Zone mehr semantische Überprüfungen durchgeführt.
zonefile-sync
(Vorgabe: 0
)Wie lange nach einer Änderung der im Arbeitsspeicher zwischengespeicherten Daten gewartet wird, bis die Daten auf die Platte geschrieben werden. Bei 0 werden sie sofort synchronisiert.
zonefile-load
(Vorgabe: #f
)Wie die in der Zonendatei gespeicherten Daten benutzt werden, wenn die Zone geladen wird. Mögliche Werte sind:
#f
sorgt dafür, dass nach der Voreinstellung von Knot verfahren wird,
'none
bewirkt, dass die Zonendatei überhaupt nicht benutzt wird,
'difference
lässt den Unterschied zwischen den bereits vorliegenden
Daten und dem gespeicherten Inhalt der Zone berechnen, welcher dann zum
vorliegenden Zoneninhalt hinzugenommen wird,
'difference-no-serial
für dasselbe wie bei 'difference
,
aber die SOA-Seriennummer in der Zonendatei wird ignoriert und der Server
kümmert sich automatisch darum.
'whole
lässt den ganzen Inhalt der Zone aus der Zonendatei auslesen.
journal-content
(Vorgabe: #f
)Wie in den Aufzeichnungen die Zone und Änderungen daran gespeichert werden
sollen. Mögliche Werte sind 'none
, um keine Aufzeichnungen zu führen,
'changes
, um Änderungen zu speichern, und 'all
, wodurch der
gesamte Inhalt gespeichert wird. Für #f
wird dieser Wert nicht
gesetzt, so dass der in Knot voreingestellte Wert benutzt wird.
max-journal-usage
(Vorgabe: #f
)Die maximale Größe, die Aufzeichnungen für die Wiederherstellbarkeit
(„Journal“) auf der Platte einnehmen können. Für #f
wird dieser Wert
nicht gesetzt, so dass der in Knot voreingestellte Wert benutzt wird.
max-journal-depth
(Vorgabe: #f
)Wie viele Aufzeichnungen höchstens im Änderungsverlauf gespeichert
werden. Für #f
wird dieser Wert nicht gesetzt, so dass der in Knot
voreingestellte Wert benutzt wird.
max-zone-size
(Vorgabe: #f
)Die maximale Größe der Zonendatei. Diese Beschränkung wird auf eingehende
Übertragungen und Aktualisierungen angewandt. Für #f
wird dieser Wert
nicht gesetzt, so dass der in Knot voreingestellte Wert benutzt wird.
dnssec-policy
(Vorgabe: #f
)Ein Verweis auf ein knot-policy-configuration
-Verbundsobjekt oder der
besondere Name "default"
, um die Voreinstellung von Knot zu
verwenden. Wenn dies als der Wert #f
angegeben wurde, findet in
dieser Zone kein Signieren mit DNSSEC statt.
serial-policy
(Vorgabe: 'increment
)Eine Richtlinie; entweder 'increment
(Seriennummer hochzählen) oder
'unixtime
(Unix-Zeitstempel verwenden).
Datentyp, der die Konfiguration von Knot repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
knot
(Vorgabe: knot
)Das Knot-Paket.
run-directory
(Vorgabe: "/var/run/knot"
)Das Laufzeit-Verzeichnis („run“-Verzeichnis). In diesem Verzeichnis werden die PID-Datei mit dem Prozessidentifikator und Sockets gespeichert.
includes
(Vorgabe: '()
)Eine flache Liste von Zeichenketten oder dateiartigen Objekten, die oben in der Konfigurationsdatei eingebunden werden müssen.
Hiermit können Geheimnisse abseits von Guix’ Zuständigkeitsbereich
gespeichert werden. Zum Beispiel können Sie geheime Schlüssel so in einer
externen Datei speichern, die nicht von Guix verwaltet und daher auch nicht
von jedem in /gnu/store ausgelesen werden kann – Sie können etwa
Ihre geheime Schlüsselkonfiguration in /etc/knot/secrets.conf
speichern und diese Datei dann zu Ihrer includes
-Liste hinzufügen.
Sie können mit dem Schlüsselverwaltungsprogramm keymgr
aus dem
Knot-Paket einen geheimen TSIG-Schlüssel erzeugen lassen (für
nsupdate
und Zonentransfers). Beachten Sie, dass das Paket
nicht automatisch durch den Dienst installiert wird. Das folgende
Beispiel zeigt, wie man einen neuen TSIG-Schlüssel erzeugen lässt:
keymgr -t meingeheimnis > /etc/knot/secrets.conf chmod 600 /etc/knot/secrets.conf
Außerdem sollten Sie bedenken, dass der erzeugte Schlüssel den Namen
meingeheimnis bekommt, dieser Name also auch im key-Feld des
knot-acl-configuration
-Verbundsobjekts und an anderen Stellen
verwendet werden muss, wo auf den Schlüssel verwiesen wird.
Sie können die includes
auch benutzen, um von der Guix-Schnittstelle
nicht unterstützte Einstellungen festzulegen.
listen-v4
(Vorgabe: "0.0.0.0"
)Eine IP-Adresse, auf der gelauscht werden soll.
listen-v6
(Vorgabe: "::"
)Eine IP-Adresse, auf der gelauscht werden soll.
listen-port
(Vorgabe: 53
)Ein Port, auf dem gelauscht werden soll.
keys
(Vorgabe: '()
)Die Liste der knot-key-configuration
-Objekte, die von dieser
Konfiguration benutzt werden sollen.
acls
(Vorgabe: '()
)Die Liste der knot-acl-configuration
-Objekte, die von dieser
Konfiguration benutzt werden sollen.
remotes
(Vorgabe: '()
)Die Liste der knot-remote-configuration
-Objekte, die von dieser
Konfiguration benutzt werden sollen.
zones
(Vorgabe: '()
)Die Liste der knot-zone-configuration
-Objekte, die von dieser
Konfiguration benutzt werden sollen.
Dies ist der Diensttyp des Knot-Resolver-Dienstes, dessen Wert ein
knot-resolver-configuration
-Objekt wie in diesem Beispiel sein
sollte:
(service knot-resolver-service-type
(knot-resolver-configuration
(kresd-config-file (plain-file "kresd.conf" "
net.listen('192.168.0.1', 5353)
user('knot-resolver', 'knot-resolver')
modules = { 'hints > iterate', 'stats', 'predict' }
cache.size = 100 * MB
"))))
Weitere Informationen finden Sie in seinem Handbuch.
Der Datentyp, der die Konfiguration von knot-resolver repräsentiert.
package
(Vorgabe: knot-resolver)Das Paketobjekt des Knot-DNS-Resolvers.
kresd-config-file
(Vorgabe: %kresd.conf)Dateiartiges Objekt der zu nutzenden kresd-Konfigurationsdatei. Nach Vorgabe
lauscht der Knot-Resolver auf 127.0.0.1
und ::1
.
garbage-collection-interval
(Vorgabe: 1000)Wie viele Millisekunden kres-cache-gc
zwischen Bereinigungen seines
Zwischenspeichers wartet.
Dies ist der Diensttyp des dnsmasq-Dienstes, dessen Wert ein
dnsmasq-configuration
-Objekt wie in diesem Beispiel sein sollte:
(service dnsmasq-service-type
(dnsmasq-configuration
(no-resolv? #t)
(servers '("192.168.1.1"))))
Repräsentiert die dnsmasq-Konfiguration.
package
(Vorgabe: dnsmasq)Paketobjekt des dnsmasq-Servers.
no-hosts?
(Vorgabe: #f
)Ist es auf wahr gesetzt, werden keine Rechnernamen („Hostnames“) aus /etc/hosts ausgelesen.
port
(Vorgabe: 53
)Der Port, auf dem gelauscht werden soll. Wird dies auf null gesetzt, werden keinerlei DNS-Anfragen beantwortet und es bleiben nur DHCP- und/oder TFTP-Funktionen.
local-service?
(Vorgabe: #t
)DNS-Anfragen nur von Rechnern akzeptieren, deren Adresse auf einem lokalen Subnetz liegt, d.h. einem Subnetz, für dem auf dem Server eine Schnittstelle existiert.
listen-addresses
(Vorgabe: '()
)Lässt auf den angegebenen IP-Adressen lauschen.
resolv-file
(Vorgabe: "/etc/resolv.conf"
)Aus welcher Datei die IP-Adresse der zu verwendenden Namensserver gelesen werden sollen.
no-resolv?
(Vorgabe: #f
)Wenn es auf wahr steht, wird das resolv-file nicht gelesen.
forward-private-reverse-lookup?
(Vorgabe: #t
)Wenn dies auf falsch gesetzt ist, werden inverse Namensauflösungen in privaten IP-Adressbereichen wie „Domain existiert nicht“ beantwortet, anstatt sie an vorgelagerte Server weiterzuleiten.
query-servers-in-order?
(Vorgabe: #f
)Wenn dies auf wahr gesetzt ist, wird dnsmasq die Server in genau der Reihenfolge anfragen, in der sie in servers aufgeführt sind.
servers
(Vorgabe: '()
)Geben Sie die IP-Adresse von anzufragenden Servern direkt an.
addresses
(Vorgabe: '()
)Geben Sie in jedem Eintrag eine IP-Adresse an, die für jeden Rechner mit einer der angegebenen Domains zurückgeliefert werden soll. Anfragen nach den Domains werden niemals weitergegeben, sondern werden immer mit der festgelegten IP-Adresse beantwortet.
Dies ist nützlich, um für Rechnernamen lokale Umleitungen einzurichten, wie in diesem Beispiel:
(service dnsmasq-service-type
(dnsmasq-configuration
(addresses
'(; Weiterleitung auf lokalen Webserver.
"/example.org/127.0.0.1"
; Weiterleitung einer Subdomain auf eine bestimmte IP.
"/subdomain.example.org/192.168.1.42"))))
Beachten Sie, dass die Regeln in /etc/hosts Vorrang haben.
cache-size
(Vorgabe: 150
)Bestimmt die Größe des Zwischenspeichers von dnsmasq. Wird die Zwischenspeichergröße auf null festgelegt, wird kein Zwischenspeicher benutzt.
negative-cache?
(Vorgabe: #t
)Ist dies auf falsch gesetzt, werden Negativergebnisse nicht zwischengespeichert.
cpe-id
(Vorgabe: #f
)Wenn es festgelegt ist, wird dies als Endgerätebezeichnung („Customer-Premises Equipment Identifier“) in DNS-Anfragen übermittelt, die an vorgelagerte Server weitergeleitet werden.
tftp-enable?
(Vorgabe: #f
)Ob der eingebaute TFTP-Server aktiviert werden soll.
tftp-no-fail?
(Vorgabe: #f
)Wenn dies wahr ist und der TFTP-Server nicht gestartet werden kann, gilt dnsmasq trotzdem nicht als fehlgeschlagen.
tftp-single-port?
(Vorgabe: #f
)Ob nur ein einzelner Port für TFTP benutzt werden soll.
tftp-secure?
(Vorgabe: #f
)Wenn dies wahr ist, kann nur auf solche Dateien zugegriffen werden, die dem Benutzerkonto gehören, das den dnsmasq-Prozess ausführt.
Wird dnsmasq durch den Administratornutzer root ausgeführt, gelten andere
Regeln: tftp-secure?
wirkt sich nicht aus, aber es kann nur auf
Dateien zugegriffen werden, auf die jeder Benutzer zugreifen darf (das
„world-readable bit“ ist gesetzt).
tftp-max
(Vorgabe: #f
)Wenn dies gesetzt ist, gibt es die Maximalzahl gleichzeitig zugelassener Verbindungen an.
tftp-mtu
(Vorgabe: #f
)Wenn es gesetzt ist, gibt es die MTU für TFTP-Pakete an, also die Maximalgröße für Netzwerkschnittstellen.
tftp-no-blocksize?
(Vorgabe: #f
)Steht es auf wahr, wird der TFTP-Server die Blockgröße nicht mit dem Client aushandeln.
tftp-lowercase?
(Vorgabe: #f
)Ob alle Dateinamen in TFTP-Anfragen in Kleinbuchstaben umgesetzt werden sollen.
tftp-port-range
(Vorgabe: #f
)Wenn es gesetzt ist, wird jeder dynamische Port (einer pro Client) aus dem
angegebenen Bereich ("<von>,<bis>"
) genommen.
tftp-root
(Vorgabe: /var/empty,lo
)Relativ zu welchem Verzeichnis die Dateien für die Übertragung per TFTP
gesucht werden. Wenn dies gesetzt ist, werden TFTP-Pfade, die ‘..’
enthalten, abgelehnt, damit Clients keinen Zugriff auf Dateien außerhalb des
angegebenen Wurzelverzeichnisses haben. Absolute Pfade (solche, die mit
‘/’ beginnen) sind erlaubt, aber sie müssen in der TFTP-Root
liegen. Wenn das optionale Argument interface
angegeben wird, wird
das Verzeichnis nur für TFTP-Anfragen über diese Schnittstelle benutzt.
tftp-unique-root
(Vorgabe: #f
)Wenn es gesetzt ist, wird entsprechend die IP- oder Hardware-Adresse des TFTP-Clients als eine Pfadkomponente ans Ende der TFTP-Root angehängt. Das ist nur gültig, wenn eine TFTP-Root gesetzt ist und das Verzeichnis existiert. Die Voreinstellung ist, die IP-Adresse anzuhängen (wie üblich als punktgetrenntes Quadrupel).
Ist zum Beispiel tftp-root
‘/tftp’ und fragt Client
‘1.2.3.4’ die Datei meinedatei an, dann wird effektiv als Pfad
/tftp/1.2.3.4/meinedatei abgerufen, wenn /tftp/1.2.3.4
existiert, oder /tftp/meinedatei andernfalls. Wird ‘=mac’
angegeben, wird stattdessen die MAC-Adresse angehängt (in Kleinbuchstaben
und durch Striche getrennt, aufgefüllt mit der Ziffer null), z.B.
‘01-02-03-04-aa-bb’. Beachten Sie, dass MAC-Adressen nur aufgelöst
werden können, wenn sich der Client im lokalen Netzwerk befindet oder von
dnsmasq eine Adresse per DHCP zugewiesen bekommen hat.
Der im Folgenden beschriebene ddclient-Dienst führt den ddclient-Daemon aus, der dafür sorgt, dass DNS-Einträge für Dienstanbieter wie Dyn automatisch aktualisiert werden.
Das folgende Beispiel zeigt, wie man den Dienst mit seiner Vorgabekonfiguration instanziiert:
(service ddclient-service-type)
Beachten Sie, dass der ddclient auf Zugangsdaten zugreifen muss, die in
einer Geheimnisdatei („Secret File“) stehen; nach Vorgabe wird sie in
/etc/ddclient/secrets gesucht (siehe secret-file
unten). Es
wird erwartet, dass Sie diese Datei manuell erstellen, ohne Guix dafür zu
benutzen (theoretisch könnten Sie die Datei zu einem Teil Ihrer
Dienstkonfiguration machen, indem Sie z.B. plain-file
benutzen,
aber dann könnte jeder über /gnu/store ihren Inhalt einsehen). Siehe
die Beispiele im Verzeichnis share/ddclient des
ddclient
-Pakets.
Verfügbare ddclient-configuration
-Felder sind:
ddclient-configuration
-Parameter: „package“ ddclient ¶Das ddclient-Paket.
ddclient-configuration
-Parameter: Ganze-Zahl daemon ¶Nach wie viel Zeit ddclient erneut versuchen wird, IP und Domain-Namen zu überprüfen.
Die Vorgabe ist ‘300’.
ddclient-configuration
-Parameter: Boolescher-Ausdruck syslog ¶Ob die Ausgabe an Syslog gehen soll.
Die Vorgabe ist ‘#t’.
ddclient-configuration
-Parameter: Zeichenkette mail ¶An welchen Benutzer Mitteilungen gemailt werden sollen.
Die Vorgabe ist ‘"root"’.
ddclient-configuration
-Parameter: Zeichenkette mail-failure ¶Den Nutzer per Mail bei fehlgeschlagenen Aktualisierungen benachrichtigen.
Die Vorgabe ist ‘"root"’.
ddclient-configuration
-Parameter: Zeichenkette pid ¶PID-Datei für den ddclient.
Die Vorgabe ist ‘"/var/run/ddclient/ddclient.pid"’.
ddclient-configuration
-Parameter: Boolescher-Ausdruck ssl ¶SSL-Unterstützung aktivieren.
Die Vorgabe ist ‘#t’.
ddclient-configuration
-Parameter: Zeichenkette user ¶Gibt den Namen oder Identifikator des Benutzerkontos an, unter dem das ddclient-Programm laufen soll.
Die Vorgabe ist ‘"ddclient"’.
ddclient-configuration
-Parameter: Zeichenkette group ¶Die Gruppe des Benutzers, mit dem das ddclient-Programm läuft.
Die Vorgabe ist ‘"ddclient"’.
ddclient-configuration
-Parameter: Zeichenkette secret-file ¶Die Geheimnisdatei („Secret File“), die an die erzeugte ddclient.conf-Datei angehängt wird. Diese Datei enthält die Zugangsdaten, die ddclient benutzen soll. Es wird erwartet, dass Sie sie manuell erzeugen.
Die Vorgabe ist ‘"/etc/ddclient/secrets.conf"’.
ddclient-configuration
-Parameter: Liste extra-options ¶Zusätzliche Einstellungsoptionen, die an die ddclient.conf-Datei angehängt werden.
Die Vorgabe ist ‘()’.
Nächste: VNC-Dienste, Vorige: Zertifikatsdienste, Nach oben: Dienste [Inhalt][Index]