Grundbegriffe für DNS-Datensätze (Resource Records und FQDNs)

• FQDN: Fully Qualified Domain Name, eindeutige Bezeichnung für ein DNS-Namensobjekt, z.B. myhost.mydomain.de. FQDNs sind hierarchisch aufgebaut (Baumstruktur), wobei jede Hierarchieebene einen Namen (Label) bekommt. Als Trennzeichen zwischen diesen Namen wird der Punkt verwendet. Die Wurzelebene (oberste Ebene oder top level domain, TLD) steht im FQDN an der letzten Position, dh. am Ende (rechts).

• Label: Basiselement von FQDNs, Name in der jeweiligen Hierarchieebene, darf keinen Punkt enthalten. Z.B. ist ‘de’ das Label der obersten Ebene von ‘myhost.mydomain.de’.

• Domain: allgemeiner Begriff für Non-Terminal-FQDNs. Eine Domain kann Untereinträge enthalten, die wiederum Domains sein können oder auch keine weiteren Untereinträge haben. Letztere werden als Terminal-FQDNs bezeichnet und für Einträge verwendet, bei denen Untereinträge gesperrt werden sollen.

• Resource Record (RR) bzw. -Satz (RR-Set): Basiseinheit der DNS-Einträge. Ein RR-Set besteht aus mehreren RRs desselben Typs und desselben Owner-FQDNs. Ein RR setzt sich aus folgenden Bestandteilen zusammen, von denen die Kombination von Owner FQDN, RR Type, RR Data grundsätzlich eindeutig ist:

  • Owner FQDN: wichtigster Schlüsselparameter des RR-Sets. “Owner” steht für die primäre Zuordnung des FQDN zum RR bzw. RR-Set.
  • RR Type: Typbezeichnung (RRT) des RR-Sets. Gibt an, welcher Art die Daten des Eintrags sind (z.B. A, AAAA, CNAME, etc.). Owner-FQDN und RRT sind eindeutige Schlüsselparameter eines RR-Sets. NetDB-intern wird RRT durch einen erweiterten, DB-internen Recordtyp (DBRT) ergänzt, der neben dem RRT zusätzliche Attribute enthält (s. “Resource-Record-Typ-Definition” weiter unten). Jedes RR-Set ist genau einem RRT und genau einem DBRT zugeordnet.
  • RR TTL: “Time To Live”, Integer-Parameter, der angibt, wie lange (in Sekunden) der RR von Resolvern im Cache gehalten werden darf, bevor eine erneute Validierung beim authoritativen Nameserver erfolgen muss. Standardmäßig erben alle RRs einer Zone deren TTL, wenn kein expliziter Wert festgelegt wird. Die TTL ist für alle RRs innerhalb eines Sets gleich.
  • RR Data: Datenfeld, auch als RR-Ziel bezeichnet. Je nach RRT handelt es sich hier um
    • Zieldaten der Form:
      • IP-Adresse (adressbasierter RR) oder
      • FQDN, wobei die Kombination mit weiteren Parametern bzw. Text möglich ist (namensbasierter RR). Dieser stellt eine Referenz zu einem bereits vorhandenen Owner-FQDN eines anderen RRs oder desselben RRs dar (s.a. RR-Kette).
    • unstrukturierte Daten: sonstige Daten im Textformat, die weder IP-Adresse noch FQDN enthalten (nullbasierter RR) und deren Interpretation einer höheren Anwendungslogik/Meta-Ebene vorbehalten ist.

