DNS-styring

Vi tilbyder alle GRATIS administration af primære og sekundære DNS-poster for domæner.

Primær domæneer et domæne, hvor DNS-poster registreres i vores system. Vores system fungerer således i det væsentlige som primær DNS-server for dette domæne. Dette er en almindelig løsning.

En sekundær domæneer en domæne, hvor vi ikke registrerer DNS-poster, men henter dem fra en anden DNS-server via AXFR. Systemet fungerer derfor som en sekundær DNS-server for denne domæne. For denne domæne indstilles kun den IP-adresse, hvorfra posterne skal hentes. Downloadperioden styres af oplysningerne i SOA-posten for den pågældende domæne (REFRESH, RETRY).

Vores DNS-servere understøtter fuldt udIPv6.

Understøttede typer af DNS-poster

Oplysninger om DNS-post af type A til angivelse af IPv4-adresse for det pågældende domænenavn.
En post af denne type indeholder IP-adressen for IPv4-protokollen. Disse adresser opbevares i en menneskeligt læsbar form (men overføres som et 32-bit tal i DNS-protokollen).
Eksempel på indstillinger for domænet og alle underdomæner:
Navn | TTL | Type | Data
(tomt navn) | 1800 | A | 81.2.199.30
* | 1800 | A | 81.2.199.30

AAAA

Oplysninger om DNS-posten af typen AAAA til angivelse af IPv6-adressen for det pågældende domænenavn.
Det drejer sig om en IPv6-adresse.
Eksempel på indstilling for domænet og alle underdomæner:
Navn | TTL | Type | Data
(tomt navn) | 1800 | AAAA | 2a02:2b88:1:4::40
* | 1800 | AAAA | 2a02:2b88:1:4::40

Oplysninger om DNS-posten af typen NS, som vi bruger til at delegere underdomænet til en anden DNS-server.
Denne type post bruges til at angive en liste overautoritative DNS-serverefor det pågældende domæne. Der angives servernavne (dvs. deres domænenavne), ikke IP-adresser. Hvis en enhed ønsker at oprette forbindelse til en autoritativ DNS-server for et domæne, finder den først alle NS-poster for det søgte domæne på en DNS-server på et højere niveau, vælger en af dem og finder IP-adressen til den. Først derefter kan der oprettes en kommunikationsforbindelse via DNS-protokollen.

CNAME

Oplysninger om DNS-posten af typen CNAME, der bruges til at indstille et alias for et andet domænenavn.
CNAME-postenangiver, at det pågældende domæne eret alias foret andet domæne i den forstand, at de har fælles DNS-poster (ikke fælles webindhold osv.).
Eksempel på opsætning af CNAME-post:
Navn | TTL | Type | Data
www1.domena.tld | 1800 | CNAME | cilovadomena.tld

Oplysninger om DNS-posten af typen MX til angivelse af servere, som e-mails til det pågældende domæne skal leveres til.
Posten angiver domænenavnetpå den mailserver, som e-mails til dette domæne skal leveres til. Foran servernavnet angivesen prioritet, som har betydning, hvis der er flere MX-poster for et navn. I så fald afprøves serverne i stigende prioritetsrækkefølge (dvs. serveren med det laveste nummer har den højeste prioritet). Hvis serveren ikke svarer, afprøves den næste. Den anden og alle efterfølgende servere, hvis de er til stede, fungerer sombackup-mailservere.
Eksempel på indstillinger for vores mailservere:
Navn | TTL | Type | Data
(tomt navn) | 1800 | MX | 1 wes1-mx1.wedos.net
(tomt navn) | 1800 | MX | 1 wes1-mx2.wedos.net
(tomt navn) | 1800 | MX | 10 wes1-mx-backup.wedos.net

SPF

For at beskytte mod misbrug af domænenavnet mod spam er det en god idé at indstille SPF-posten
. Du finder en detaljeret beskrivelse med vejledning i vidensdatabasen.

SRV

Oplysninger om DNS-posten af typen SRV, der bruges til at angive servere, der leverer bestemte tjenester til den pågældende domæne. Et eksempel er routing af telefonopkald via SIP-protokollen.
SRV-poster har mange andre anvendelser. F.eks. bruger Microsoft Windows dem til at finde domænecontrollere, og andre protokoller (XMMP, Kerberos, LDAP osv.) bruger dem også.
Eksempel på SRV-rekordindstilling:
Navn | TTL | Type | Data (prioritet, vægt, portnummer, vært)
_sip._udp.domæne.tld | 1800 | SRV | 10 100 5060 sip.domæne.tld

