Skoči na vsebino

Preverite nastavitve DNS strežnikov

Zonemaster je orodje za preverjanje stanja domene in DNS strežnikov in je dosegljivo na naslovu https://zonemaster.register.si.

Namenjeno je tako strokovnjakom kot osebam, ki jih zanima ali so težave pri delovanju domene. Zonemaster pošlje poizvedbe na DNS strežnike, ki gostijo domeno in na strežnike nadrejene cone. Opravi niz testov, ki preverijo ustreznost nastavitev na DNS strežnikih in izdela razčlenjeno poročilo.

V kolikor v rezultatih poročila najdete NAPAKA ali KRITIČNO, domena ne bo vpisana v DNS, dokler se te napake ne odpravijo.

Pred vpisom domene v vrhnji strežnik za .si morajo biti strežniki za domeno ustrezno nastavljeni. Ustreznost nastavitev lahko preverite tako, da vpišete celotno domeno (torej domena.si) in IP-naslov primarnega domenskega (DNS) strežnika za to domeno (če se primarni strežnik nahaja v domeni, ki je že vpisana v vrhnji DNS, lahko uporabite tudi ime strežnika).

Režim preverjanja:

  • prvih 8 ur po vnosu domenskih strežnikov na 10 minut;
  • 8-24 ur po spremembi na 1 uro;
  • 24 ur po spremembi enkrat na dan.

Vsaka sprememba (dodajanje ali izbris) domenskih strežnikov ponastavi režim, tako da se domena preverja znova na 10 minut.

Ob uspešnem vpisu v vrhnji DNS dobi tehnični kontakt za domeno obvestilo. Prav tako dobi obvestilo v primeru napake pri preverjanju. V sporočilu najdete tudi podatek, kolikokrat je bila domena neuspešno preverjena in kdaj približno se bo preverjala naslednjič.

Zahteve za imenske strežnike

Testi se izvajajo za nabor zapisov NS in vse povezane IP naslove. Za vsako posamezno ime gostitelja se testi izvajajo za vsak par IP-naslov/protokol.

Minimalno število imenskih strežnikov

Delegacija mora vsebovati vsaj dva zapisa NS. Ni priporočljivo, da se razrešujeta na isti IP naslov.

Veljavna imena gostiteljev

Imena gostiteljev, uporabljenih za imenske strežnike, morajo ustrezati zahtevam za veljavna imena gostiteljev, opisanih v RFC 1123, razdelek 2.1.

Dosegljivost imenskih strežnikov

Imenski strežniki morajo odgovarjati na DNS poizvedbe prek protokolov UDP in TCP na vratih 53.

Avtoritativni odgovori

Imenski strežniki morajo odgovarjati avtoritativno za določeno cono. Odgovori na poizvedbe za določeno cono morajo imeti nastavljen »AA«-bit.

To bo preverjeno s poizvedbo po zapisu SOA določene cone brez nastavljenega »RD«-bita.

Omrežna razpršenost

Priporočljivo je, da so imenski strežniki v vsaj dveh topološko ločenih omrežjih.

Skladnost med glue podatki in avtoritativnimi podatki

Imenski strežniki, ki imajo IP naslove navedene kot glue, ti IP naslovi se morajo ujemati z avtoritativnimi zapisi A in AAAA za tega gostitelja.

Skladnost med delegacijo in cono

Nabor zapisov NS, ki jih strežejo avtoritativni imenski strežniki, se mora ujemati s tistimi, predlaganimi za delegacijo v nadrejeni coni.

Skladnost med avtoritativnimi imenskimi strežniki

Podatki, ki jih strežejo avtoritativni imenski strežniki določene cone, morajo biti skladni.

Vsi avtoritativni imenski strežniki morajo streči isti nabor zapisov NS za določeno domeno.

Vsi avtoritativni imenski strežniki morajo streči isti zapis SOA za določeno domeno.

Če se vsebina cone iz operativnih razlogov hitro spreminja, morajo biti serijske številke vsaj približno usklajene.

Brez okrnjenja referralov

Referrali iz imenskih strežnikov nadrejene cone se morajo prilegati v ne-EDNS0 UDP DNS paket. To pomeni, da DNS odgovor ne sme presegati 512 oktetov.

Zahtevani delegacijski podatki v referral odgovoru so popoln nabor zapisov NS in minimalni nabor potrebnih glue zapisov. Velikost odgovora se oceni kot odgovor na poizvedbo z največjim možnim QNAME.

Minimalni nabor potrebnih glue zapisov je:

  • en zapis A, če so vsi avtoritativni imenski strežniki in-bailiwick nadrejene cone; in
  • en zapis AAAA, če obstajajo avtoritativni imenski strežniki z IPv6 in so vsi taki strežniki in-bailiwick nadrejene cone.

Brez odprtega rekurzivnega resolverja

Avtoritativni imenski strežniki ne smejo zagotavljati rekurzivnih DNS storitev. To se preveri s pošiljanjem poizvedbe zunaj območja njihove avtoritete z nastavljenim »RD«-bitom.

Isti izvorni naslov

Odzivi avtoritativnih imenskih strežnikov morajo vsebovati isti izvorni IP naslov, kot je bil ciljni IP naslov začetne poizvedbe.

Zahteve za zapise Delegation Signer (DS)

Te zahteve morajo biti izpolnjene za podpisane delegacije, torej kadar je predložen eden ali več zapisov DS. Če zapisov DS ni, je delegacija nepodpisana in ti testi se ne izvajajo.

Oblika zapisa DS

Trust anchorji morajo biti predloženi kot popolni zapisi DS. To pomeni, da morajo vključevati key tag, algoritem ključa, vrsto zgoščevalnega algoritma (digest) in samo zgoščeno vrednost — vse z veljavnimi vrednostmi.

Podprti algoritmi za podpisovanje

Dovoljeni so naslednji algoritmi:

  • DSA/SHA-1 (type 3)
  • RSA/SHA-1 (type 5)
  • DSA/SHA-1 z NSEC3 (type 6)
  • RSA/SHA-1 z NSEC3 (type 7)
  • RSA/SHA-256 (type 8)
  • RSA/SHA-512 (type 10)
  • GOST R 34.10-2001 (type 12)
  • ECDSA Curve P-256 with SHA-256 (type 13)
  • ECDSA Curve P-384 with SHA-384 (type 14)
  • Ed25519 (type 15)
  • Ed448 (type 16)

Podprte vrste zgoščevanja

Dovoljene so vrste digest 1–4:

  • SHA-1
  • SHA-256
  • GOST R 34.11-94
  • SHA-384

Ujemajoči se zapisi DNSKEY

Ob času zahteve za vpis mora biti v podrejeni coni prisoten zapis DNSKEY, ki se ujema z vsakim zapisom DS.

Čeprav je v izjemnih operativnih okoliščinah možno dovoliti vpis zapisov DS brez ujemajočega se DNSKEY, je to močno odsvetovano. Medsebojno preverjanje vseh zapisov DS je zaščita, ki zmanjša tveganje, da bi domena v prihodnosti prešla v neveljavno stanje zaradi napačne rotacije podpisov.

Veljavnost RRSIG

Validacija cone mora biti mogoča z uporabo niza zapisov DS, ki so bili predloženi za vpis v nadrejeno cono. To testiramo s poizvedbo po apex zapisu SOA za domeno z nastavljenim »DO«-bitom in preverjanjem, ali je mogoče validirati njegove zapise RRSIG na podlagi predloženega nabora DS.