본문으로 건너뛰기

브라우저가 Domain Name에서 IP를 얻는 과정

확인하고 싶은 것​

  1. 동일한 도메인 서버에 요청을 할때 IP가 캐시된다는 것을 확인하고 싶음.

서론​

FROM : 브라우저 렌더링 > Navigation 단계 > DNS

DNS를 왜 알아야하는가?! 지금 나의 상황에서는 브라우제 렌더링 과정을 더 잘 알기 위한 단계로서가 첫번째, 그리고 보안에 관심이 있는데 실은 악성 공격이 내 호스트 DNS 캐시가 위변조될 경우 내가 아무리 제대로된 도메인에 들어간다고 해도 다른 IP로 이동될 수 있기에... 가장 기본이 되는 DNS는 누구보다 잘 알아야한다.

해당 개념을 다시 정리하기 전 나의 머릿속은 아래와 같다. DNS에 쿼리를 하면 해당 도메인의 IP를 얻을 수 있다는 것. 만약 이전에 방문했다면 캐시에서 빠르게 값을 가지고 와서 응답 받는다는 것? 그리고 만약 요청 기록이 없다면 DNS 테이블에 요청을 해서 응답을 받고 그것을 캐싱한다는 것?! 결국 domain 입력에 ip가 출력이라는 것이다. 하지만 그 내부 구현을 잘 모르겠다. 이번에 정리해보려고 한다.

export const getIPFromDns = (domain: string): string => {
    if(~) return ip
    if(~) return ip
    if(~) return ip
    return ip
}

사전 지식​

  1. 노트북 DNS 서버는 자동 세팅됨 컴퓨터에 랜선을 꼽거나 와이파이를 연결하면 DNS Server는 자동으로 설정된다. (ISP 주체)

  2. ISP (Internet service Provider) ISP는 DNS의 IP를 호스트에 자동으로 연결해준다.

  3. ISP가 제공해준 DNS를 사용하지 않고 Public DNS 서버를 사용할 수 있다.

DNS 내부 구조​

blog.example.com. Right To Left로 읽어야한다. 이름을 살펴보자

. : Root com : Top-Level Domain example : Second-Level Domain blog : Sub Domain

위에 4개를 담당하는 서버는 각각 존재한다. 각 서버는 한단계 하위의 서버에 대한 의존성 있음.

IP를 얻는 과정

  • request : Root 네임서버로 질의
  • response : com으로 끝나니 TopLevel 목록 줄게
  • request : TL 네임서버로 질의
  • response : example로 끝나니 Second-Level 목록 줄게
  • request : SL 네임서버로 질의
  • response : blog로 끝나니 sub 목록 줄게
  • request : sub 네임서버로 질의
  • response : IP GET

DNS 등록 절차​

그림 그리자!

나 -> 등록 대행자 -> 루트 네임 서버 관리자 : ICANN 비영리 단체 -> 탑 레벨 서버 관리자 : 등록소 기관들이 존재 (a.gtld-servers.net) .com.

https://www.inflearn.com/courses/lecture?courseId=143476&type=LECTURE&unitId=12082 여기 이미지 그림으로 그리자

어휘 정리​

레코드 : [example.com] [record type] [ip or domain name] 레코드 타입 : A, AAAA, NS

nslookup를 활용해서 확인해보자​

(base) juyoung@Mac new-blog % nslookup naver.com
Server:		192.168.50.1
Address:	192.168.50.1#53

Non-authoritative answer:
Name:	naver.com
Address: 223.130.192.248
Name:	naver.com
Address: 223.130.200.236
Name:	naver.com
Address: 223.130.192.247
Name:	naver.com
Address: 223.130.200.219
  • 인가 네임 서버 (Registary)
(base) juyoung@Mac new-blog % nslookup -type=ns naver.com
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
naver.com	nameserver = ns1.naver.com.
naver.com	nameserver = ns2.naver.com.
  • 직접 문의
(base) juyoung@Mac new-blog % nslookup naver.com ns1.naver.com.
Server:		ns1.naver.com.
Address:	125.209.248.6#53

Name:	naver.com
Address: 223.130.192.247
Name:	naver.com
Address: 223.130.192.248
Name:	naver.com
Address: 223.130.200.219
Name:	naver.com
Address: 223.130.200.236

DNS record​

본론​

IP 주소란?​

Hosts file​

이건 가장 로컬한 DNS 매핑 방법이고, 실제 DNS 질의 전에 OS가 먼저 확인하는 곳 우선 Hosts 파일은 도메인 이름을 IP 주소에 매핑하는 로컬 파일이다.

OS에는 hosts라는 파일이 있다고 하는데 확인해보자. 해당 파일에 example.com -> 000.000.000.000 IP가 적혀있음.

cat /etc/hosts

UW PICO 5.09                                    File: /etc/hosts

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost

