Funktionalität und Struktur der Zugriffsrechte

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

  • FQDN: Fully Qualified Domain Name (DNS-Namensobjekt, z.B. myhost.mydomain.de)
  • Domain: allgemeiner Begriff für Non-Terminal-FQDN’s. Eine Domain kann Untereinträge enthalten, die wiederum Domains sein können oder auch keine weiteren Untereinträge haben. Letztere werden als Terminal-FQDN’s bezeichnet und typischerweise für Hosteinträge verwendet; s. “DB-Namenstyp-Definition” weiter unten.
  • Resource Record (RR) bzw. -Satz (RR-Set): Basiseinheit der DNS-Einträge. Ein RR-Satz besteht aus mehreren RR’s desselben Typs und desselben Owner-FQDN’s. Ein RR setzt sich aus folgenden Bestandteilen zusammen:
    • Owner FQDN: wichtigster Schlüsselparameter des RR-Sets. “Owner” steht für die primäre Zuordnung 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. Systemintern wird dieser Parameter durch einen erweiterten, DB-internen Recordtyp ersetzt, der neben dem RRT zusätzliche Attribute enthält (s. “DB-Record-Typ-Definition” weiter unten)
    • 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 muß. Standardmäßig erben alle RR’s einer Zone deren TTL, wenn kein expliziter Wert festgelegt wird. Die TTL ist für alle RR’s innerhalb eines Sets gleich.
    • RR Data: Datenfeld, auch als RR-Ziel bezeichnet. Je nach RRT handelt es sich hier um
      • Zieldaten:
        • eine IP-Adresse (adreßbasierter RR)
        • einen 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 RR’s oder desselben RR’s 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 vorbehalten ist
  • DB-Namenstyp (DBNT): datenbank- bzw. systeminterner FQDN-Typ, der weitere Attribute enthält, die je nach dem Verwendungszweck festgelegt werden (Strukturbeispiel):
    • Name: Schlüsselparameter, eindeutige Namenstypbezeichnung
    • Beschreibung [optional]
    • Non-Terminal-FQDN-Attribut: Boolean-Wert, der festlegt, ob FQDN’s dieses Typs untergeordnete FQDN’s (SubDomains) haben können oder nicht
    • Hostnamens-Attribut: Boolean-Wert, der festlegt, ob FQDN’s dieses Typs als Standard-Hostnamen vorgesehen sind
    • DHCP-Hostnamens-Attribut: Boolean-Wert, der festlegt, ob FQDN’s dieses Typs als per DHCP vergebene Standard-Hostnamen vorgesehen sind
    • RAD-Attribut: numerischer Wert, der festlegt, ob FQDN’s dieses Typs als Reverse Adress Domains vorgesehen 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.)
    • Permission-Name für Namenstyp: globale Berechtigung zur Datenmanipulation von FQDN’s dieses Namenstyps
  • DB-Record-Typ (DBRT): datenbank- bzw. systeminterner RR-Typ, der weitere Attribute enthält, die je nach dem Verwendungszweck festgelegt werden (‘links’ bzw. ‘rechts’ beziehen sich auf die Leserichtung der RR-Standard-Notation, Strukturbeispiel):
    • Name: Schlüsselparameter, eindeutige DBRT-Bezeichnung
    • Beschreibung [optional]
    • linker Namenstyp: DBNT-Name des RR-Owner-FQDN’s
    • rechter Namenstyp: DBNT-Name des Ziel-FQDN’s im Datenfeld, falls zutreffend. Existiert alternativ (exclusiv-ODER) zu rechtem Adreßtyp.
    • rechter Adreßtyp: Typ der Ziel-IP-Adresse im Datenfeld, falls zutreffend. Existiert alternativ (exclusiv-ODER) zu rechtem Namenstyp.
    • linke 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
    • rechte Eindeutigkeit: numerischer Wert, der festlegt, inwieweit die Zieldaten eindeutig sein sollen. Momentaner Wertebereich:
      • 0: entspr. Grundbedingung lt. DNS-Richtlinien für:
        • RR-Sets, die weder namens- noch adreßbezogen sind: nur FQDN, RR-Typ, RR-Data eindeutig
        • adreßbezogene RR-Sets: nur FQDN, RR-Typ, Zieladresse eindeutig
        • namensbezogene RR-Sets: nur FQDN, RR-Typ, Ziel-FQDN, RR-Data eindeutig
      • 1: wie 0, und keine RR-Sets erlaubt (nur genau 1 RR pro Owner-FQDN und RR-Typ)
      • 2: wie 1, und rechte Seite muß systemweit eindeutig sein
    • RR-Typbezeichnung: RR Type aus DNS-RR
    • Permission-Name für DBRT-Zugriff: falls angegeben, dürfen RR’s dieses DBRT’s nur von entsprechenden Rolleninhabern manipuliert werden. Falls nicht angegeben (Basiszugriff), gilt der Adreßzugriff als gleichwertig zum DBRT-Zugriff; für nullbasierte DBRT ist der DBRT-Zugriff dann unbeschränkt.
    • Auto-DML auf FQDN: numerischer Wert, der festlegt, in welchem Umfang der Owner-FQDN automatisch durch die Eintragung oder Löschung des RR’s manipuliert wird. RR-Änderungen verstehen sich als Verschiebung des einzelnen RR’s gegenüber Sets, daher erfolgt hier ein “Merge”, dh. je nach Änderungskontext wird ggf. zum neuen (noch nicht vorhandenen) RR-Set ein neuer Owner-FQDN eingetragen oder der alte Owner-FQDN nach Löschen des alten RR-Sets gelöscht. Momentaner Wertebereich:
      • 0: keine automatische Manipulation (FQDN des passenden Namenstyps muß zum Eintragungszeitpunkt des ersten RR’s bereits vorhanden sein und wird nach dem Löschen des letzten RR’s nicht automatisch gelöscht)
      • 1: FQDN wird automatisch manipuliert über eine Stufe im Namensbaum (FQDN-Label bzw. flacher Name), gilt nur für Eintragen und Löschen
      • 2: FQDN wird automatisch manipuliert über mehrere Stufen im Namensbaum (rekursiv, d.h. mehrere FQDN-Labels möglich, solange diese in derselben DNS-Zone liegen.), gilt nur für Eintragen und Löschen
  • REF-FQDN: datenbank- bzw. systeminterner, nullbasierter RR-Typ, der zur Abbildung eines Endpunktes einer namensbasierten RR-Kette dient. Die unter dessen Owner-FQDN liegende RR-Kette (also die Fortsetzung nach diesem Endpunkt) ist nicht mehr im System vorhanden, weil sie auf einer anderen (fremden) DNS-Datenbank verwaltet wird.
  • RR-Kette: rekursive Folge mehrerer RR’s, die durch die Verzeigerung von Ziel-FQDN des referenzierenden RR auf den Owner-FQDN des referenzierten RR’s (RR-Ziel) entsteht.
    • Im einfachsten Fall besteht die Kette aus nur einem RR (adreßbasiert oder nullbasiert).
    • In der Kette sind Kombinationen möglich, d.h. sie kann sich theoretisch aus Teilketten zusammensetzen.
    • Eine Teilkette endet bei den RR’s, deren
      • RR-Ziel eine Adresse ist (adreßbasierter RR, alle RR’s dieser Teilkette haben Adreßauflösung)
      • RR-Typ ‘REF-FQDN’ ist (nullbasierter RR, kein RR dieser Teilkette hat Adreßauflösung)
      • RR-Ziel weder Adresse noch FQDN enthält (nullbasierter RR, kein RR dieser Teilkette hat Adreßauflösung)
  • Adreßauflösung: besteht für einen RR, wenn dessen RR-Kette systemweit (nicht DNS-weit bzw. weltweit) an einer Adresse (als Ziel) endet.

