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