오호! 127.0.0.1 localhost가 적혀있구나?! 그래서 개발 서버가 띄워질 수 있던거 였구나!

hosts 파일과 보안과의 관계​

이렇게 호스토 내부 파일로 존재하는 hosts 파일을 악의적으로 변조한다면?

cat /etc/hosts

UW PICO 5.09                                    File: /etc/hosts

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
//악의적인 변조
x.x.x.x naver.com
::1             localhost

만약 네이버 서버에 접근할때 www.naver.com을 입력해서 접근하고 있다고 가정한다면 hosts가 위와 같이 바뀐다면? 그리고 바뀐 IP 서버의 응답이 naver.com와 동일해서 모든 정보를 파악할 수 있게 되면?!...

이런 문제를 우리가 일반적으로 신경쓰지 않아도 되는 이유를 알아보자.

  1. https (웹 브라우저가 식별해서 피싱을 막아줌. 어떻게?)

DNS 캐시가 무엇이고 어떻게 확인할 수 있어?​

DNS 캐시는 운영체제의 메모리 내부에 있는 mDNSResponder 프로세스가 관리해요.

DNS 캐시는 파일로 저장되지 않음 ❌ 별도의 디렉터리나 로그 파일로 보존되지 않음 ❌

mDNSResponder, dnsResponder, 또는 Discoveryd (버전에 따라 다름)라는 데몬이 RAM에 유지함 ✅

sudo log stream --predicate 'process == "mDNSResponder"' --info


Timestamp                       Thread     Type        Activity             PID    TTL
2025-06-12 01:35:49.260494+0900 0x154a     Default     0x0                  658    0    mDNSResponder: [com.apple.mDNSResponder:mDNS] [A(da8b8d28, 689be87e)] Received 139-byte IPv4 mDNS query from <mask.hash: 'Syweb54MbIEBsQR4Vcz5KQ=='> over multicast via en0/14 -- id: 0x0000 (0), flags: 0x0000 (Q/Query, NoError), counts: 5/0/0/1 <mask.hash: 'kPm80QrRHzQ5iWC0xdVI0A=='>
2025-06-12 01:35:49.263762+0900 0x154a     Default     0x0                  658    0    mDNSResponder: [com.apple.mDNSResponder:mDNS] [A(da8b8d28, 3a8a74ed)] Received a previous IPv6 mDNS query from <mask.hash: '5p/uwiLRUY9UDt7rBZICqg=='> over multicast via en0/14
2025-06-12 01:35:49.378292+0900 0x154a     Default     0x0                  658    0    mDNSResponder: [com.apple.mDNSResponder:mDNS] [A(b079ef2d, 36187799)] Sent a previous IPv4 mDNS response over unicast
2025-06-12 01:35:50.362573+0900 0x154a     Default     0x0                  658    0    mDNSResponder: [com.apple.mDNSResponder:mDNS] [R40->mDNS] DNSServiceBrowse result -- event: add, expired: no, ifindex: 14, name hash: fb114b37, type: PTR, rdata: <mask.hash: 'Gc1A+fV3B8nabi3q06YjLQ=='>
2025-06-12 01:35:58.224132+0900 0x154a     Default     0x0                  658    0    mDNSResponder: [com.apple.mDNSResponder:State] SysEventCallBack -- event: KEV_DL_ADDMULTI
2025-06-12 01:36:00.397177+0900 0x154a     Default     0x0                  658    0    mDNSResponder: [com.apple.mDNSResponder:Default] Received Goodbye packet for cached record -- name hash: fb114b37, type: PTR, last time received: 2025-06-12 01:36:00.397157+0900, interface index: 14, source address: <mask.hash: 'Syweb54MbIEBsQR4Vcz5KQ=='>, name hash if PTR: f23ac190
(base) juyoung@Mac new-blog % ps aux | grep mDNSResponder
root               688   0.0  0.0 426965760   2352   ??  Ss   13 525    0:38.93 /usr/sbin/mDNSResponderHelper
_mdnsresponder     658   0.0  0.1 426983312  11056   ??  Ss   13 525   14:27.32 /usr/sbin/mDNSResponder
juyoung          76808   0.0  0.0 410742544   1712 s059  S+    1:41AM   0:00.00 grep mDNSResponder

/etc/resolv.conf에 명시된 외부 DNS 서버로 질의​

잠깐 DHCP(Dynamic Host Configuration Protocol)은 뭐지?

DHCP는 네트워크에 연결된 장치에 IP 주소와 기타 필요한 네트워크 구성 정보를 자동으로 할당하는 프로토콜이라고 하는데 MAC에는 이런게 있나?!

