Folgende Domain Einträge können via webadmin verarbeitet werden:

A ... Hostadresse (RFC 1035)
AAAA ... IPv6-Hostadresse (RFC 1886)
CNAME ... Alias
HINFO ... Hostinformationen (RFC 1035)
MX ... Mailexchanger (RFC 1035)
NS ... Nameserver (RFC 1035)
PTR ... Pointer für Reverse Lookup Zonen
RP ... Responsible Person (RFC 1183)
SOA ... Start of Authority
TXT ... Text
SRV ... Services Record (RFC 2782)

die wichtigsten davon sind bis heute:

• Address Record (A): ein Datensatz, in dem der eigentliche Zusammenhang zwischen Host-Name und IP-Adresse festgehalten ist, sodass man vom Namen auf die Adresse kommt.
• Name Server Record (NS): der zuständige Name-Server für eine bestimmte Domain wird in diesem Datensatz angegeben.
• Pointer Record (PTR): die Umkehrung des Address Records ermöglicht die Auffindung eines Host-Namens anhand einer IP-Adresse.
• Mail Exchange Record (MX): über MX-Records können Hosts definiert werden, die für andere Hosts Mail entgegennehmen, etwa weil sie nicht ständig mit dem Netz verbunden sind (die Auslieferung von Mail über UUCP benötigt beispielsweise diese MX-Records).
• Canonical Name Record (CNAME): für einen Host im Netz kann ein Alias vereinbart werden, etwa um den eigentlichen Rechner unter einem für bestimmte Zwecke aussagekräftigeren Namen ansprechen zu können. Der Canonical Name ist der eigentliche Name des Hosts.
• Host Information Record (HINFO): in der DNS-Datenbank können über diesen Datensatz Informationen über Rechnertyp und Betriebssystem des Hosts festgehalten werden.

Die Nameserver:

Service		Name		IP Adresse
Erster Name Server		ns1.comnect.at		195.69.180.2
Zweiter Name Server		ns2.comnect.at		195.69.180.3

Ihre bereits registrierten Domain-Namen können Sie selbstverständlich in webadmin übernehmen. Für den Umzug Ihrer Domains von Ihrem bisherigen Provider zu SIPit stellen Sie einen Domain-Transfer-Antrag. Mit diesem erteilen Sie Ihr Einverständnis, dass SIPit zukünftig das Hosting Ihrer Domains übernehmen soll, ohne dass die Domainnamen während der Zeit des Umzugs für Dritte verfügbar sind.

Folgender Ablauf gilt für einen Providerwechsel bei .at-Domains:

1. Umzugs-Auftrag
Sie erteilen SIPit einen Auftrag zum Umzug Ihrer Domain. Das Auftragsformular senden wir Ihnen gerne zu.

2. Information an bisherigen Provider
Sie informieren Ihren bisherigen Provider über Ihre Einwilligung zum bevorstehenden Umzug Ihrer Domain. Auch hierfür erhalten Sie von SIPit das entsprechende Formular.

3. Prüfung und Anfrage bei NIC
SIPit prüft anhand des ausgefüllten Formulars, ob der Umzug Ihrer Domains tatsächlich vom Domaininhaber bzw. administrativen Ansprechpartner (admin-c) beantragt wurde und leitet den Antrag dann an die NIC weiter.

4. Freigabe durch bisherigen Provider
Nach Eingang des Antrags bei der NIC bittet diese den bisherigen Provider um Zustimmung zur Kündigung. Wenn dem bisherigen Provider Ihre Einwilligung vorliegt, gibt er den Umzug frei.

5. Freigabe durch NIC
Sobald der bisherige Provider seine Zustimmung an die NIC.at weitergeleitet hat, gibt diese die Domain frei - der Umzug ist damit abgeschlossen.

