10/19/2014
DNS, DHCP i upravljanje adresama
Mr Nenad Krajnović
Katedra za telekomunikacije, ETF
E-mail: [email protected]
DNS – Domain Name Service
• IP adresa je neophodna da bi bila moguća
komunikacija između računara na Internetu
• Lakše je pamtiti imena nego gomilu brojeva
• DNS – uspostavlja vezu između
alfanumeričkog imena i IP adrese i obrnuto
• Kako formirati tabelu sa imenima i IP
adresama?
2
Primer DNS tabele
;
; ETF.BG.AC.RS domain definitions
;
$TTL 86400
@
IN
SOA
NS.ETF.BG.AC.RS. HOSTMASTER.ETF.BG.AC.RS. (
2003090800 ; serial
10800
; refresh
3600
; retry
604800
; expire
86400 ) ; minimum – negative caching
; --- DNS
DNS--ovi za zone ETF.BG.AC.RS. (Elektrotehnicki fakultet Univ. u Beogradu)
IN
NS
NS.ETF.BG.AC.RS.
IN
NS
ZMAJ.ETF.BG.AC.RS.
IN
NS
NS.RCUB.BG.AC.RS.
IN
NS
AVALA.YUBC.NET.
; --- MX zapis za razmenu poste za domen ETF.BG.AC.RS
IN
MX
10
zmaj.etf.bg.ac.rs.
; --- web server za domen ETF.BG.AC.RS
IN
A
147.91.8.17
rtr1
svarog
kondor
proxy
vhost1
www
IN
IN
IN
IN
IN
IN
A
A
A
A
A
CNAME
147.91.8.1
147.91.8.4
147.91.8.8
147.91.8.10
147.91.8.17
vhost1.etf.bg.ac.rs.
3
1
10/19/2014
Formiranje DNS tabele
• U doba ARPANETARPANET-a se tabela ručno
formirala (održavana od strane SRISRI-NIC
NIC--a)
• Problemi sa ovakvim rešenjem:
– Opterećenje host
host--a sa koga su preuzimani podaci
– Kolizija po pitanju imena (isto ime za više
računara)
– Konzistentnost podataka u tabeli
• Problem rešen uvođenjem DNSDNS-a 1983.
(autor Paul Mockapetris – RFC 1034, 1035)
4
Formiranje DNS tabele
• U početku se ručno unosili podaci
• Sledeći korak je bio korišćenje
uporednih tabela (spreadsheets
(spreadsheets)) za
formiranje zone filefile-a
• Namenski pisani skriptovi za formiranje
zone filefile-a
5
Organizacija FQDN prostora
• Nije praktično čuvati sve IP adrese i sve nazive (FQDN) na
lokalnom DNS serveru (zbog potrebne memorije, update
update-a, brzine odziva, cene,...)
• Hijerarhijska organizacija
• Nezavisno od adresne hijerarhije
• DNS je globalno distribuirana, skalabilna, pouzdana,
labavo povezana, dinamička baza podataka
• Sastoji se od tri komponente:
– Domenskog prostora
– Servera koji čine taj prostor raspoloživ
– Klijenata ((resolvers
resolvers)) koji šalju upite serverima u vezi domena
6
2
10/19/2014
Šta nudi DNS?
• DNS predstavlja mehanizam
pretraživanja globalne baze podataka
sa p
podacima o nazivima domena i IP
adresama
7
DNS – globalno distribuirana baza
• Podaci se lokalno formiraju ali su
globalno raspoloživi
postojij računar kojij sadrži sve DNS
• Ne p
podatke sa celog Interneta
• DNS upit ((lookup
lookup)) može da postavi bilo
koji računar na Internetu
• U cilju poboljšanja performansi, dobijeni
odgovori se lokalno keširaju
8
DNS – labavo povezana baza
• Svaka zona ima svoj serijski broj koji se
povećava kada dođe do promene
• Promene u zoni se distribuiraju na osnovu
vremenskog parametra postavljenog od
strane administratora ili automatski
• Vreme čuvanje keširanih podataka zavisi od
vremenskog parametra postavljenog od
strane administratora (u zone filefile-u)
9
3
10/19/2014
DNS - skalabilnost
• Veličina baze ničim nije ograničena
• Jedan server može da čuva podatke za samo
nekoliko imena a može i za par desetina
miliona imena (ne preporučuje se)
• Nema ograničenja po pitanju broja upita koje
može da obradi jedan server (tipično 2.000 –
4.000 a može i preko 25.000 upita)
• Upiti se distribuiraju između master i slave
servera
10
DNS - pouzdanost
• Podaci koji se unose samo na master
serveru se distribuiraju do jednog ili više
slave servera tako da se kod svih
servera nalaze isti podaci
• Odgovore na upite ravnopravno mogu
da pruže i master i slave serveri
11
DNS – dinamička baza
• Svaki podatak u bazi se može i dinamički
menjati
• Na Internetu se stalno menjaju podaci u DNS
tabelama
• Dinamičke promene su moguće samo na
master serveru
• Promena podataka na master serveru odmah
inicira kopiranje tih podataka na sve slave
servere
12
4
10/19/2014
root
gTLD
.com
ccTLD
.org
.uk
.net
.org.rs
.org.
rs
domen
.ni.ac.rs
.ni.ac.
rs
.rs
.de
.ac.rs
.ac.
rs
.co.rs
.co.
rs
.bg.ac.rs
.bg.ac.
rs
.ns.ac.rs
.ns.ac.
rs
domen
.fon.bg.ac.rs
.fon.bg.ac.
rs
domen
.etf.bg.ac.rs
.etf.bg.ac.
rs
.grf.bg.ac.rs
.grf.bg.ac.
rs
www.etf.bg.ac.rs
147.91.8.17
147.91.8.1
7
13
Organizacija domenskog prostora
• Hijerarhijska
• Svako ime na prethodnoj slici
p
predstavlja
j domen/poddomen
p
• Svaki domen sadrži određeni broj RR
(Resource Record)
Record)
• Primeri RRRR-a: address (A), pointer
(PTR), mail exchange (MX), name
server (NS), start of authority (SOA)
14
Zone, delegacija, domeni
• Glavni domeni se dele na zone koje
možemo nazivati poddomenima
j
• Zone su administrativne tvorevine koje
sadrže podatke o delu domenskog
prostora
• Nadležnost nad zonama se dodeljuje u
hijerarhijskom smislu (delegacija
domena)
15
5
10/19/2014
DNS serveri
• DNS serveri su serveri koji sadrže
podatke o domenima i koji odgovaraju
p
na DNS upite
• Odgovori master i slave servera se
smatraju za autoritativne dok se
odgovori dobijeni od rekurzivnih
(caching
caching)) smatraju za neautoritativne
odgovore
16
Kako radi DNS
DNS??
• Klijent šalje upit lokalnom
Root name
.COM
server
name serveru da bi dobio
name
server
IP adresu odredišta
autoritativni
• Lokalni server šalje prvi
odgovor
upit root name serveru a
posle rekurzivno šalje
CISCO.COM
Local DNS
upite DNS serverima dok name server
server
ne dođe do servera koji
ima potrebne podatke
NE autoritativni
caching
odgovor
• Lokalni server šalje
Q: What is the address
konačni odgovor klijentu i
for www.cisco.com?
te podatke pamti u cache
cache-u zbog sledećih upita
A: 161.44.10.9
17
18
6
10/19/2014
Sadržaj zone filefile-a
;
; ETF.BG.AC.RS domain definitions
;
$TTL 86400
@
IN
SOA
NS.ETF.BG.AC.RS. HOSTMASTER.ETF.BG.AC.RS. (
2003090800 ; serial
10800
; refresh
3600
; retry
604800
; expire
86400 ) ; minimum – negative caching
; --- DNS
DNS--ovi za zone ETF.BG.AC.RS. (Elektrotehnicki fakultet Univ. u Beogradu)
IN
NS
NS.ETF.BG.AC.RS.
IN
NS
ZMAJ.ETF.BG.AC.RS.
IN
NS
NS.RCUB.BG.AC.RS.
IN
NS
AVALA.YUBC.NET.
; --- MX zapis za razmenu poste za domen ETF.BG.AC.RS
IN
MX
10
zmaj.etf.bg.ac.rs.
; --- web server za domen ETF.BG.AC.RS
IN
A
147.91.8.17
rtr1
svarog
kondor
proxy
vhost1
www
IN
A
IN
A
A
A
IN
IN
IN
IN
147.91.8.1
A
147.91.8.4
147.91.8.8
147.91.8.10
147.91.8.17
CNAME
vhost1.etf.bg.ac.rs.
19
Resource Records (RR)
• Zone file se sastoji iz zaglavlja i resource
record--a
record
zmaj.etf.bg.ac.rs.. 3600 IN A 147.91.8.62
zmaj.etf.bg.ac.rs
labela
ttl
klasa
uvek
IN
tip
podatka
podatak
20
Primer
;
; ETF.BG.AC.RS domain definitions
;
$TTL 86400
@
IN
SOA
NS.ETF.BG.AC.RS. HOSTMASTER.ETF.BG.AC.RS. (
2003090800 ; serial
10800
; refresh
3600
; retry
604800
; expire
86400 ) ; minimum – negative caching
zaglavlje
; --- DNS
DNS--ovi za zone ETF.BG.AC.RS. (Elektrotehnicki fakultet Univ. u Beogradu)
IN
NS
NS.ETF.BG.AC.RS.
IN
NS
ZMAJ.ETF.BG.AC.RS.
IN
NS
NS.RCUB.BG.AC.RS.
IN
NS
AVALA.YUBC.NET.
; --- MX zapis za razmenu poste za domen ETF.BG.AC.RS
IN
MX
10
; --- web server za domen ETF.BG.AC.RS
IN
A
147.91.8.7
rtr1
svarog
kondor
zmaj
proxy
IN
IN
IN
IN
IN
A
A
A
A
A
147.91.8.1
147.91.8.4
147.91.8.8
147.91.8.62
147.91.8.10
zmaj.etf.bg.ac.rs.
RR
21
7
10/19/2014
Tipovi podataka u RRRR-u
• A – označava IP adresu host
host--a
• CNAME – označava alternativno ime
(canonical name)
name) za neki host
• HINFO – podaci o procesoru i OSOS-u,...
• MX – redni broj + naziv servera koji je
mail server
• NS – naziv servera koji je autoritativni
name server za taj domen
22
Tipovi podataka u RRRR-u
• TXT – proizvoljan tekstualni podatak za
objašnjenje prethodnih RRRR-a
• LOC – za unošenje geografskih
koordinata DNS servera (nije obavezno)
secret--wg.org. 3600 IN LOC ( 52 21 23.0 N 04 57 05.5 E 0m 100m 100m 100m )
secret
secret--wg.org. 3600 IN TXT “Demonstration and test zone”
secret
23
Zaglavlje zone filefile-a
• SOA – Starting of Authority – zapis koji
služi za predstavljanje podataka koji se
odnose na sam domen
24
8
10/19/2014
Zaglavlje zone filefile-a
Naziv domena
Master DNS server
E-mail adresa za kontakt
etf.bg.ac.rs. IN SOA NS.ETF.BG.AC.RS. HOSTMASTER.ETF.BG.AC.RS. (
2003090800 ; serial
10800
; refresh
3600
; retry
604800
; expire
86400 ) ; minimum – negative caching
Serijski broj
Timing parametri
25
Timing parametri u SOA zapisu
• Vreme se izražava u sekundama a novi
RFC--ovi su dozvolili i druge vremenske
RFC
veličine:
• h – časova
• M – minuta
• W - nedelja
26
Timing parametri u SOA zapisu
• Refresh – vreme osvežavanja; posle
isteka tog vremena će slave server da
p
proveri da li jje došlo do p
promene
sadržaja podataka na master serveru
• Retry – ako provera podataka na
master serveru nije uspela, posle isteka
ovog vremena će slave server ponovo
pokušati sa proverom podataka
27
9
10/19/2014
Timing parametri u SOA zapisu
• Expire – ako ponovni pokušaji provere
serijskog broja na master serveru nisu
p do isteka expire
p
uspeli
vremena,, tada
slave server proglašava svoje podatke
za ne važeće i odbacuje ih
• Poslednje polje u SOA zapisu je u
početku označavalo TTL ((Time
Time To Live)
Live)
– vreme koliko je odgovor validan
28
Timing parametri u SOA zapisu
• RFC 2308 doneo promenu tako da sada
poslednje polje u SOA zapisu
predstavlja vreme koliko treba čuvati
negativan
ti
odgovor
d
(odgovor
( d
da
d traženi
t ž i
podatak ne postoji)
• Default vrednost za TTL se zadaje pre
SOA zapisa sa:
$TTL 3h
29
Klasičan format zone filefile-a
;
; ETF.BG.AC.RS domain definitions
;
etf.bg.ac.rs. IN
SOA
NS.ETF.BG.AC.RS. HOSTMASTER.ETF.BG.AC.RS. (
2003090800 ; serial
10800
; refresh
3600
; retry
604800
; expire
86400 ) ; minimum – negative caching
; --- DNS
DNS--ovi za zone ETF.BG.AC.RS.
ETF BG AC RS (Elektrotehnicki fakultet Univ.
Univ u Beogradu)
etf.bg.ac.rs. 86400
IN
NS
NS.ETF.BG.AC.RS.
etf.bg.ac.rs. 86400
IN
NS
ZMAJ.ETF.BG.AC.RS.
etf.bg.ac.rs. 86400
IN
NS
NS.RCUB.BG.AC.RS.
etf.bg.ac.rs. 86400
IN
NS
AVALA.YUBC.NET.
; --- MX zapis za razmenu poste za domen ETF.BG.AC.RS
etf.bg.ac.rs. 86400
IN
MX
; --- web server za domen ETF.BG.AC.RS
etf.bg.ac.rs. 86400
IN
A
147.91.8.17
rtr1
svarog
kondor
zmaj
proxy
147.91.8.1
147.91.8.4
147.91.8.8
147.91.8.62
147.91.8.10
86400
86400
86400
90000
86400
IN
IN
IN
IN
IN
A
A
A
A
A
10
zmaj.etf.bg.ac.rs.
30
10
10/19/2014
Skraćeni format zone filefile-a
;
; ETF.BG.AC.RS domain definitions
;
$TTL 86400
@
IN
SOA
NS.ETF.BG.AC.RS. HOSTMASTER.ETF.BG.AC.RS. (
2003090800 ; serial
10800
; refresh
3600
; retry
604800
; expire
86400 ) ; minimum – negative caching
; --- DNS
DNS--ovi za zone ETF.BG.AC.RS. (Elektrotehnicki fakultet Univ. u Beogradu)
IN
NS
NS.ETF.BG.AC.RS.
IN
NS
ZMAJ.ETF.BG.AC.RS.
IN
NS
NS.RCUB.BG.AC.RS.
IN
NS
AVALA.YUBC.NET.
; --- MX zapis za razmenu poste za domen ETF.BG.AC.RS
IN
MX
10
zmaj.etf.bg.ac.rs.
; --- web server za domen ETF.BG.AC.RS
IN
A
147.91.8.17
rtr1
svarog
kondor
zmaj
proxy
IN
IN
IN
90000
IN
A
A
A
IN
A
147.91.8.1
147.91.8.4
147.91.8.8
A
147.91.8.62
147.91.8.10
31
Inverzni (reverse
(reverse)) DNS
• Inverzni DNS radi mapiranje IP adrese
u ime kada znate samo IP adresu
• Popunjava se na isti način kao i direktni
DNS
• Obavezan je za svaku IP adresu koja je
dodeljena nekom uređaju
32
Inverzni DNS
•
net edu com
arpa
google
ripe isi sun tislabs
in-addr
inmoon
www disi
www
ftp
ws2 ws1
•
•
•
•
•
•
•
•
IP v4
addresses
33
11
10/19/2014
Primer inverznog zone filefile-a
;
; 147.91.8.0 inin-addr.arpa definition
;
$TTL 86400
$ORIGIN 8.91.147.in8.91.147.in-addr.arpa.
@
IN
SOA
NS.ETF.BG.AC.RS. HOSTMASTER.ETF.BG.AC.RS. (
2003090800 ; serial
10800
; refresh
3600
; retry
604800
; expire
86400 ) ; minimum – negative caching
; --- DNS
DNS--ovi za zone 8.91.147.in
8.91.147.in--addr.arpa (Elektrotehnicki fakultet Univ. u Beogradu)
IN
NS
NS.ETF.BG.AC.RS.
IN
NS
ZMAJ.ETF.BG.AC.RS.
IN
NS
NS.RCUB.BG.AC.RS.
IN
NS
NS.BEOTEL.NET.
IN
NS
FON.FON.BG.AC.RS.
1
4
8
10
62
IN
IN
IN
IN
IN
PTR
PTR
PTR
PTR
PTR
rtr1.etf.bg.ac.rs.
svarog.etf.bg.ac.rs.
kondor.etf.bg.ac.rs.
proxy.etf.bg.ac.rs.
zmaj.etf.bg.ac.rs.
34
DNS zahtevi
• Za svaki domen moraju da postoje
minimalno dva DNS servera
• DNS serveri moraju da budu na
različitim mrežama
• Preporučljivo je da ima nekoliko DNS
servera
35
DHCP
• Dynamic Host Configuration Protocol
• Protokol koji omogućava dinamičko
dodeljivanja IP adrese i ostalih tehničkih
parametara računarima vezanim u
mrežu
• Definisan u RFCRFC-u 2131 a dopunjen u
RFC--u 3396
RFC
36
12
10/19/2014
Kako DHCP radi?
Pošalji mi
konfiguracion
e podatke
•DHCP server dinamički dodeljuje IP adresu
•Formira adresni pool da bi efikasnije koristio
adresni prostor i podržao mobilne korisnike
•Klijent šalje broadcast discovery paket na
lokalnu mrežu
LAN
•Više servera može da odgovori na taj upit
•Klijent bira onog koji je prvi odgovorio ili onog
koji ima najbolji odgovor
Evo tvoje konfiguracije:
IP adresa: 147.91.8.123
Subnet maska: 255.255.254.0
Default ruteri: 147.91.8.1, 147.91.8.3
DNS serveri: 147.91.8.6, 147.91.8.62
Lease time:
time: 5 dana
37
DHCP proces otkrivanja servera
klijent
Server 1
Server 2
• DHCP klijent šalje
DISCOVER pakete
broadcast--om na LAN
broadcast
• DHCP serveri odgovaraju
sa OFFER paketom koji
sadrži i informacije o
uslovima dobijanja resursa
• DHCP klijent na osnovu
toga bira server i šalje
REQUEST kao broadcast
• Izabrani DHCP server
odgovara sa ACK paketom
38
DHCP format paketa
OP Code (1)
HW Type (1)
HW Length (1)
HOPS (1)
Transaction ID (XID) (4)
Flags (2)
Seconds (2)
Client
Cli t IP Address
Add
(CIADDR) – (4)
Your IP Address (YIADDR) – (4)
Server IP Address (SIADDR) – (4)
Gateway IP Address (GIADDR) (4)
Client Hardware Address (CHADDR) – (16)
Server Name (SNAME) – (64)
Filename – (128)
DHCP Options (variable)
39
13
10/19/2014
DHCP format paketa
• OP Code – definiše tip poruke koja se
šalje:
– 1 – bootprequest
– 2 – bootpreply
• HW Type – definiše tip mreže i adrese:
– 1 – 10 Mbps ethernet
• HW Length – definiše dužinu HW
adrese: 6 – 10Mbps ethernet
40
DHCP format paketa
• HOPS – klijent ovde upisuje vrednost 0;
opciono se koristi kada postoji relay
agent
g
• Transaction ID (XID) – slučajan broj
izabran od strane klijenta; služi za
povezivanje poruka koje razmenjuju
klijent i server
41
DHCP format paketa
• Seconds – broj sekundi od trenutka kada je
klijent započeo proces dobijanja IP adrese;
popunjava klijent
• Flags – B – broadcast flag – klijent ga
postavlja na 1 ako ne može da prihvati
unicast paket pre nego što je dobio
kompletnu IP adresu; ako može da prihvati
unicast adresu tada je ovaj bit 0
B
All bits are zero
42
14
10/19/2014
DHCP format paketa
• CIADDR – IP adresa klijenta; upisuje je
klijent kada šalje poruku za obnavljanje
j
dodele p
postojeće
IP adrese
• YIADDR – IP adresa klijenta koju
upisuje DHCP server kada je dodeli
klijentu
43
DHCP format paketa
• SIADDR – IP adresa sledećeg DHCP
servera u nizu koga treba kontaktirati
• GIADDR – IP adresa relay agenta;
upisuje je relay agent ako postoji na
mreži a poruka prolazi kroz njega
• CHADDR – hardverska adresa klijenta
44
DHCP format paketa
• SNAME – ime DHCP servera; polje je
opciono, ako se ne koristi u njemu se
nalazi prazan string
• File – kada se šalje DHCPDISCOVER
poruka tada je prazno a ako je to
DHCPOFFER onda sadrži puno ime
direktorijuma
• Options – opciono polje
45
15
10/19/2014
DHCP Options
• Kroz opciona polja server šalje klijentu
razne parametre
• Do sada definisano preko 100 raznih
opcija
• Većina klijenata podržava oko 10 opcija
• Na raspolaganju su i opcije razvijene od
strane proizvođača
46
Zajedničke DHCP opcije
•
•
•
•
•
•
•
•
•
Lease time
Subnet mask
Default Routers
DNS servers
Domain name
Host name
WINS servers
NetBIOS Node Type
Client Identifier
Code: 51
Code: 1
Code: 3
Code: 6
Code: 15
Code: 12
Code: 44
Code: 46
Code: 61
47
Unapređenja u radu DNS servisa
• RFC 2136 – Dynamic DNS update
• RFC 1995 – Incremental zone transfer
• RFC 1996 – Notify
48
16
10/19/2014
49
50
51
17
10/19/2014
52
53
54
18
10/19/2014
55
56
57
19
10/19/2014
58
59
60
20
10/19/2014
61
62
Problemi sa DNS
DNS--om?
• Na prvi pogled, sve radi kako treba
• Problem je što prilikom slanja upita i dobijanja
odgovora ne postoji autentifikacija odgovora
• Klijent ne zna:
– Odakle je odgovor stvarno došao?
– Da li je server poslao tačne podatke?
– Da li je klijent primio ono što je server poslao?
63
21
10/19/2014
“Razbijanje” DNS servisa
• Bombardovanje klijenta lažnim odgovorima
– Pogađanje šta bi odgovor mogao da bude
• Presretanje paketa sa odgovorom i modifikovanje
– Funkcioniše samo ako je napadač blizu klijentu ili serveru
• Postavljanje lažnog servera za neku zonu
– Prevariti ostale servere da šalju upite lažnom serveru
• Lažiranje tabela rutiranja u cilju preusmeravanja
saobraćaja ka lažnim root DNS serverima ili DNS
serverima “interesantne” zone
64
Posledice...
• Klijent ne može da bude siguran da li je
stvarno dobio odgovor od nadležnog
DNS servera
• Klijent ne može da bude siguran da li je
dobio prave podatke u odgovoru
• Da li će klijent pristupiti traženom
serveru ili nekom lažnom?
65
Osnovni tipovi kripto zaštite
Dva osnovna sistema kripto zaštite:
zaštite:
• sistem sa simetričnim ključem - isti tajni
ključ se koristi i za šifrovanje i za
dešifrovanje podataka
• sistem sa asimetričnim ključem postoje dva ključa,
ključa, javni i tajni
66
22
10/19/2014
Sistem sa simetričnim ključem
isti tajni
ključ
izvorište
odredište


67
Sistem sa simetričnim ključem
• tajnost ključa utiče na sigurnost celog
sistema
• brz sistem što je veoma dobro sa
stanovišta performansi
• najčešće se koriste AES, 3DES i RC
RC--4
algoritmi
• dužina ključa utiče na kvalitet kripto
zaštite (današnji ključevi su 512
512--bitni i
više))
više
68
Sistem sa asimetričnim ključem
• problem tajnosti ključa u sistemu sa
simetričnim ključem razrešen je u
sistemu sa asimetričnim ključem
• ovde se koriste dva ključa,
ključa, javni i tajni
• javni ključ se slobodno distribuira dok je
tajni poznat samo vlasniku
• kombinacijom javnog i tajnog ključa
dobija se novi ključ koji se koristi za
šifrovanje
69
23
10/19/2014
Sistem sa asimetričnim ključem
• novodobijeni ključ se koristi za
šifrovanje kao i kod sistema sa
j
simetričnim ključem
• najčešće se koriste dva algoritma DiffieDiffieHellman (DH) i RivestRivest-Shamir
Shamir--Adlemen
(RSA)
• problem ako se neko ubaci u prenos
javnih ključeva (man
(man--in
in--the
the--middle)
middle)
70
DH algoritam
A
tajni
ključ
sa
lok.A
B
javni
ključ
sa
lok.B
javni
ključ
sa
lok.A
tajni
ključ
sa
lok.B
DH algoritam
za proračun
ključa
DH deljeni
tajni ključ
DH deljeni
tajni ključ