CAA

Oplysninger om CAA-registrering (Certification Authority Authorization), som gør det muligt at specificere, hvilke certificeringsmyndigheder der kan udstede certifikater for et domænenavn.
Med andre ord, hvis der ikke er angivet nogen CAA-post for domænet, kan enhver CA uden begrænsninger udstede et certifikat for domænet. I modsat fald kan kun den CA, der er angivet i CAA-posten, udstede et certifikat for domænet.
Eksempel:
Navn | TTL | Type | Data
domena.tld | 1800 | CAA | 0 issue „letsencrypt.org“

TXT

TXT-poster for forskellige tekstværdier (f.eks. registrering af SPF-regler) skrives uden anførselstegn i starten og slutningen.
Eksempel:
Navn | TTL | Type | Data
(tomt navn) | 1800 | TXT | „v = spf1 IP4: 64.170.98.0/26 IP6: 2001: 1890: 1112: 1 :: 0/64 -all“

TLSA

Oplysninger om DANE/TLSA-typen (DNS-Based Authentication of Named Entities/TLS Association).
DANE-protokollen, der implementerer DNS-typen TLSA, blev udviklet med det formål at øge sikkerheden ved verifikation af oprindelsen af det certifikat, der udstedes af serveren. DNS TLSA-posten bestemmer tjenestecertifikatet for en kombination af data – FQDN, protokol og port, som tilsammen udgør postens præfiks. Ved hjælp af TLSA-posten er det således muligt at verificere, om certifikatet er blevet ændret på vejen mellem modtageren og afsenderen.
Du kan finde mere information om TLSA-posten i vores vidensdatabase.

SSHFP

Oplysninger om SSHFP-typen. Oplysningerne bruges til at verificere serverens offentlige nøgleaftryk efter oprettelse af en forbindelse via SSH-protokollen.
Når der oprettes en forbindelse til serveren via SSH-protokollen, sker der en autentificering mellem klienten og serveren, således at serveren efter oprettelse af forbindelsen sender klientens offentlige nøgleaftryk til klienten, så klienten kan verificere serverens identitet.
Forbindelsens troværdighed og sikkerhed afhænger således af, om brugeren rent faktisk sammenligner den fingeraftryk, som serveren har leveret, med den forventede fingeraftryk af serverens offentlige nøgle.
Med indførelsen af DNS SSHFP-posten (RFC 4255) opstår der en ny måde at autentificere SSH-klienter på ved at sammenligne det fingeraftryk, der leveres af serveren, med det fingeraftryk, der er gemt i DNS-zonen for serverens FQDN. Ved sammenligningen skal alle parametre i SSHFP-posten stemme overens – algoritmen, der er brugt til at generere nøglen, algoritmen, der er brugt til at generere nøgleaftrykket, og endelig selve nøgleaftrykket.
Brug af DNS SSHFP giver kun mening, hvis denne post er signeret med DNSSEC-teknologi, så det er garanteret, at den pågældende post ikke kan forfalskes.
Du kan finde mere information om SSHFP-posten og hvordan du konfigurerer den i vores videnbase.

Avancerede systemfunktioner

kompletní historie změn– změny v nastavení, přidání, změna a smazání záznamů
justerbar tilladelse/forbudmod download af zoner via AXFR (udgående AXFR)med mulighed for at angive specifikke IP-adresser, der kan downloade zonen for den pågældende domæne
import af dataved overgang fra andre DNS-servere – download via AXFR fra en anden server, upload af zonefil eller manuel indtastning
kopiering af domæner– du kan nemt oprette et nyt domæne ved at kopiere et andet (med alle poster og indstillinger)
administrationaf reverse-registreringer(for kunder af vores serverhostingtjenester)

Under forberedelse

DNSSEC-understøttelse forgeneriske domæner. (DNSSEC tilbydes foreløbig kun for CZ- og EU-domæner)

Ytterligere oplysninger findes i vidensdatabasen:VEDOS DNS