• DB-Namenstyp (DBNT): datenbank- bzw. systeminterner FQDN-Typ, dessen Definition pro WebAPI-Version fest vorgegeben ist und im Objekttypindex abgefragt werden kann. Er enthält weitere Attribute, deren Werte je nach dem Verwendungszweck festgelegt werden (Strukturbeispiel):

  • Name: Schlüsselparameter, eindeutige Namenstypbezeichnung. Für FQDNs oder RRs, deren Namenstyp in der verwendeten Version nicht definiert ist, wird null ausgegeben. Umgekehrt können Namenstypen, die in der verwendeten Version nicht definiert sind, nicht als Neuwert für die Funktionen "create" oder "update" verwendet werden.
  • Beschreibung
  • Non-Terminal-FQDN-Attribut: Boolean-Wert, der festlegt, ob FQDNs dieses Typs untergeordnete FQDNs (Subdomains) haben können oder nicht
  • Hostnamens-Attribut: Boolean-Wert, der festlegt, ob FQDNs dieses Typs als Standard-Hostnamen (Host-Kontext) verwendbar sind
  • DHCP-Hostnamens-Attribut: Boolean-Wert, der festlegt, ob FQDNs dieses Typs als per DHCP vergebene Standard-Hostnamen verwendbar sind
  • RAD-Attribut: numerischer Wert, der festlegt, ob FQDNs dieses Typs als Reverse Adress Domains verwendbar sind. Momentaner Wertebereich:
    • 0: trifft nicht zu
    • 1: ENUM-RAD (unter e164.arpa.)
    • 4: IPv4-RAD (unter in-addr.arpa.)
    • 6: IPv6-RAD (unter ip6.arpa.)
  • Wildcard-Attribut: Boolean-Wert, der festlegt, ob FQDNs dieses Typs als Wildcards verwendbar sind (‘*’ als Label)
  • Permission-Name für Namenstyp: globale Berechtigung zur Datenmodifikation von FQDNs dieses Namenstyps

• Resource-Record-Typ (RRT): Typbezeichnung eines RRs bzw. RR-Sets. Ist datenbank- bzw. systemintern zusätzlich einer erweiterten Typdefinition (DBRT) zugeordnet. Diese ist pro WebAPI-Version fest vorgegeben und kann im Objekttypindex abgefragt werden. Der DBRT enthält zusätzlich zum RRT weitere Unterattribute, die je nach dem Verwendungszweck pro WebAPI-Version festgelegt werden (Strukturbeispiel):

  • Beschreibung
  • FQDN-Namenstyp: DBNT-Name des Owner-FQDNs (null, wenn FQDN-Namenstyp in der verwendeten Version nicht definiert ist)
  • Ziel-Namenstyp: DBNT-Name des Ziel-FQDNs im Datenfeld, falls RRT namensbasiert ist (null, wenn Ziel-Namenstyp in der verwendeten Version nicht definiert ist)
  • FQDN-Eindeutigkeit: Boolean-Wert, der festlegt, ob der FQDN systemweit eindeutig sein soll, dh. wenn TRUE, darf ihm nur genau ein RR bzw. RR-Set zugeordnet werden.
  • RR-Ziel ist rückwärts eindeutig: Boolean-Wert. Wenn TRUE, ist das Vorkommen des Ziel-Datums (Ziel-Adresse oder Ziel-FQDN oder Zieldatentext) unter allen RRs dieses DBRTs einmalig und damit die umgekehrte Zuordnung des Ziel-Datums zum Owner FQDN (Rückwärtsabbildung, bzw. Reverse Mapping) eindeutig. In diesem Fall wird bei adressbasierten RRs der zugehörige PTR-RR automatisch behandelt.
  • RR ist Einzel-Record-Typ: Boolean-Wert. Legt fest, ob RR-Sets erlaubt sind oder nicht.
  • RR-Typbezeichnung: RR Type aus DNS-RR. Jedes RR-Set ist genau einem DBRT und genau einem RRT zugeordnet. D.h. es ist nicht möglich, RRs ein und desselben RR-Sets unterschiedlichen DBRTs (aber desselben RRTs) zuzuordnen.
  • Permission-Name für DBRT-Zugriff: falls angegeben, dürfen RRs dieses DBRTs nur von entsprechenden Rolleninhabern modifiziert werden. Falls nicht angegeben (Basiszugriff), gilt der Adresszugriff als gleichwertig zum DBRT-Zugriff; für nullbasierte DBRT ist der DBRT-Zugriff dann unbeschränkt.