Grundbegriffe für Berechtigungen

  • Betreuer: Inhaber eines Benutzerkontos (Account). An diesen sind in der NetDB bestimmte Rechte gebunden, die der Betreuer ausüben darf.
  • Adreßzugriff: Voraussetzung zur Datenmanipulation (Eintragen/Ändern/Löschen) von RR’s, die Adreßauflösung haben.
    • Bereichsbetreuer haben Zugriff auf alle regulären IP-Adressen des Adreßbereiches
    • Inhaber der Rolle “dns.regular_addrspace_user” haben Zugriff auf alle regulären IP-Adressen des Systems
    • Inhaber der Rolle “dns.reserved_addrspace_user” haben Zugriff auf alle reservierten IP-Adressen des Systems
  • Namensraum-Zugriff: Voraussetzung zur Datenmanipulation von RR’s. Diese ist erfüllt, wenn Owner FQDN oder der übergeordnete FQDN (Parent Domain) des RR’s im erlaubten Namensraum des Betreuers liegt. Je nach Kontext gilt
    • der Domain-Namensraum eines Bereiches (bereichsbasierter Namensraum): dieser ist für regulär adreßbasierte RR’s bindend und ergibt sich
      • aus den Domains in der betreffenden Bereichsdomainliste, falls der Betreuer gleichzeitig Bereichseigentümer ist, zzgl.
      • aus den Domains/Zonen, die dem Betreuer per Rollen zugeordnet sind
    • der Domain-Namensraum eines Betreuers (betreuerbasierter Namensraum): dieser ist für namensbasierte und nullbasierte sowie reserviert adreßbasierte RR’s bindend und ergibt sich
      • aus allen Domains aller Bereiche, die dem Betreuer zugeordnet sind zzgl.
      • aus den Domains/Zonen, die dem Betreuer per Rollen zugeordnet sind
  • DBRT-Zugriff: Voraussetzung zur Datenmanipulation von RR’s eines bestimmten DB-Recordtyps. Kann je nach DBRT-Definition entweder durch Adreßzugriff als Betreuer (Basiszugriff) erfüllt sein oder als explizite Berechtigung per Rollenzuordnung zu diesem DBRT. Für nullbasierte RR’s ist der DBRT-Zugriff unbeschränkt, falls der Basiszugriff erfüllt ist (keine Rollenzuordnung zu diesem DBRT vorhanden).
  • DBNT-Zugriff: Voraussetzung zur Datenmanipulation von FQDN’s eines bestimmten DB-Namenstyps. Kann entweder durch “Auto-DML auf FQDN > 0” via DBRT-Definition (falls RR vorhanden) erfüllt sein oder durch explizite Berechtigung per Rollenzuordnung zu diesem DBNT.

