일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Jenkins
- 도메인
- Storage
- 네이버 클라우드 플랫폼
- CLI
- route table
- AD
- ncp
- VPC
- Dedup
- security group
- Python
- FSX
- Windows
- Subnet
- Athena
- 테라폼
- 윈도우
- EC2
- ALB
- storage gateway
- terraform
- S3
- CloudFront
- dns
- lambda
- AWS
- RDS
- Linux
- NaCl
- Today
- Total
끄적이는 보송
nslookup 명령어 사용법 본문
nslookup 이란 DNS record를 조회할 수 있는 커맨드 라인 명령어이며 여러 OS에 기본적으로 설치되어 있는 유틸리티다. 업무에 자주 쓰이는 녀석이라 정리해본다.
nslookup 명령어 기본 포맷
$ nslookup
> server ('dns ip') // 인자 값을 넣어 dns 지정할 수 있다. 지정하지 않으면 로컬에 설정된 기본값을 따른다
> set type=('type') // 어떻게 물어볼지에 대한 타입 입력
> www.server.com // 무엇을 물어볼지에 대한 도메인 입력
nslookup 명령어는 기본적으로 prompt를 받게 되어있어 위처럼 꺾쇠가 있다.
nslookup RR(Resource Record) type 종류
- A > IP 주소를 알고 싶을 때
- PRT > 특정 IP주소가 도메인과 일치하는지 알고 싶을 때
- CNAME > 도메인과 별도로 별칭이 있는지 (원래 이름)
- MX > 도메인으로 메일이 갈 때, 어떤 메일 서버가 수신하는지
- NS > 해당 도메인을 관리하는 도메인 서버가 누구인지
- SOA > 도메인 존에 관련된 정보가 무엇인지
- TXT > 기본 도메인 정보 외, 기타 정보는 무엇인지
정방향 쿼리 (type=a)
정방향 쿼리를 사용해 네이트와 구글의 IP 주소를 알 수 있었다. 도메인 서버 168.126.63.2에 질의하여 도메인의 IP 주소를 얻어온 것을 알 수 있다.
역방향 쿼리 (type=ptr)
IP 주소를 입력했을 때, 어떤 도메인이 연결되어 있는지 알 수 있는 명령어다. 여기서 재밌는 게 하나 있다. 우리는 분명 '142.251.42.164'의 IP주소에 대해 물어봤지만 실제로 컴퓨터 내부적으로는 뒤집어서 '164.42.251.142.in-addr.arpa'로 뒤집어서 질의한다는 것을 알 수 있다.
다음은 역방향 질의는 오류를 보이고 있다. IP가 잘못된 것일까? 아니다. 일단 우리는 dns를 직접 설정할 권한이 없고 업체에서 관련 기능을 허용해야 한다.
오류 메시지를 자세히 확인해보자. '120.50.131.112'라는 IP 주소의 역방향 쿼리는 실제로 '112.131.50.120.in-addr.arpa'라는 PTR 레코드 형식으로 전달된다고 앞서 언급했다. xxx.xxx.xxx.xxx.in-addr.arpa라는 서브도메인 PTR 레코드 설정 권한은 그 IP 주소를 소유하고 있는 기관에게 있으며 역방향을 할지 말지는 그들이 정하는 것이다. 여기서 우리는 in-addr.arpa라는 도메인을 소유하고 있지 않기에 해당 도메인을 컨트롤할 수 없고 그들이 못하도록 설정한 거면 그냥 못하는 거다.
CNAME 레코드 (type=cname)
cname은 canonical name의 약자로 원래 도메인 이름이 너무 길으니 일반 유저들을 위해 간단하게 줄여준 것을 바라보도록 가리키는 레코드다. 혹은 여러 서브도메인 주소를 하나의 주소로 몰아줄 수도 있고, 용도가 변경된 도메인을 다른 곳을 바라보도록 이어 줄 수도 있다.
MX 레코드 (type=mx)
어느 웹사이트에 메일을 보냈을 때, 어떤 메일 서버가 메일을 받는지 알 수 있는 명령어다. 밑에 이미지를 보면 5개의 리스트가 보인다. 이들이 내가 메일을 보냈을 때 메일을 받게 될 서버이며 빨간색 박스로 강조한 숫자 값이 적으면 적을수록 그 우선순위는 높다.
10 값의 서버가 죽었으면 20으로 보내고, 20 값의 서버가 죽으면 30으로 보낼 것이다. 만약 50 값의 서버가 메일을 받았다면 우선순위가 높은 메일 서버로 그 메일을 넘기게 된다. 숫자에 대한 제약은 없지만 일반적으로 10, 100 단위로 깔끔하게 나누는 편이다.
NS레코드 (type=ns)
도메인을 어떤 DNS가 관리하는지 확인하기 위한 명령어다. 'nate.com' 도메인은 'ns1.nate.com'과 'ns2.nate.com' 이 관리하는 것을 알 수 있다.
SOA레코드 (type=soa)
start of authority의 약자로 도메인 정보 상단에 위치하는 도메인 전체 정보 설정에 대한 중요한 정보들을 담고 있다. 총 7개의 필드를 출력하고 있다. 위에서부터 1~2번째는 네임서버 부분이고, 3~6번째는 마스터&슬레이브 부분이고, 마지막 부분은 cache dns가 참조하는 부분이다. 하나하나 설명하자면 밑과 같다.
- origin > 해당 존을 도메인을 관리하는 네임서버
- mail addr > 네임서버를 관리하는 관리자
- serial > 언제 업데이트했는지
- refresh > 최신화를 위해 슬레이브가 마스터에 데이터를 질의하는 주기
- retry > 슬레이브가 마스터에 질의 실패 시, 가지는 텀
- expire > 슬레이브가 마스터로부터 받은 데이터를 유지하는 기간
- minimum > 마스터 or 슬레이브로부터 데이터를 받은 DNS 서버가 데이터를 보관하는 주기 (default TTL이 없을 때 이것이 대신한다)
위 값들을 좀 더 자세히 설명해 보겠다. 마스터가 한대고 슬레이브가 10대라고 가정하겠다. 마스터와 슬레이브는 항상 데이터를 동기화한다. 이때 이들이 참조하는 값들은 serial, refresh, retry 그리고 expire이다.
슬레이브는 serial 값을 참고해 마스터에 데이터 변경이 있는지 확인하고 있다면 데이터를 최신화하며 그 주기는 refresh 값만큼이다. 만약 어떠한 이유로 마스터로부터 슬레이브가 데이터를 가져오지 못한다면(마스터가 죽었다던가 etc...) 얼마간의 텀을 가지고 다시 정보를 요청할지 retry 값을 참고한다. 그리고 슬레이브는 expire 값만큼 데이터를 유지한다. 그리고 마스터&슬레이브로부터 데이터를 얻은 DNS 서버는 TTL 값만큼 데이터를 보관한다.
TXT레코드 (type=txt)
필수 정보 외에 참고할 수 있는 자료를 볼 수 있는 레코드다. 대충 설명하자면 하단의 IP주소들은 화이트 도메인 부분이고 구글에서 긁어가지 못하도록 설정하겠다 등의 참고자료를 볼 수 있다.