• REF-FQDN: datenbank- bzw. systeminterner, nullbasierter RR-Typ, der zur Abbildung eines Endpunktes einer namensbasierten RR-Kette dient. (Diese Definition ist erforderlich, um die referentielle Datenintegrität zu bedienen.) Die unterhalb dieses Owner-FQDNs liegende RR-Kette (also die Fortsetzung nach diesem Endpunkt) ist nicht mehr in der NetDB vorhanden, weil sie auf einer anderen (fremden) DNS-Datenbank verwaltet wird.

• RR-Kette: rekursive Folge mehrerer RRs, die durch die Verzeigerung von Ziel-FQDN des referenzierenden RR auf den Owner-FQDN des referenzierten RRs (RR-Ziel) entsteht.

  • Im einfachsten Fall besteht die Kette aus nur einem RR (adressbasiert oder nullbasiert).
  • In der Kette sind Kombinationen möglich, d.h. sie kann sich theoretisch aus Teilketten zusammensetzen.
  • Eine Teilkette endet bei den RRs, deren
    • RR-Ziel eine Adresse ist (adressbasierter RR, alle RRs dieser Teilkette haben Adressauflösung)
    • RR-Typ ‘REF-FQDN’ ist (nullbasierter RR, kein RR dieser Teilkette hat Adressauflösung)
    • RR-Ziel weder Adresse noch FQDN enthält (nullbasierter RR, kein RR dieser Teilkette hat Adressauflösung)

• Adressauflösung: besteht für einen RR, wenn dessen RR-Kette systemweit (nicht DNS-weit bzw. weltweit) an einer Adresse (als Ziel) endet.

Funktionalität und Struktur der Zugriffsrechte für Resource Records und FQDNs

Grundbegriffe für Berechtigungen

• Betreuer: Inhaber eines NetDB-Benutzerkontos. An dieses sind in der NetDB bestimmte Rechte gebunden, die der Betreuer ausüben darf.
• Adresszugriff: Voraussetzung zur Datenmodifikation (Eintragen/Ändern/Löschen) von RRs, die Adressauflösung haben.
  • betreuerbasierter Adressraum: Netzbereichsbetreuer haben Zugriff auf alle regulären IP-Adressen der Subnetze ihrer Netzbereiche (BCDs)
  • Inhaber der Rolle “dns.regular_addrspace_user” haben Zugriff auf alle regulären IP-Adressen der NetDB
  • Inhaber der Rolle “dns.reserved_addrspace_user” haben Zugriff auf alle reservierten IP-Adressen der NetDB
• Namensraum-Zugriff: Voraussetzung zur Datenmodifikation von RRs und FQDNs. Diese ist für FQDNs bzw. RRs erfüllt, wenn der FQDN im erlaubten Namensraum des Betreuers liegt. Je nach Kontext gilt als Namensraum
  • der Domain-Namensraum einer BCD (bereichsbasierter Namensraum): dieser ist für regulär adressbasierte RRs bindend und ergibt sich
    • aus den Domains (nicht zonenübergreifend), die der Gruppe dieser BCD zugeordnet sind, falls der Betreuer Gruppenmitglied ist, zzgl.
    • aus den Domains, die dem Betreuer per Rollen zugeordnet sind
  • der Domain-Namensraum eines Betreuers (betreuerbasierter Namensraum): dieser ist für FQDNs, namensbasierte und nullbasierte sowie reserviert adressbasierte RRs bindend und ergibt sich
    • aus den Domains (nicht zonenübergreifend) aller Gruppen, denen der Betreuer angehört zzgl.
    • aus den Domains, die dem Betreuer per Rollen zugeordnet sind
