[DNS]DNS의 기초적인 작동방식

DNS는 Domain Name System의 줄임말로써 도메인을 관리하는 시스템이다. DNS의 기본적인 작동방식에 대해서 정리한다.

1. DNS 서버에 ip 등록

서비스 제공자는 ip를 DNS 서버에 입력해달라고 요청한다. 즉, “도메인 example.com은 ip 93.184.216.34를 의미한다”라고 저장해달라고 요청한다. 그리고 DNS 서버는 해당 정보를 저장한다.

2. DHCP를 통해 DNS 서버 주소 할당

DHCP를 통해 클라이언트는 ip 뿐만 아니라 DNS 서버의 주소 / 서브넷 마스크 / 기본 게이트워이 등의 네트워크 정보를 할당 받는다. DHCP는 컴퓨터가 네트워크에 연결되는 순간 바로 실행되어 네트워크의 정보를 할당 받게 되며, 따라서 어떤 DNS 서버를 사용해야 하는지도 알게 된다.

참고

3. DNS로 도메인에 해당하는 ip 요청

DHCP를 통해 DNS 서버를 알고있기 때문에 접속할 도메인의 ip가 무엇인지 물어본다. 즉, DNS 서버는 example.com의 ip주소인 93.184.216.34를 클라이언트에게 알려준다.

example.com의 ip 주소를 알게된 클라이언트는 ip 주소를 통해 해당 서비스에 접속할 수 있다.

DNS 이용의 장점

  • hosts 파일을 관리하는 수고를 덜어준다.
  • 도메인의 ip 주소가 변경되어도 DNS 서버에서만 바꾸면된다.

정리

  • 클라이언트가 네트워크에 연결되는 순간 DHCP가 작동하여 ip를 물어볼 DNS 서버를 알게된다.

  • 네이버에 접속하는 순간 다음의 두 과정을 거친다.

    1. DNS 서버에게 naver.com의 ip 주소를 물어본다.
    2. DNS 서버로부터 naver.com의 ip 주소를 받고 해당 ip로 접속한다.

[참고]
https://www.youtube.com/watch?v=iM07I1X7qkg&list=PLuHgQVnccGMCI75J-rC8yZSVGZq3gYsFp&index=6
https://jwprogramming.tistory.com/35
http://www.ciokorea.com/tags/25731/DHCP/39337

Share

[JWT]인증(authentication)에 보편적으로 사용되는 JWT에 대해서

jwt.io

1. 사용자 인증정보를 관리하는 두 가지

  • 세션 기반 인증

서버 기반 인증이라고 불리기도 한다. 과거부터 사용해오는 방법이며 이름에서 알 수 있듯이 유저가 서비스에 로그인을 하면 서버는 인증 정보를 계속해서 사용해야 하기 위해 메모리나 데이터 베이스에 저장하여 관리하는 방식이다. 세션 기반 방식은 정말 정말 널리 쓰이지만 크게 볼때 두 가지의 문제가 존재한다.

첫 번째, 서비스에 로그인 중인 유저가 많아지면 세션을 유지하기 위해 더 많은 메모리 / 데이터 베이스의 자원을 사용하게 됨으로 성능에 무리를 줄 수 있다. 두 번째, 서버의 확장이 어려워진다. 첫 번째 이유를 확장해 생각해볼때 분산 환경에서 세션을 사용하려면 분산된 서비스간에 세션의 정보가 동기화 되어야 함으로 구현의 복잡도가 매우 커질 것이다.

  • 토큰 기반 인증

HTTP의 두 가지 특성 - 무상태성 / 비연결성 - 에 따라 HTTP는 상태를 가지지 않는다. 그렇기 때문에 로그인한 상태를 파악하기 위해 세션 기반 인증을 사용하는 것인데, 이에 반해 토큰 기반 인증은 서버 측에서 상태를 유지하지 않고 로그인 시에 발급한 토큰을 통해 유저가 인증과정을 밟는 것이다. 서버의 구성이 분산되어 있더라도 유저는 동일한 토큰을 통해 서버에 요청할 수 있고, 서버는 데이터 베이스와 통신할 필요 없이 인증을 유지할 수 있어서 확장하기에 편해질 수 있다. 또한 모바일 어플리케이션에서 인증을 구현하기에 매우 편리하다는 장점이 있다.

2. 토큰 관리

  1. 브라우저 스토리지에 저장

유저가 로그인하면 서버는 응답정보에 토큰을 넣어 전달한다. 클라이언트는 브라우저의 localStorage나 sessionStorage에 저장하여 다음 번 요청때 요청 헤더에 토큰을 붙여 보낼 수 있다. 구현하기 매우 쉽지만 보안적으로는 큰 구멍이 존재하는데, 자바스크립트를 통해 웹 브라우저의 스토리지에 접근할 수 있기 때문이다.

  1. 쿠키에 저장