Typische Probleme beim Umzug
Wenn ein Umzug scheitert, liegt es häufig daran, dass der bisherige Provider über die Einwilligung des Domain-Inhabers nicht rechtzeitig informiert wurde. Auch im Falle noch ausstehender Rechnungsbeträge wird der bisherige Provider seine Zustimmung zum Umzug verweigern.
Sie sollten sich deshalb in jedem Fall sofort nach Beauftragung des Domain-Umzugs mit Ihrem bisherigen Provider in Verbindung setzen und Unstimmigkeiten klären, bzw. evtl. Restzahlungen begleichen. Erteilt Ihr bisheriger Provider seine nachträgliche Zustimmung, kann der Umzug im Nachgang vollzogen werden.

Lokalisieren von SIP-Dienstleistungen

Üblicherweise werden Server anhand des Hostnamens angegeben, die Aufösung des Standortes wird anhand eines DNS Eintrages realisiert der eine eindeutige Zuordung zulässt ohne die Flexibilität der Standortwahl einzuschränken. Genau so verhält es sich auch mit Services, wodurch eine flexible Trennung zwischen dem eigentlichen Service und der Maschine auf der das Service angeboten wird, erzielt werden kann.

Im RFC3263 wird DNS als die bevorzugte Methode für die Bestimmung der IP Adresse, des Ports und der Transportmethode des Hosts spezifiziert, zu dem ein SIP-Request geschickt werden soll. Die Methode muß festgestellt werden, da SIP-Requests via UDP, TCP, SCTP oder TLS over TCP für einen sicheren, verschlüsselte Session gesendet werden können.

Lokalisierung von SIP Servern

Für die Lokalisierung von Diensten innerhalb einer Domain (oder eines Hosts) existieren sog. Service Records (SRV) im DNS. Ein SRV Record ist vergleichbar dem MX-Record für die Mailzustellung. Ein SRV Record ist allerdings wesentlich allgemeiner gehalten.

Über einen SRV-Record können für einen spezifischen Dienst, ein oder mehrere Server angegeben werden. In der Regel werden diese Angaben auf Ebene der Domain hinterlegt. Der Service wird dabei über den Namen angesprochen unter dem er bei IANA registriert wurde. Damit keine Verwechslung mit realen Namen möglich ist, wird diesem sogenannten Servicenamen ein Unterstrich vorangestellt.

Das verwendete Transportprotokoll wird ebenfalls mit vorangestelltem Unterstrich als Subdomain angehängt, und damit wird eine Anfrage an das DNS mit Recordtyp SRV durchgeführt.

ein SRV Record (RFC2782) sieht folgendermassen aus:

  "_Service._Proto.Name TTL Class SRV Priority Weight Port Target"

zum Beispiel:

  "_sip._udp.sample.com 43200 IN SRV 10 10 5060 proxy.sample.com."

• Das Service ist SIP.
• Die Transportmethode ist UDP. Es kann aber auch TCP, SCTP oder TLS sein.
• Die Cachezeit beträgt 12 Stunden (43.200 Sekunden)
• Die Kategorie ist IN
• Der Typ ist SRV.
• Die Priorität ist 10. Bei mehreren SRV Records legt die Priorität die Reihung der Proxyabfrage fest. Niedrige Werte werden zuerst abgefragt.
• Das Gewicht ist 10. Mit mehreren SRV Records gleicher Priorität, stellt das Gewicht proportional fest, wie häufig ein Proxy abgefragt wird.
• Der Port ist 5060.
• Die FQDN des Proxies ist calvin.comnect.at und wird - wie im DNS gefordert - mit einem Punkt abgeschlossen.