• DBRT-Zugriff: Voraussetzung zur Datenmodifikation von RRs eines bestimmten DB-Recordtyps. Kann je nach DBRT-Definition entweder durch Adresszugriff als Betreuer (Basiszugriff) erfüllt sein oder als explizite Berechtigung per Rollenzuordnung zu diesem DBRT. Für nullbasierte RRs ist der DBRT-Zugriff unbeschränkt, falls der Basiszugriff erfüllt ist (keine Rollenzuordnung zu diesem DBRT vorhanden).
• DBNT-Zugriff: Voraussetzung zur Datenmodifikation von FQDNs eines bestimmten DB-Namenstyps. Ist durch Basiszugriff oder durch explizite Berechtigung per Rollenzuordnung zu diesem DBNT erfüllt.

Schema der Berechtigungslogik für Datenmodifikationen

	Vorgang	adressbasierte RRs	namensbasierte RRs	nullbasierte RRs
RR	Löschen	Bedingungen für das RR-Ziel: Adresszugriff Bedingungen für den Owner-FQDN: [keine]	Bedingungen für das RR-Ziel: Adresszugriff auf mind. 1 Adresse, die am Ende der RR-Kette des (alten) Ziel-FQDNs liegt. Wenn keine Adressauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette des (alten) Ziel-FQDNs liegt DBRT-Zugriff Bedingungen für den Owner-FQDN: [keine]	Bedingungen für das RR-Ziel: DBRT-Zugriff Bedingungen für den Owner-FQDN: Namensraum-Zugriff
	Ändern (alt)
	Ändern (neu)	Bedingungen für das RR-Ziel: Adresszugriff DBRT-Zugriff Bedingungen für den Owner-FQDN: Namensraum-Zugriff Diese Bedingung entfällt, wenn alter und neuer Owner-FQDN identisch sind und durch Adressänderung sowohl für den alten als auch für den neuen bereichsbasierten Namensraum kein Zugriff besteht. Adresszugriff auf alle Adressen aller bereits vorhandenen adressbasierten RRs mit diesem Owner-FQDN	Bedingungen für das RR-Ziel: Adresszugriff auf mind. 1 Adresse, die am Ende der RR-Kette des (neuen) Ziel-FQDNs liegt. Wenn keine Adressauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette des (neuen) Ziel-FQDNs liegt DBRT-Zugriff Bedingungen für den Owner-FQDN: Namensraum-Zugriff Diese Bedingung entfällt, wenn alter und neuer Owner-FQDN identisch sind und Adresszugriff auf mind. 1 Adresse besteht, die am Ende der RR-Kette des alten und neuen Ziel-FQDNs liegt. Falls RR-Set bereits vorhanden: Adresszugriff auf mind. 1 Adresse, die am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt. Wenn keine Adressauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt.
	Eintragen	Bedingungen für das RR-Ziel: Adresszugriff DBRT-Zugriff Bedingungen für den Owner-FQDN: Namensraum-Zugriff Adresszugriff auf alle Adressen aller bereits vorhandenen adressbasierten RRs mit diesem Owner-FQDN	Bedingungen für das RR-Ziel: Adresszugriff auf mind. 1 Adresse, die am Ende der RR-Kette des (neuen) Ziel-FQDNs liegt. Wenn keine Adressauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette des (neuen) Ziel-FQDNs liegt. DBRT-Zugriff Bedingungen für den Owner-FQDN: Namensraum-Zugriff Falls RR-Set bereits vorhanden: Adresszugriff auf mind. 1 Adresse, die am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt. Wenn keine Adressauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt.