(base) juyoung@Mac new-blog % ipconfig getpacket en0
op = BOOTREPLY
htype = 1
flags = 0x0
hlen = 6
hops = 0
xid = 0xc5f13e78
secs = 0
ciaddr = 0.0.0.0
yiaddr = 192.168.50.176
siaddr = 192.168.50.1
giaddr = 0.0.0.0
chaddr = 7a:a2:de:92:23:3a
sname =
file =
options:
Options count is 10
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 192.168.50.1
lease_time (uint32): 0x15180
renewal_t1_time_value (uint32): 0xa8c0
rebinding_t2_time_value (uint32): 0x12750
subnet_mask (ip): 255.255.255.0
broadcast_address (ip): 192.168.50.255
domain_name_server (ip_mult): {192.168.50.1}
router (ip_mult): {192.168.50.1}
end (none):
항목설명
yiaddr할당된 IP 주소 → 192.168.50.176
siaddrDHCP 서버 (또는 TFTP 서버) → 192.168.50.1
chaddr클라이언트 MAC 주소 → 7a:a2:de:92:23:3a
dhcp_message_typeACK (0x5) → 요청 승인 완료
server_identifierDHCP 서버 주소 → 192.168.50.1
lease_timeIP 임대 시간 → 0x15180 = 86400초 = 24시간
subnet_mask서브넷 마스크 → 255.255.255.0
broadcast_address브로드캐스트 → 192.168.50.255
domain_name_serverDNS → 192.168.50.1
router기본 게이트웨이 → 192.168.50.1

오호!! WIPI에 연결할때 DHCP가 바뀌는구나!? 우선 이번엔 여기까지

/etc/resolv.conf와의 관계는?! 뭐지? /etc/resolv.conf는 리눅스/유닉스/macOS 시스템이 DNS를 어떻게 사용할지 정의하는 설정 파일입니다.

DHCP는 IP 주소뿐 아니라 DNS 서버 정보도 제공합니다. macOS/Linux에서 DHCP로 연결하면, DHCP 서버가 알려준 DNS 서버 주소가 /etc/resolv.conf에 반영됩니다. 즉, /etc/resolv.conf는 보통 DHCP가 제공한 DNS 서버 주소로 자동 덮어써집니다.

확인해보니

  • 요청 UDP 53포트로 전송된다고 함.

  • 모든 DNS Server는 root name server 주소 목록을 알고 있다!!

질의 응답 수신 -> DNS 캐시에 저장​

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder 그 응답을 메모리 내 캐시 공간에 저장함. 이거 확인해보자

DNS 실습

  • 계층적 네임 서버
    • 재귀적 질의
    • 반복적 질의

실무 (나)에 적용할 포인트가 있을까?​

  1. DNS -> ISP의 DNS가 아닌 구글 무료 DNS를 사용해보자 (IP 주소 8.8.8.8 및 8.8.4.4를 사용하도록 네트워크 설정 수정, 1.1.1.1 사용해봐도 좋을듯)
  2. TTL 설정한대로 TTL에 맞게 캐시에서 사라지는지 확인하고 싶음.

결론​

DNS를 공부하면서 HTTPS에 대해 깊이 있게 눈으로 확인해보면서 학습해보고 싶어졌다. 보안에 관심이 있는 프론트엔드 개발자로서 우선 HTTPS에 대해 깊이 있게 학습해야함을 느꼈다. 지금까지 학습 흐름은 다음과 같다.

2024년 7월 8일에 1.1.1.1 해킹 당했다고 하는데??

Google DNS 관련

  • BGP 하이재킹(2014): 브라질·베네수엘라에서 약 22분간 Google DNS 트래픽 hijac
  • 과거 cache poisoning 공격 사례도 일부 보고됨 (예: 2018년 MyEtherWallet 도메인 변조 경고)

Cloudflare DNS 관련

  • 2024년 6월 27일: BGP 하이재킹 및 경로 누수(route leak)로 인해 1.1.1.1 트래픽 일부가 차단되거나 지연됨. 전 세계 70개국 300개 네트워크 영향
  • 2017년 Cloudbleed: Cloudflare 내부 버그로 인해 민감한 메모리 데이터 유출 (쿠키, 토큰 등 약 1,800만 건)
  • 2024년 초: Okta 해킹 연계로 추정되는 내부 시스템 접근 사례 .

해킹 사건 -> 보안 관심 -> 드림핵 -> XSS,CSRF 학습 -> 네트워크,리눅스 학습 도중 방황 -> 우선 브라우저 -> 브라우저 렌더링 -> DNS -> HTTPS

참고​

https://www.youtube.com/watch?v=drWd9HIhJdU https://www.inflearn.com/courses/lecture?courseId=143476&type=LECTURE&unitId=12077 루트네임서버 관리하는 조직 웹 사이트

나아가​

  1. DNS 서버 직접 운영해봐도 재밌을 것 같다.
  2. 로컬 DNS 사용해도 좋을 듯
  3. 집 서버 운영하고 싶은데 Dynamic DNS
  4. HTTPS 학습