DNS lahendusest üldiselt

Sissejuhatus

TODO

SOA

SOA (start of authority), aadressil http://www.ripe.net/ripe/docs/ripe-203 soovitatakse selliseid väärtusi

example.com.  3600  SOA  dns.example.com. hostmaster.example.com. (
                        1999022301   ; serial YYYYMMDDnn
                        86400        ; refresh (  24 hours)
                        7200         ; retry   (   2 hours)
                        3600000      ; expire  (1000 hours)
                        172800 )     ; minimum (   2 days)

kus

• MNAME -
• RNAME -
• Serial Number
• refresh - aega, mille järel slave kopeerib andmeid masterilt
• retry - aega, mille järel slave püüab kopeerida andmeid masterilt eelnenud ebaõnnestumise korral
• expire - kui kaua slave teenindab päringuid peale viimast masteriga toimuma pidanud kuid toimumata jäänud kontakti
• minimum -

Negative caching

Negative caching tähendab seda, et rekursiivne nimeserver, mida klient kasutab, mäletab NXDOMAIN vastuseid. Tundub, et selle mäletamise aeg on määratud vastava tsooni SOA kirje TTL väärtusega. Kummaline, et see ei ole määratud SOA kirje nö parameetrite osa juures oleva TTL väärtusega, st viimasel positsioonil oleva arvuga).

PTR

PTR delegeerimiseks on kaks võimalust

• classful - kasutatakse tavalist NS kirjete abil delegeerimist
• classless - kasutatakse CNAME kirjeid

Classless

Tulemus peaks olema nt selline (kahel real)

$ dig +short -x 192.168.105.100 ptr
100.98-127.105.168.192.in-addr.arpa.
nimi.auul.pri.ee.

Lisaks sobib töötamise kontrollimiseks kasutada mingeid online checkereid, nt http://ping.eu/rev-lookup/.

EDNS

Kasulikud lisamaterjalid

• EDNS - http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS

DNS võimendus

TODO

Kasulikud lisamaterjalid

• EDNS - http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS

Effective TLD

Kui mõni wildcard sertifikaati ei tööta, nt 2014 aasta kevadel Chromega, siis maksab kontrollida, ega seda effective tld nimekirjas pole, http://publicsuffix.org/list/effective_tld_names.dat. Tundub, et nimekirja idee on kaitsa brauseri abil, et kasutajat ei eksitataks *.com, *.riik.ee jt taoliste wildcard sertifikaatidega.

Kasulikud lisamaterjalid

• http://publicsuffix.org/list/

Domeeni nimeserverite asenduse protseduur

Olgu lähtepunktiks töötav nimesüsteem

• kõnealune domeen on domain-a.ee ja kasutatakse kahte nimeserverit, ns1.domain-b.ee ja ns2.domain-b.ee
• ülemine tsoon sisaldab NS delegation record'eid (ilma glue'ta kuna nimserverid on väljaspool kõnealust domain-a.ee domeeni)
• domeeni tsoonis on samuti korrektsed NS sissekanded

Eesmärk on lõpetada nimeserveri ns2.domain-b.ee kasutamine ja asuda kasutama selle asemel nimeserverit ns3.domain-b.ee.

Muudatuse protseduur võiks olla nt selline

• valmistada ette ns3.domain-b.ee peale korrektse sisuga tsoon (nt also-notify jms vahendite abil)
• lisada tsooni kolmas NS kirje (kolm kirjet on seal ajutiselt)
• oodata tsoonis olevate NS kirjete TTL selleks, et muudatused saaksid ära levida resolverite cache'idesse
• asendada ülemise taseme tsoonis ns2.domain-b.ee nimeserveriga ns3.domain-b.ee
• oodata ülemise taseme tsooni NS kirjete TTL
• eemaldada tsooni seest ns2.domain-b.ee NS kirje

Selline protseduur põhineb asjaolul, et ülemise taseme tsoonis on NS kirjed nö 'delegation' tüüpi, aga tsoonis endas on nad 'authoritative (pädev)' tüüpi. Kui resoleverid lahendavad tsooni nimesid, siis nad jõuavad domeeni nimeserverite juurde delegation kirjete abil, kuid usaldavad kasutada tsooni enda andmestikust teada saadud nimeservereid.

Muudatuse tegemise vältel saab olukorda jälgida nt aadressilt http://dnscheck.pingdom.com/?domain=domain-a.ee

Kasulikud lisamaterjalid

• TODO