FQDN mit RR	Löschen	Bedingungen für alle RR-Ziele: DBRT-Zugriff Bedingungen für den Owner-FQDN: wenn adressbasierte RR-Sets unter diesem Owner-FQDN vorhanden: Adresszugriff auf alle Adressen dieser RR-Sets; FQDN muss auch im bereichsbasierten Namensraum liegen (Gruppen der BCDs aller Adressen dieser RR-Sets). sonst: wenn keine adressbasierten RR-Sets, aber namensbasierte RR-Sets unter diesem Owner-FQDN vorhanden: Adresszugriff auf mind. 1 Adresse, an der eine RR-Kette dieser RR-Sets endet sonst: wenn ausschließlich RR-Sets ohne Adressauflösung unter diesem Owner-FQDN vorhanden: Namensraum-Zugriff für mind. 1 Ziel-FQDN, an dem eine RR-Kette dieser RR-Sets endet DBNT-Zugriff Namensraum-Zugriff
	Ändern
FQDN ohne RR	Löschen	DBNT-Zugriff Namensraum-Zugriff
	Ändern
	Eintragen

Grundsätzliches zur internen Datenmodellierung von FQDNs und Resource Records

Abbildung

Die nachfolgende Modellierung basiert auf der gängigen Notation einer DNS-Zonendatei (s. a. https://en.wikipedia.org/wiki/Zone_file), ausgehend von den Feldern der ersten Zeile der folgenden Tabelle:

name	ttl	record class	record type	record data
Die Felder sind von links nach rechts gruppierbar nach 'name', 'record class', 'record type'. 'record class' ist konstant und hat immer den Wert 'IN'. Zusammengefasst ergibt sich:
name	ttl, record class, record type			record data
Weiter zusammengefasst ergeben sich nach Weglassen der Konstanten 'record class' 3 Felder, welche nach den ersten beiden gruppiert werden können:
name	ttl, record type			record data
Die letzte Zusammenfassung ergibt die Grundlage für das nachfolgende Schema mit one-to-many-Relationen zwischen den gruppierbaren Feldern
Owner	Set			Destination (Target)
FQDN der zugeordneten RR-Set-Gruppe	RR-Set (mit Typ und TTL) der zugeordneten Gruppe von RR-Zielen			RR-Ziel (je nach Typ mit Zieladresse, Ziel-FQDN, Datentext)

Schema der Modellierung

Owner	1:n	Set		1:n	Destination (Target)		RR nach Zielart	Adressauflösung via RR-Kette?
Owner Name		TTL	Type		RR Data
					unstrukt. Daten	Ziel-Daten [*R]
fqdn		ttl_1	type_1			dst_addr_1	adressbasiert	TRUE
						dst_addr_2
						...
		ttl_2	type_2		data_1	dst_fqdn_1	namensbasiert	TRUE or FALSE
					data_2	dst_fqdn_2
					...	...
		ttl_3	type_3		data_1		nullbasiert	FALSE
					data_2
					...
--- Beispiele ---
kit.edu		86400	A			129.13.40.10	adressbasiert	TRUE
		86400	AAAA			2a00:1398:9:fd10::810d:280a
		86400	MX		10	scc-mailin-cn-01.scc.kit.edu	namensbasiert	TRUE
					10	scc-mailin-cs-01.scc.kit.edu
		3600	SOA		hostmaster.kit.edu 4671 10800 1800 2592000 600	dns1.kit.edu	namensbasiert	TRUE
		3600	NS			dns1.kit.edu	namensbasiert	TRUE
						dns2.kit.edu
						dns1.belwue.de
						dns3.belwue.de
		3600	TXT		"google-site-verification=***"		nullbasiert	FALSE
					"MS=***
					"v=spf1 ip4:129.13.231.64/26 ~all"

Wesentliche funktionale Eigenschaften bei FQDN- und RR-Modifikationen

• FQDNs
  • haben eine Container-Funktion für untergeordnete FQDNs (Subdomains), wenn der Non-Terminal-FQDN-Attributwert true ist
  • können (als neuer Unter-FQDN bzw. Subdomain) unter einen anderen übergeordneten, bereits vorhandenen FQDN verschoben werden
  • haben eine Container-Funktion für RR-Sets (können zugeordnete RR-Sets enthalten, können aber auch leer sein, sog. empty non-terminal FQDNs)
  • können als Ziel-FQDN (von anderen RR-Zielen) referenziert werden, wenn sie selbst mindestens ein RR-Set enthalten
• RR-Sets
  • haben eine Container-Funktion für RR-Ziele (müssen zugeordnete RR-Ziele enthalten; können also nicht leer sein)
  • können zu einem anderen, bereits vorhandenen FQDN verschoben werden, solange es dort noch kein typgleiches RR-Set gibt.
• RR-Ziele
  • können nicht in ein anderes RR-Set verschoben werden. Für diese Operation ist Löschen und Neueintragen des RRs erforderlich. Wird das alte RR-Set dadurch leer, wird es automatisch mitgelöscht.

Zusätzliche interne Typisierung

Die Bindung von FQDNs und RRs an zusätzliche, intern vordefinierte Typen (DBNT bzw. fqdn_type, DBRT via record_type) ist erforderlich, um das Vorkommen von

• unerlaubten bzw. unerwünschten Untereinträgen oder Label-Werten bei FQDNs
• unerlaubten Kombinationen oder Duplikaten von Owner FQDN, RR Type, RR Data bei RRs

zu verhindern. Dabei steuern die jeweiligen Attribute der internen Typen diese Wirkungsweise. Beispiele:

• Labels von Reverse Adress Domains (Basisname ‘rad’) dürfen nur die Zahlen 0..255 (v4-RAD) bzw. nur die Werte 0..9 und a..f (v6-RAD) beinhalten.
• Labels von Service-FQDNs (Basisname ‘meta’) können als erstes Zeichen einen Underscore haben.
• Labels von Domain/Host-FQDNs (Basisname ‘dflt’) dürfen keinen Underscore enthalten.
• Ziel-FQDNs von SRV-RRs müssen ausschließlich Domain/Host-Einträge sein, die ihrerseits wiederum ein A/AAAA-RR-Set haben.

Schematischer Aufbau der DB-Namenstypen (DBNT, fqdn_type)

Die nachfolgenden Beispiele dienen ausschließlich der prinzipiellen Veranschaulichung und haben keinen Anspruch auf Korrektheit. Verbindliche Daten müssen über den Objekttyp- bzw. Funktionsindex der WebAPI abgefragt werden.

Titel	Name (versionsspezifisch)	Basisname (intern)	Non-Terminal-FQDN-Attribut	Hostnamens-Attribut	DHCP-Hostnamens-Attribut	RAD-Attribut	Wildcard-Attribut
--- Beispiele ---
Domain/Host	domain	dflt	TRUE	TRUE	FALSE	0	FALSE
Alias	alias	alias	TRUE	FALSE	FALSE	0	FALSE
IPV4-Reverse-Adress-Domain	rad_ipv4	rad	TRUE	FALSE	FALSE	4	FALSE

Schematischer Aufbau der DB-Record-Typen (DBRT, record_inttype)

Die nachfolgenden Beispiele dienen ausschließlich der prinzipiellen Veranschaulichung und haben keinen Anspruch auf Korrektheit. Verbindliche Daten müssen über den Objekttyp- bzw. Funktionsindex der WebAPI abgefragt werden.

RRT-Name	FQDN-Eindeutigkeit	FQDN-Namenstyp	Ziel-Namenstyp	Ziel-Adresstyp	Einzel-Record-Typ	Ziel-Rückwärtseindeutigkeit
--- Beispiele ---
AAAA	FALSE	domain		6	TRUE	TRUE
		domain		6	FALSE	TRUE
		domain		6	FALSE	FALSE
MX	FALSE	domain	domain		FALSE	FALSE
CNAME	TRUE	alias	domain		TRUE	FALSE
PTR	TRUE	rad_ipv4	domain		TRUE	FALSE