저의 velog에 작성된 글은 모두 저의 주관적인 생각 및 이해를 바탕으로 작성된 글이므로
정확하지 않은 내용을 있을 수 있음을 알립니다.
[교재] Computer Networking : A Top-Down Approach 8th
오늘은 평소에 많이 사용하지만 대부분이 당연하게 생각하는 DNS에 대해 알아보겠습니다.
DNS (Domain Name System)은 복잡한 IP 주소를 사람이 사용하기 쉽게 별명을 정해주는 것이다.
보통 하나의 web site는 32 bit의 IP address를 갖는다. 하지만 IP address를 가지고 web에 접속하는 것은 만만치 않은 일이다. 길고 복잡하기 때문..
따라서 사람이 사용하기 쉽도록 velog.io, google.com과 같은 별명을 붙여 사용한다. 이것이 바로 DNS이다.
지구에는 굉장히 많은 server가 존재하기 때문에 scalable한 hierachy가 필연적이다. 이에 따라 복잡한 구조를 갖게 되는데, 이는 network core에서 하지 않고 network edge, 즉 end-system에서 함으로써 network core의 속도를 향상시킨디.
DNS는 다음과 같은 Services를 제공한다.
DNS는 결국엔 aliasing, 즉 별명을 붙여주는 기능을 하게 되는데, 위에서 말했듯이 web site의 IP 주소를 aliasing 하기도 하고, @naver.com과 같은 mail 주소를 aliasing 하기도 하고, 같은 회사의 여러 server를 하나의 이름으로 aliasing 하여 부하를 분산시켜 주기도 한다.
뒤에서 확인해보겠지만, DNS structure를 보면 centralize하지 않는다.
이유는 center DNS가 고장다면 모든 DNS가 down 되기 때문이다. 뿐만 아니라 center DNS의 traffic volume도 증가할 것이기 때문에 centralized database를 분산시켜줄 필요가 있다. 따라서 root DNS도 여러 개 실행하고, 각 root DNS에서 하위 DNS로 나뉜다.
사진을 보면 알 수 있듯이 DNS는 root DNS와 TLD(Top Level Domain)라고 불리는 DNS에서 하위 DNS로 계속 나뉜다. 위에서 언급했듯이 root DNS도 하나가 아니다.
어떤 사림이 google.com을 방문하고자 한다면, root DNS에서 .com이라는 TLD를 찾고, 그 하위 DNS에서 google.com을 찾게 된다.
DNS server가 고장나면 internet 접속에 관련된 모든 function을 사용하지 못한다. 따라서 security도 굉장히 중요하다고 볼 수 있다.
TLD server
TLD serversms authoritative server라고도 불린다.
.com, .org 등의 domain을 respose하며, 국가 또는 기관이 관리한다.
Local DNS server
엄격하게 따지면 Local DNS는 DNS hierachy에 속하지 않는다. 이 이유때문에 default name server라고도 불리며 ISP가 하나씩 가지고 있다. 실질적으로 host의 query가 진행되면 Local DNS server로 보내진다.
DNS resolution에는 두 가지 방식이 있다.
Iterated query
host의 query가 진행되면 가장 먼저 Local DNS로 보내지고 root DNS server에 물어본다. 그럼 DNS server는 "TLD DNS에 물어봐!"라는 response를 보내고 local DNSsms TLD DNS에, 또 그 이후에 sub DNS에 물어보는 것을 반복한다.
위의 사진은 worst case를 보여주는 것이고, 사실 TLD는 알고 있는 경우가 많아서 root DNS server는 거치지 않는다.
recursive query
쉽게 말해 relay 방식이다. iterated query와는 달리 response를 받고 다시 local DNS에 보내지 않고 query를 받은 DNS가 다음 DNS에 이어서 물어본다. 하지만 local DNS는 2~7 과정이 진행될 때까지 query를 기억하고 있어야하기 때문에 부담이 크다.
따라서 recursive query 방식보다 iterated query 방식이 일반적으로 사용된다.
host가 IP 주소를 바꾼다고 가정해보자. Internet은 매우 광범위하고 거리가 멀기 때문에 update 되는데 꽤 많은 시간이 걸린다. cache entries는 TTL(Time To Leave)라는 유효기간이 존재하기 때문에 시간이 초과되는 문제가 발생한다.
RR format : (name, value, type, ttl)
RR format에서 type은 4가지로 나뉜다.
if type = A
name = hostname
value = IP address
if type = NS
name = domain (ex. google.com)
value = hostname
if type = CNAME
name = alias name for canonical name
(www.ibm.com is really servereast.baclup2.ibm.com)
value = canonical name (real name)
if type = MX
value = name of mailserver associated with name
DNS는 비교적 간단한 data를 주고 받기 때문에 상대적으로 복잡한 TCP보다는 UDP를 사용한다. UDP는 unreliable data transfer 방식이기 때문에 데이터를 중간에 잊어버릴 수 있다.
따라서 identification을 이용해서 해당 identification의 reply가 오지 않으면 중간에 data를 잊어버린 것으로 간주하고 다시 전송한다.
flags는 해당 identification의 query, reply 구분한다.
새로운 DNS를 등록하는 과정이다.
networkutopia.com을 TLD server에 등록하기 위해서 NS, A type을 이용한다.
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
이 과정을 통해 TLD에 새로운 DNS를 등록할 수 있다.
DNS의 security는 매우 중요하다고 위에서 언급했다.
다음은 root DNS를 공격할 수 있는 3가지 방식을 소개한다.
DDoS attacks
많은 서버를 이용해서 엄청난 양의 query를 root DNS server로 보내면 root server가 정상적으로 작동하지 않을 수 있다. 하지만 현재까지 성공한 적이 없다고 알려져 있다. root DNS server는 유효하지 않은 query는 걸러내어 traffic filtering 기능이 있다.
Redirect attacks
DNS query의 source destination을 바꿈으로써 redirect 하는 attack 방식이다.
Exploit DNS for DDos
이는 1번 방식과 유사하지만 약간 다르다. 1번에서 DDos는 '많은 서버'를 이용해 공격한다라거 했다. Exploit DNS for DDos 에서는 '많은 서버'를 DNS로 삼아 attack 하는 방식이다. 이의 경우 root DNS server가 정상적인 query라고 보고 착각할 수 있을 것으로 보인다.
오늘은 DNS에 대한 전반적인 내용을 다뤄봤다. 양이 꽤 많았던 것 같다.. DNS는 다른 내용보다 조금은 친숙한 내용이라서 이해가 어렵지는 않을 것으로 기대한다. 지금까지는 client-server architecture에서 이뤄지는 내용을 소개했는데, 다음 시간에는 peer to peer architecture에서 이뤄지는 내용을 소개해보려고 한다. 수고하셨습니다 :)