eine Abfrage liefert somit beispielsweise:

  dig srv _sip._udp.sipit.at
  ; <<>> DiG 9.2.4 <<>> srv _sip._udp.sipit.at
  ;; global options:  printcmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13558
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
  
  ;; QUESTION SECTION:
  ;_sip._udp.sipit.at.            IN   SRV
  
  ;; ANSWER SECTION:
  _sip._udp.sipit.at.     86400   IN   SRV  0 0 5060 calvin.comnect.at.
  
  ;; AUTHORITY SECTION:
  sipit.at.               15462   IN   NS   ns2.comnect.at.
  sipit.at.               15462   IN   NS   ns1.comnect.at.
  
  ;; ADDITIONAL SECTION:
  ns1.comnect.at.         84197   IN   A    195.69.180.2
  ns2.comnect.at.         84197   IN   A    195.69.180.3
  
  ;; Query time: 38 msec
  ;; SERVER: 213.129.226.2#53(213.129.226.2)
  ;; WHEN: Tue Sep 20 15:46:04 2005
  ;; MSG SIZE  rcvd: 141
                                                                                

Als Ergebnis erhält man ein oder mehrere SRV-Records die letztlich auf einen Host verweisen der den geforderten Dienst (hier SIP als UDP Dienst) unter dem angegebenen Port (hier 5060) anbieten.

In der Zone müssen entsprechende Records hinterlegt werden:

  $ORIGIN sample.com.
  ;        Prio Weight Port  Server
  _sip._udp   IN  SRV  0    0      5060  proxy.sample.com.
  _sip._tcp   IN  SRV  0    0      5060  proxy.sample.com.
  _sips._tcp  IN  SRV  0    0      5060  proxy.sample.com.
                                                                                

Auswahl des Transport Protokolls

Ein SIP-Client kann als Transportprotokoll entweder UDP oder TCP verwenden. Zusätzlich ist eine sichere Variante des Protokolls (SIPS) über TLS und TCP definiert. Der Client muß eine Möglichkeit haben herauszufinden welche Protokolle von einem SIP Server angeboten werden, damit er anschließend eine entsprechende SRV-Abfrage durchführen kann. Für diesen Zweck werden laut RFC3263 NAPTR-Records verwendet. Diese werden hierbei, anders als bei der e164-Rufnummernauflösung über ENUM, mit dem Flag "s" verwendet, und stellen damit ein Mapping auf die oben angegebenen SRV Records dar.

Ein NAPTR Record (RFC3403) sieht folgendermassen aus:

  "domain TTL Class NAPTR order pref flags service regexp target"

zum Beispiel:

  "sample.com. 43200 IN NAPTR 6 5 "s" "SIP+D2U" "" _sip._udp.sample.com."

• Die Domain nach der abgefragt wird. Das ist der Teil auf der rechten Seite von sip: john.doe@sample.comDiese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
• Die Cachezeit beträgt 12 Stunden (43.200 Sekunden)
• Die Kategorie ist IN
• Der Typ ist NAPTR.
• "order" ist 6, ähnlich SRV Record
• "preference" ist 5, ähnlich SRV Record
• Das flag ist s. Das Flag s kennzeichnet den Eintrag als "terminalen" Eintrag mit Verweis auf einen SRV Record. Dies bedeutet, dass im nächsten Schritt eine Anfrage an den angegebenen Service Record gestelllt werden muß.
• Der Service ist SIP+D2U. Dieses spezifiziert das SIP-Protokoll via UDP. Andere mögliche Werte sind SIP+D2T für SIP over TCP, SIP+D2S für SIP over SCTP und SIPS+D2T für sicheres SIP over TLS over TCP. TLS over UDP wird nicht definiert.
• regexp ist hier leer und kann für komplexere Abfragen verwendet werden
• _sip._udp.sample.com ist das Ziel

Beispiel:

  $ORIGIN sample.com.
  ;            order pref flags service   regexp replacement
  @  IN NAPTR  10    50   "s"   "SIP+D2T" ""     _sips._tcp.sample.com.
     IN NAPTR  20    50   "s"   "SIP+D2U" ""     _sip._udp.sample.com.
     IN NAPTR  40    50   "s"   "SIP+D2T" ""     _sip._tcp.sample.com.