쿠키를 전송 수단으로써 사용한다. 서버 측에서 응답할때 쿠키 설정에 httpOnly 옵션을 활성화하면, 네트워크 통신 상에서만 해당 쿠키가 붙게 된다. 따라서, 자바스크립트가 브라우저를 통해 토큰 값을 사용할 수 없다. 그렇다고 보안상의 문제가 없는 것은 아니며 CSRF 공격의 위험성이 발생할 수 있다.

3. JWT란?

JWT는 Json Web Token의 약자로써 JSON 문자열로 이루어진 토큰을 의미한다. 토큰 기반 인증 기술 중 하나이며 다른 토큰들과는 다르게 토큰 그 자체가 의미를 가지는 Claim 기반의 토큰이다.

4. JWT의 구조

https://jwt.io/introduction/

Header / Payload / Signature - 세 개의 섹션으로 이루어져있다.

4-1. Header

JWT 웹 토큰의 헤더 정보

  • alg: 해시 알고리즘. 데이터 자체를 암호화 하는 것이 아니라 발급된 토큰을 검증하기 위해 사용한다.
  • typ: 토큰의 타입. JWT만 사용가능하다.
1
2
3
4
{
"alg": "HS256",
"typ": "JWT"
}

4-2. Payload

데이터가 저장되는 부분. 3가지의 Claim 데이터가 있다.

  • Reserved Claim
  • Public Claim
  • Private Claim : 사용자 정의 Claim으로써 아래와 같이 정보를 저장한다.
1
2
3
4
5
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

4-3. Signature

데이터의 무결성과 변조 방지를 위한 서명. Header와 Payload를 합친 후 Secret Key와 함께 Header에 명시한 알고리즘으로 해싱된 값이다.

1
2
3
4
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)

4-4. 인증 과정

image

  1. 클라이언트가 로그인을 한다.
  2. 서버는 사용자의 정보를 확인 후 토큰을 생성하여
  3. 클라이언트에게 토큰을 전달한다.
  4. 로그인 후 모든 요청때, 헤더에 토큰 값을 붙여 전송한다.
  5. 토큰을 확인하여 유효한 토큰일 경우 요청을 처리한 뒤 응답한다.

4-5. 단점

  • Payload 부분에 데이터를 저장하기 때문에 데이터가 많아질 경우 토큰의 길이가 증가한다.
  • Payload의 데이터는 암호화가 아닌 base64로만 인코딩을 거친 값이다. 즉, 따로 암호화를 수행하거나 보안에 민감한 데이터를 포함하지 않아야만 한다.
  • 무상태(stateless)하기 때문에 한 번 생성한 토큰을 임의로 삭제할 수 없다. 꼭 토큰 만료시간을 설정하여 대비해야한다.

[참고]
https://jwt.io/introduction/
https://sanghaklee.tistory.com/47

Share

[DNS]도메인 이름의 구조

도메인 이름은 네 가지로 나눌 수 있다.

  • Root
  • Top-level
  • Second-level
  • Sub

그리고 DNS에서 통용되는 규칙 몇 가지가 있다.

  • 직속 하위 레벨의 DNS 서버의 리스트를 알고 있어야 한다.
  • 모든 컴퓨터는 적어도 Root 도메인의 DNS 서버를 알고 있어야 한다.

도메인 서버를 찾아과는 과정

위와 같이 blog.example.com 이라는 도메인에 접속하려고 할 때, 한 번에 blog.example.com를 가진 DNS 서버를 찾는 것은 어렵기 때문에 여러 레벨의 도메인 서버를 거쳐가기 마련이다.

클라이언트가 blog.example.com의 ip 주소를 알아가는 과정을 의식의 흐름대로 정리해보면 다음과 같다.

  1. Root 도메인의 DNS 서버를 알고 있으며, blog.example.com의 ip 주소를 물어본다.
  2. Root 도메인 서버는 blog.example.com의 ip를 모르기 때문에 하위 레벨인 .com의 DNS 서버를 알려준다.
  3. 클라이언트는 다시 .com의 DNS 서버에게 blog.example.com를 물어보지만 모르기 때문에 하위 레벨인 .example(2nd level)의 DNS 서버를 알려준다.
  4. .example를 관리하는 2nd level의 DNS 서버도 blog.example.com를 모르기 때문에 blog라는 서브 도메인을 관리하는 DNS 서버를 알려준다.
  5. blog를 관리하는 DNS 서버는 blog.example.com의 ip 주소를 알고 있기 때문에 클라이언트에게 알려준다.
Share