Schema der Berechtigungslogik für Datenmanipulationen von RR’s und FQDN’s

Vorgang adreßbasierte RR's namensbasierte RR's nullbasierte RR's
RR Löschen
  • Bedingungen für das RR-Ziel:
    • Adreßzugriff
    • DBRT-Zugriff
  • Bedingungen für den Owner-FQDN:
    • [keine]
  • Bedingungen für das RR-Ziel:
    • Adreßzugriff auf mind. 1 Adresse, die am Ende der RR-Kette des (alten) Ziel-FQDN's liegt. Wenn keine Adreßauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette des (alten) Ziel-FQDN's liegt (über mehrere Stufen im Namensbaum)
    • 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:
    • Adreßzugriff
    • DBRT-Zugriff
  • Bedingungen für den Owner-FQDN:
    • Namensraum-Zugriff
    • Diese Bedingung entfällt, wenn
      • alter und neuer Owner-FQDN identisch sind und
      • durch Adreßänderung sowohl für den alten als auch für den neuen bereichsbasierten Namensraum kein Zugriff besteht.
    • Adreßzugriff auf alle Adressen aller bereits vorhandenen adreßbasierten RR's mit diesem Owner-FQDN
  • Bedingungen für das RR-Ziel:
    • Adreßzugriff auf mind. 1 Adresse, die am Ende der RR-Kette des (neuen) Ziel-FQDN's liegt. Wenn keine Adreßauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette des (neuen) Ziel-FQDN's liegt (über mehrere Stufen im Namensbaum)
    • DBRT-Zugriff
  • Bedingungen für den Owner-FQDN:
    • Namensraum-Zugriff
    • Diese Bedingung entfällt, wenn
      • alter und neuer Owner-FQDN identisch sind und
      • Adreßzugriff auf mind. 1 Adresse besteht, die am Ende der RR-Kette des alten und neuen Ziel-FQDN's liegt.
    • Falls RR-Set bereits vorhanden: Adreßzugriff auf mind. 1 Adresse, die am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt. Wenn keine Adreßauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt (über mehrere Stufen im Namensbaum).