71
DH - man
man--inin-thethe-middle
A
M
B
72
24
10/19/2014
Transaction Signatures (TSIG)
• Defined in RFC 2845
• Computed on the fly
– Not in zone files
– Added to Additional Section of DNS replies
• Uses a shared secret and cryptographic
hash functions
– Currently HMACHMAC-MD5
• Timestamps prevent replay attacks
73
TSIG Overview
• "Lightweight" digital signature
• Cryptographic hash of:
– DNS query or answer
– Timestamp
– Shared secret
• Can be anything (within reason)
• Usually generated by dnssec
dnssec--keygen
• Use any tool that generates a base
base--64 encoded
string
74
Cryptographic Hash Functions
• Very strong checksums
• Mathematically proven to have almost no
chance of a collision:
– Different inputs cannot result in the same hash
value
• MD5 hash of ASCII character 1
– b026324c6904b2a9cb4b88d6d61c81d1
• MD5 hash of ASCII character 2
– 26ab0db90d72e28ad0ba1e22ee510510
75
25
10/19/2014
TSIG Validation
• Other party knows:
–
–
–
–
Contents of DNS packet
Choosen crypto hash algorithm
Time of day (UTC)
Shared Secret
• It can compute the TSIG hash value
– If the calculated hash matches the TSIG hash in
DNS packet, all is well
– If not, something has gone wrong:
• Wrong timestamp
• Different shared secret
76
TSIG Shared Secret
• An obvious vulnerability
– Has to remain secret
• Systems using TSIG should be under
one administrative & operational control
– Authenticating zone transfers?
• Many TLDs do this already
– Dynamic DNS update requests
• DHCP server, nsupdate
77
Timestamps and TSIG
• Transaction Signatures include a timestamp
– Prevents replay attacks
– Fuzz factor allows clocks to be out by up to a
few minutes
• Systems using TSIG should have their
clocks synchronised
– Should be running NTP anyway
– Run Secure NTP if you're paranoid
• Or buy an atomic clock!
78
26
10/19/2014
Why Secure DNS?
• The DNS is not secure!!!
• Servers could be lying
– Cache poisoning attacks
•
•
•
•
Servers could be spoofed
Answers could be tampered with
UDP makes these attacks simple
This is what Secure DNS is designed to
solve
79
What DNSSEC Does Not Do
• Prevent/thwart denialdenial-of
of--service attacks
• Stop name server compromises
– Buffer overflows
• Run BIND9 to stop that!
– Environment variable leakages
• Confidentiality of DNS data
– The DNS is public after all...
80
What Secure DNS Proves
• Data authenticity
– What was received was what the server sent
• Non
Non--repudiation
– Who/what signed the data
• Name server authenticity (in theory anyway)
– An answer for foo.example.com comes from the
genuine name servers for example.com
– Should be a chain of trust to the root
81
27
10/19/2014
The Chain of Trust
• Public key for example.com
example.com is signed with
the private key for .com
– .com “trusts” the example
example.com
.com key
• Public key for .com is signed with the
private key for the root
– Root zone “trusts” the .com key
• Everyone trusts the root zone’s public key
– Openly published
– Built in to every name server?
82
Validation Model
• Answer for www.
www.example.
example.com
com is provably
correct
– It’s been signed with the example
example.com
.com key
– Nobody could have tampered with the data
– The example.com
example.com key was signed by the key
for .com so the example.com
example.com key is OK
– The .com key was signed by the root key so
the delegation to com can be trusted too
– The root key is known and trusted by
everyone
83
Secure DNS Overview
• Defined in RFC2535 (DNSSEC)
– Raft of enhancements & extensions since then:
• RFC2536, RFC2537, RFC2931, RFC3007,
RFC3008,
RFC3008 RFC3090,
RFC3090 RFC3110,
RFC3110 etc
• Three new resource records:
– KEY, SIG and NXT
• Digital signatures of DNS data
• Industrial
Industrial--strength crypto:
– DSA, RSA, DiffieDiffie-Helman
84
28
10/19/2014
Public Key Cryptography
• Asymmetric encryption:
– RSA, DSA
– Public key and private key pairs
• Data encoded with public key can only be decoded
with the corresponding private key and vice versa
– Digital signatures
– Non
Non--repudiation
– Confidentiality
• Not used in DNSSEC!
• DNS is supposed to be public after all
85
DNSSEC Signatures
• Don't explicitly sign the actual DNS data
– Sign a hash of the data instead (SHA1)
– Less data to sign
• Names must be normalised to a canonical
form:
– All in lower
lower--case
– Fully qualified domain names
– Handled automatically by the zone signing tool
86
Signing a Zone
• 4 steps:
– Generate a key
– Get parent to sign zone key
– Incorporate parent's signature of zone key
– Sign the zone
• Can self
self--sign when the parent zone is not
DNSSEC--aware
DNSSEC
– e.g. self
self--sign example.com if com is not
signed
87
29
10/19/2014
Comments on Signed Zone
• Original ordering is lost
– So are any comments in the unsigned zone file
• Signed zone files are not human
human--readable
– "No user serviceable parts inside"
• Zone file is approximately 4 times bigger:
– Each RR has a SIG record
• And an NXT record which also has a SIG record
88
DNSSEC--aware queries
DNSSEC
• Note use of EDNS0 protocol
– Bigger DNS payloads/buffers
– Standard DNS q
query
y only
y has 512 byte
y
payload
• Prevents truncated responses and TCP retries
• DNSSEC
DNSSEC--aware answer is much bigger
– All the crypto stuff: SIGs, KEY
– Exceeds standard 512512-byte limit
• Trivial example with small key size
89
Setting Up Islands of Trust
• Root zone is signed! (15. July 2010.)
• Top
Top--level zones are not signed (yet)
– How to verify another DNSSEC
DNSSEC--aware zone?
• trusted
trusted-keys statement in named.conf
– Add another "trusted" zone's public key to server
– Zone's public key sent by some out
out--of
of--band means to
another DNSSEC
DNSSEC--aware name server
• eg. business partner, supplier, ASP
90
30
10/19/2014
Algorithms
• Implementations must support DSA
• RSA will become mandatory too
– No patent issues any more
g g
• DSA is faster than RSA at signing
– Takes longer to verify DSA signatures though
• Using >1 algorithm doesn't provide stronger
authenticity or "security"
– DNS data will be insecure if either key is
compromised
91
Sample Zone Signing Times
• Very modest hardware: 300 Mhz Pentium
– 100 Resource Records: 7.6 seconds
– 100,000 Resource Records: 7445 seconds
• Clearly linear
• Faster processors mean quicker signing
– Moore’s Law is a big help here
– Crypto hardware makes it even faster
• Zone signing is inherently parallelisable
– Multi
Multi--processor systems, clusters
92
SIG Verification Times
• Same modest hardware:
• Verifying 1 RRset, 1 SIG record
–
–
–
–
DSA
DSA--512: 108 ms
DSA-1024:
DSA1024 346 ms
RSA
RSA--512: 20 ms
RSA
RSA--1024: 110ms
• Same linear speed
speed--up with faster CPUs and/or
special crypto hardware (RSA chips)
• Validating a single SIG record can’t easily be
done in parallel
93
31
10/19/2014
Choosing Key Lengths
• Keys should be no bigger than parent
zone's key
– No point making them larger
s key "strength"
strength defines child
s
– Parent
Parent's
child's
"strength"
• Use larger key sizes for longlong-lived SIGs
– Beware of cryptanalysis
• Shorter key lengths make sense for short
short-lived signatures
– Typically valid for less than a week
94
Good Crypto Policy
• Don't use one key for everything
• Maybe:
– RSA to sign zone data
– DSA to sign child keys
• or:
– 768
768--bit keys for signing zone data
– 1024
1024--bit keys for signing child keys
• Change the keys "often enough"
95
Secure Dynamic Update
• Defined in RFC3007
– But not well explained in BIND9 documentation yet
• On
On--line signing
– BIND9 computes SIG and NXT records on the fly
– Dynamic update requests on signed zones
• Name server needs to read the file containing
the private key
• Storing private keys on
on--line is maybe not a
good idea
96
32
10/19/2014
DNSSEC Problems
• Bigger DNS packets
– Typically break 512
512--byte payload limit
– Need EDNS0 to allow bigger packets
• And
A d preventt truncated
t
t d responses => TCP retries
ti
• Zone files are bigger and unreadable
• Signed zones can't be altered by hand
• Signing means changes to admin procedures
– check
check--out, modify, check, check
check--in, sign zone
– Add/remove/change keys
97
• Parent zone should sign child zone's keys
– Implies close coupling of parent and child zones
– No bad thing, but too many broken/lame
delegations
• ~25%
25% in tightly controlled registries
• ??% in .com
– High levels of DNS cluelessness
• No toptop-level domains are signed yet
98
• Awkward registry/registrar relationships
– Who signs what and how?
• NXT records allow the whole zone to be
traversed
• Key rollover is hard (and recursive!)
• Root zone key is a weakness
99
33
10/19/2014
DNSSEC Future
• Some registries are planning to sign their
TLDs for real
– Projects under way in Netherlands, Sweden &
Germany
– RIPE's
intree
RIPE' in
i -addr.arpa
dd
t
– Verisign/NSI's plans for .com
• Further protocol extensions
– The DS (Delegation Signer) record
– Opt
Opt--in
• Alterations to NXT record
100
Tranzicija DNS servera
• Promena ISP
ISP--a podrazumeva i promenu IP
adresa na DNS serverima
• Da bi promene DNS servera bile vidljive u
svetu,, one moraju
j da se evidentiraju
j i u DNS
serverima za nadređene domene (.co.yu,
.org.yu, .com, .org, .net,...)
• Izmene nadređenih DNS tabela ne mogu da
se obave trenutno
• U zavisnosti od domena, na izmenu se može
čekati od par sati  do više dana ili nedelja 
101
Tranzicija DNS servera
• Promena IP adrese bez izmene
podataka u DNS tabelama i propagacije
tih informacija
j dovodi do p
prekida
komunikacije sa korisnicima
• Dva slučaja:
– Single homed sistem
– Multi homed sistem
102
34
10/19/2014
Tranz. DNSDNS-a – single homed sistem
• Korisnik ima samo jedan link ka
Internetu
j jjednog
g linka i aktivacija
j drugog
g g
• Gašenje
zahteva trenutne izmene IP adrese
servera (svaki ISP rutira samo za svoj
adresni prostor)
• Najčešće se DNS serveri nalaze kod
ISP--a
ISP
103
Tranz. DNSDNS-a – single homed sistem
• Prilikom prelaska na novog ISP
ISP--a
zadržavanje DNS hosting
hosting--a kod starog ISP
ISP--a
još neko vreme
• Prilikom promene linka i IP adresa, treba
izvršiti promenu podataka i u DNS tabelama
na starom DNS serveru
• U DNSDNS-u se sada nalaze IP adrese novog
ISP--a što omogućava normalan rad korisnika
ISP
104
Tranz. DNSDNS-a – single homed sistem
• Prekid u radu je minimalan – traje koliko
treba da se izmene iz DNS tabele
p
propagiraju
p g j p
po Internetu
• Bez obzira na preduzete mere, prekid u
vidljivosti servera na lokalnoj mreži ipak
postoji (za korisnike koji pristupaju sa
Interneta)
105
35
10/19/2014
Tranz. DNSDNS-a – single homed sistem
• Uspostavljeni su novi linkovi, serveri se
“vide” sa novim IP adresama ali DNS
j kod starog
g ISPserveri su i dalje
ISP-a
• Podizanje novih DNS servera kod
novog ISPISP-a
• Formiranje DNS tabela sa novim
podacima koji su validni
106
Tranz. DNSDNS-a – single homed sistem
• Prijava izmene DNS servera
nadređenom Internet registru za vaš
domen ((.co.rs,, .org.rs,
g , .com,, .org,
g,
.net,...)
• Tek po ažuriranju DNS tabela za
nadređeni domen (.co.rs, .org.rs, .com,
.org, .net,...) treba isključiti DNS kod
starog ISPISP-a
107
Tranz. DNSDNS-a – multi homed sistem
• Multi homed sistem znači da postoje
dva linka ka dva ISPISP-a
• Omogućava korisniku da samostalno
izvrši tranziciju DNSDNS-a bez prekida
komunikacije i bez zavisnosti od dobre
volje ISP
ISP--a
108
36
10/19/2014
Tranz. DNSDNS-a – multi homed sistem
• Scenario:
– Promena jednog od dva ISP
ISP--a čije adrese
koriste DNS serveri ili,
– Postojanje samo jednog ISP
ISP--a a
uspostavlja se i drugi link pri čemu se DNS
serveri postavljaju da koriste adresni opseg
novog ISPISP-a
109
Tranz. DNSDNS-a – multi homed sistem
• Uspostavljanje novog linka ka novom
ISP--u (za slučaj da ne postoje dva ISPISP
ISPa))
• Podizanje novih DNS servera koji će da
koriste adresni opseg novog ISPISP-a ili
dodavanje mrežnih kartica na postojeće
DNS servere sa novim IP adresama
110
Tranz. DNSDNS-a – multi homed sistem
• Upisivanje novih podataka u tabele
postojećih DNS servera (koji se vide na
starim IP adresama)
• Tim postupkom će sav saobraćaj ka
web i ostalim javnim serverima da
dolazi preko novog linka
• Prijava izmene DNS servera
nadređenom Internet registru
111
37
10/19/2014
Tranz. DNSDNS-a – multi homed sistem
• Po dobijanju potvrde da je izvršena
izmena u nadređenim DNS tabelama,
j
može da se isključe
stari DNS serveri ili
da se ukinu stare IP adrese i link ka
starom ISPISP-u
• Tranzicija DNSDNS-a i IP adresa praktično
prolazi bez prekida servisa za korisnike!
112
BIND
• Najpoznatija i najčešće korišćenja
implementacija DNS servisa je BIND
• Autori: Internet Systems Consortium
(ISC)
• Softver može besplatno da se preuzme
sa njihovog web sajta www.isc.org
113
Knjige
• DNS and BIND, 5th edition
edition,, Paul Albitz,
Cricket Liu, O’Reilly, may 200
2006
6.
• DHCP,
DHCP A Guide to Dynamic TCP/IP
Network Configuration, Barry Kercheval,
Prentice Hall
114
38
10/19/2014
Utilities
• nslookup
– Command line utility za slanje upita DNS
serveru; postoji za Unix i za Windows
• dig
– Još jedan klijent
• ipconfig
– Klijent za Win XP koji omogućava da se
vidi kompletna konfiguracija
115
DNS, DHCP i upravljanje adresama
Mr Nenad Krajnović
Katedra za telekomunikacije, ETF
E-mail: [email protected]
39
Download

DNS - Katedra za telekomunikacije