Eintragen
  • Bedingungen für das RR-Ziel:
    • Adreßzugriff
    • DBRT-Zugriff
  • Bedingungen für den Owner-FQDN:
    • Namensraum-Zugriff
    • Adreßzugriff auf alle Adressen aller bereits vorhandenen adreßbasierten RR's mit diesem Owner-FQDN
  • Bedingungen für das RR-Ziel:
  • Adreßzugriff auf mind. 1 Adresse, die am Ende der RR-Kette des (neuen) Ziel-FQDN's liegt. Wenn keine Adreßauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette des (neuen) Ziel-FQDN's liegt (über mehrere Stufen im Namensbaum).
  • DBRT-Zugriff
  • Bedingungen für den Owner-FQDN:
  • Namensraum-Zugriff
  • Falls RR-Set bereits vorhanden: Adreßzugriff auf mind. 1 Adresse, die am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt. Wenn keine Adreßauflösung besteht: Namensraum-Zugriff auf mind. 1 FQDN, der am Ende der RR-Kette dieses RR-Sets (Owner-FQDN und RR-Typ) liegt (über mehrere Stufen im Namensbaum).
FQDN mit RR Löschen
  • Bedingungen für alle RR-Ziele:
    • DBRT-Zugriff
  • Bedingungen für den Owner-FQDN:
    • wenn adreßbasierte RR-Sets mit diesem Owner-FQDN vorhanden: Adreßzugriff auf alle Adressen dieser RR-Sets
    • sonst: wenn keine adreßbasierten RR-Sets, aber namensbasierte RR-Sets mit diesem Owner-FQDN vorhanden: Adreßzugriff auf mind. 1 Adresse, an der eine RR-Kette dieser RR-Sets endet
    • sonst: wenn ausschließlich RR-Sets ohne Adreßauflösung mit diesem Owner-FQDN vorhanden: Namensraum-Zugriff für mind. 1 Ziel-FQDN (über mehrere Stufen im Namensbaum), an dem eine RR-Kette dieser RR-Sets endet
    • DBNT-Zugriff
    • Namensraum-Zugriff (höchster Auto-DML-FQDN-Wert aller RR's wird zugrundegelegt)
Ändern
Eintragen s. RR -> Eintragen
FQDN ohne RR Löschen
  • DBNT-Zugriff
  • Namensraum-Zugriff
Ändern
Eintragen

RR-Struktur

Schematischer Aufbau der DB-Namenstypen

[ Eindeutig ] [ Eindeutig ]
Name Basisname Non-Terminal-FQDN-Attribut Hostnamens-Attribut DHCP-Hostnamens-Attribut RAD-Attribut
--- Beispiele ---
host:0100 host 0 1 0 0
domain:1000 domain 1 0 0 0
alias:0000 alias 0 0 0 0
rad:1004 rad 1 0 0 4

Schematischer Aufbau der DB-Record-Typen

[ Eindeutig ] [ Eindeutig ]
Name linker Namenstyp rechter Namenstyp rechter Adreßtyp linke Eindeutigkeit rechte Eindeutigkeit RR-Typbezeichnung
--- Beispiele ---
host:0100,:,602,AAAA host:0100 : 6 0 2 AAAA
domain:1000,host:0100,000,MX domain:1000 host:0100 0 0 0 MX
alias:0000,host:0100,011,CNAME alias:0000 host:0100 0 1 1 CNAME
rad:1004,host:0100,011,PTR rad:1004 host:0100 0 1 1 PTR

Schematischer Aufbau der Resource Records

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