DNS란 무엇이며 중요한 이유 [스크린샷으로 설명]
게시 됨: 2019-08-20목차
정의
DNS 서버란?
DNS 작동 방식
DNS 레코드를 확인하는 방법
DNS 관행
웹사이트가 있는 경우 적합한 도메인 이름을 찾기 위해 많은 노력을 기울였을 가능성이 있습니다. 그 과정에서 여러 요소를 고려해야 했지만 가장 중요한 것은 창의성 모드를 켜야 한다는 것이었습니다.
1) 귀하의 비즈니스를 대변하고, 2) 대중의 관심을 끌며, 3) 적절한 가격표로 등록할 수 있는 정확한 이름을 생각해 내는 것은 쉬운 일이 아닙니다.
그러나 그 이름 뒤에 무엇이 있는지 궁금해 한 적이 있습니까? 어떻게 작동합니까? 답은 DNS가 무엇인지 알아내는 데 있습니다.
이것은 방문자가 귀하의 도메인을 입력할 때 실제로 일어나는 일을 알려줍니다! 궁금하시다면 계속 읽어보세요!
정의
웹사이트의 이름이 핵심입니다. 왜요? 대중이 귀하의 비즈니스와 아이디어를 알게 되는 문입니다. 그 고유한 이름을 도메인 이름이라고 합니다.
어려운 숫자는 또한 도메인 이름의 중요성에 대해 이야기합니다. 2020년 4분기에만 모든 최상위 도메인에서 3억 6,630만 개의 도메인 이름 등록이 마감되었습니다. 또 다른 연구에 따르면 웹사이트의 총 수는 약 20억 개입니다. 그런 종류는 스스로를 말합니다.
우리는 도메인 이름을 사용하여 다음을 수행합니다.
- 온라인 커뮤니티의 일원이 되다
- 더 많은 청중과 아이디어 공유
- 온라인에서 특정 정보 찾기
... 그리고 우리의 창의성이 영감을 줄 수 있는 모든 것. 우리는 그 이름을 기억하고 북마크하거나 나중에 사용할 수 있도록 저장합니다. 다양한 옵션이 있습니다.
반면에 웹 브라우저는 우리가 온라인에서 검색하는 것과 동일한 정보를 찾기 위해 다른 접근 방식을 사용합니다. 그들은 인터넷 프로토콜(IP) 주소라고 불리는 것을 사용합니다. 이것은 각 장치에 할당된 숫자 시퀀스입니다.
도메인 이름 시스템 또는 DNS는 단순히 이름 지정 시스템입니다. 각 도메인 이름을 고유한 IP 주소로 변환하므로 웹 브라우저가 원하는 정보를 찾을 수 있는 위치를 알 수 있습니다.
인터넷에 연결된 각 장치에는 IP 주소가 있어 이를 찾아 연결할 수 있습니다.
도메인 이름 시스템에는 자체 계층이 있습니다.
- 그 위에 DNS 루트 서버가 있습니다. 여기에는 모든 최상위 도메인 이름의 이름과 IP 주소를 나열하는 파일이 포함되어 있습니다. 이를 통해 서버는 멋진 도메인을 IP로 변환하고 실제로 웹사이트를 반환할 수 있습니다.
'A'에서 'M'까지의 문자로 명명된 13개의 루트 서버가 전 세계적으로 운영되고 있습니다. ICANN(Internet Corporation for Assigned Names and Numbers)에서 관리합니다.
- 신뢰할 수 있는 서버는 쿼리에 직접 '응답'하는 서버 유형입니다. 여기에는 DNS 영역이 포함되어 있으며 요청을 완료하는 데 필요한 올바른 DNS 레코드를 찾는 데 도움이 됩니다. 도메인을 등록할 때 두 개의 권한 있는 서버(주 서버와 보조 서버)를 설정하게 됩니다. 여기에는 도메인과 연결된 모든 단일 DNS 레코드와 같은 동일한 데이터가 포함됩니다. 보조 서버는 기본 서버가 다운된 경우 단순히 백업 역할을 합니다. 언제든지 변경할 수 있습니다. 변경 자체가 완전히 적용되려면 24~48시간이 걸립니다.
- DNS 쿼리 체인의 또 다른 구성 요소는 재귀 DNS 서버입니다. 모든 DNS 쿼리를 수신하고 호스트 이름을 해당 IP 주소와 일치시키는 역할을 합니다.
어떻게 작동합니까?
> 먼저 확인자는 로컬 캐시에서 지정된 DNS 레코드를 찾습니다.
> 작동하지 않으면 도메인의 권한 있는 서버를 찾습니다.
> 다음으로 갈 곳은 루트 서버로, 해석기가 해당 TLD 네임서버의 세부 정보를 얻을 수 있습니다.
> 마지막으로 찾고 있는 도메인의 IP 주소를 찾는 데 도움이 됩니다. 이제 실제로 사이트에 액세스할 수 있습니다.
DNS 서버란?
좋습니다. 우리는 컴퓨터가 IP 주소를 통해 통신한다는 것을 확인했습니다. 이제 우리는 DNS 서버가 무엇인지 쉽게 이해할 수 있습니다. 즉, IP 주소와 해당 호스트 이름의 데이터베이스를 저장하는 서버입니다.
브라우저에 특정 도메인을 입력하면 실제로 이름 서버에 쿼리를 보내 해당 IP 주소를 찾습니다. 도메인의 서버는 IP 주소를 호스트 이름과 일치시켜 요청한 도메인 이름에 액세스할 수 있습니다.
브라우저나 다른 애플리케이션의 도메인에 액세스하려고 하면 실제로 특정 DNS 서버에 쿼리를 제출하게 됩니다. 요청을 처리하는 프로토콜을 DNS 프로토콜이라고 하며 보다 구체적으로 UDP(User Datagram Protocol)라고 합니다. 포트 53에서 작동하며 짧은 메시지를 보내는 데 사용됩니다. 요청에 대한 응답이 512바이트보다 큰 경우 TCP(전송 제어 프로토콜)가 대신 사용됩니다.
보내는 요청은 지정된 호스트 이름과 연결된 DNS 조회를 트리거합니다. 이에 대해 잠시 살펴보겠습니다!
DNS 작동 방식
이제 우리는 좋은 기반을 마련했습니다. 결국 우리는 DNS와 관련하여 접할 수 있는 거의 모든 용어를 설명했습니다.
좋습니다. 몇 가지 질문에 더 답해 보겠습니다.
DNS란 무엇이며 어떻게 작동합니까?
DNS는 전 세계적으로 모든 운영 체제에서 작동하는 이름 확인 서비스입니다. 도메인 이름을 해당 IP 주소에 매핑합니다.
과거에는 호스트 이름을 IP 주소에 매핑하는 로컬 호스트 파일이 있었습니다. 오늘날의 DNS는 수백만 개의 IP 주소를 처리하며 오늘날 가장 널리 사용되는 매핑 시스템입니다.
브라우저에 도메인을 입력하면 DNS 쿼리가 트리거됩니다. 그런 다음 눈 깜짝할 사이에 장면 뒤에서 일련의 이벤트가 발생합니다.
- 이 빠른 여정의 첫 번째 중지는 브라우저가 운영 체제에 요청을 보내고 해당 IP 주소를 찾는 것입니다.
- 그런 다음 운영 체제는 요청을 ISP(인터넷 서비스 공급자)로 보냅니다. 각 ISP는 확인 서버라고 하는 DNS 서버를 구성했습니다.
- 확인 서버에 요청된 IP 주소의 위치에 대한 정보가 없을 수 있습니다. 그러나 루트 서버 방향으로 쿼리를 가리킵니다.
- 그런 다음 확인 서버는 최상위 도메인 이름 서버인 권한 있는 이름 서버의 위치를 찾습니다. 여기에는 요청된 호스트 이름의 DNS 레코드가 포함됩니다.
- 등록된 각 도메인에 할당된 권한 있는 1차 및 2차 네임서버는 DNS 레코드 세트를 보유하고 있으며 그 중 우리가 찾는 도메인 이름의 IP 주소가 있습니다.
- 서버에서 제공한 응답은 데이터를 브라우저로 다시 전송하는 확인 서버로 돌아가고 짜잔 – 방문하려는 페이지가 표시됩니다!
전체 DNS 프로세스는 1초 이내에 언급한 모든 단계를 거칩니다. 그러나 프로세스는 가능하며 일반적으로 그보다 더 짧습니다. 프로세스의 모든 단계에서 로컬 캐시는 첫 번째 단계로 간주됩니다.
캐시는 처리 능력, 저장 공간을 절약하고 결과를 최적화하는 강력한 방법입니다. 운영 체제, 인터넷 서비스 제공업체, 네임서버 - 모두 로컬 캐시를 먼저 확인합니다. 정보가 있으면 IP 주소가 다시 전송되고 프로세스가 완료됩니다.
아래에서 DNS 작동 방식을 확인하십시오.
DNS 영역 레코드란 무엇입니까?
도메인을 등록할 때 등록 회사로부터 네임서버 공간도 받거나 다른 곳에서 받을 수 있습니다. 이 공간은 도메인에 대한 DNS 포인터를 만들고 다양한 요청을 도메인으로 보냅니다.
이러한 항목을 DNS 레코드라고 하며 도메인 이름에 온라인으로 연결할 수 있으려면 최소한 몇 개의 항목이 필요합니다. 다양한 목적을 가진 많은 선택적 레코드가 있습니다. 몇 가지 기본적인 DNS 레코드 유형과 가장 널리 사용되는 레코드 유형을 살펴보겠습니다.
네임서버 레코드 – 도메인의 DNS 영역 레코드를 처리하는 권한 있는 네임서버를 나타냅니다.
DNS A 레코드 – 호스트 이름의 IP 주소를 나타냅니다.
CNAME 레코드 – 도메인을 다른 이름으로 전달하는 정식 이름 레코드입니다.
MX 레코드 – 메일 교환기 레코드는 도메인을 담당하는 메일 서버를 나타냅니다.
DNS TXT 레코드 – 호스트 이름을 서버, 네트워크 또는 기타 정보에 대한 사람이 읽을 수 있는 텍스트에 연결할 수 있는 기능을 제공하는 리소스 레코드입니다.
DNS 영역 레코드에는 도메인 이름과 관련된 몇 가지 다른 정보가 포함되어 있습니다.
- 기록의 이름(호스팅 제공업체에서 제공)
- TTL(time-to-live) 표시기(DNS 영역 레코드가 초 단위로 새로 고쳐지는 빈도를 나타냄)
- 레코드 유형(A, CNAME, MX 등)
- 및 레코드 값(호스팅 제공업체에서 제공).
DNS 레코드를 확인하는 방법
도메인 이름의 DNS 레코드 영역을 확인하는 방법에는 여러 가지가 있습니다.
- 개인 도메인 이름의 DNS 영역 레코드를 관리하려면 도메인의 제어판을 사용해야 합니다. 각 도메인 이름 등록 대행자는 하나에 대한 액세스를 제공합니다. 여기에서 기록을 관리하고 도메인을 갱신 또는 다른 등록 대행자로 이전하거나 연락처 정보를 관리할 수 있습니다.
- DNSChecker 또는 MXToolbox와 같은 사용 가능한 온라인 도구 중에서 선택할 수도 있습니다.
- 터미널 프로그램(Mac OS용), 명령 프롬프트(Windows용) 또는 명령줄 인터페이스(Linux OS용)에 익숙해지면 다음 명령 중 하나를 실행하여 DNS 레코드를 찾을 수 있습니다. dig, host 또는 nslookup.
명령: 발굴
레코드 유형: A, MX, TXT, NS 등
도메인 이름: DNS 조회를 원하는 도메인 입력
> dig A techjury.com
이 쿼리의 결과는 techjury.net의 IP 주소를 제공해야 합니다.
DNS 레코드 조회를 수행하는 방법은 무엇입니까?
다시 말하지만 온라인 도구를 사용하거나 명령 프롬프트에 다음 명령을 입력할 수 있습니다.
명령어: nslookup
도메인 이름: techjury.net
> nslookup techjury.net
DNS 관행
물론 DNS에 대해 말할 때 좋은 사례와 그렇지 않은 사례가 있습니다. 오늘날 인터넷에서 가장 널리 사용되는 확인 시스템인 DNS는 큰 관심의 대상입니다. 의도도 양극화되고 있다.
DNS 작동 방식을 더 잘 이해하려면 가장 일반적인 몇 가지 좋은 방법과 나쁜 방법, 그리고 이것이 도메인 성능에 미치는 영향에 대해 알아두는 것이 좋습니다. 계속 읽고 문제에 대한 지식과 팁을 얻으십시오!
좋은 사람들을 바라보며:
- 도메인 이름의 DNS 영역에 항상 두 개의 DNS 이름 서버가 설정되어 있는지 확인하십시오. 기본 서버와 동일한 정보를 보유한 보조 서버는 기본 서버가 다운된 경우에도 도메인 이름의 기능을 보장합니다. 또는 웹사이트, 메일 서비스 및 기타 도메인 관련 서비스에 액세스할 수 없습니다. 비즈니스에 좋지 않습니다!
- 도메인의 DNS 영역을 정기적으로 감사하고 모든 항목이 최신 상태인지 확인하십시오. DNS 영역 제어판을 통해 직접 수행하거나 사용 가능한 온라인 DNS 확인 도구 중 하나를 사용하거나 브라우저에서 도메인 및 하위 도메인의 기능을 간단히 확인할 수 있습니다. 오류 메시지는 무엇보다도 DNS 영역 레코드의 오작동을 나타내는 표시일 수 있습니다.
- 간단하게 들릴 수 있지만 DNS 영역 제공자(웹상의 다른 모든 것)에 액세스할 때는 항상 이중 인증을 고려해야 합니다.
몇 가지 나쁜 습관:
- DNS 오염 또는 DNS 캐시 중독은 가장 널리 사용되는 DNS 공격 중 하나입니다. IP 주소와 같은 정보를 변경하기 위한 간섭인 스푸핑 공격의 결과로 발생합니다. 결과적으로 특정 DNS 요청은 변경된 소스로 전달됩니다. 해커는 DNS 쿼리에 대한 응답을 수정하고 궁극적으로 자신의 이익을 위해 트래픽을 도메인 이름으로 리디렉션하거나 민감한 세부 정보를 수집하거나 단순히 웹 사이트의 평판을 손상시킬 수 있습니다. 예방 조치로 도메인 DNS 영역에 대해 DNSSEC 확장을 활성화하는 것을 고려해야 합니다. 이 방법은 쿼리에 대한 DNS 응답의 신뢰성을 보장하는 디지털 서명을 사용합니다. 메시지를 확인할 수 없는 경우 브라우저는 요청한 페이지를 표시하지 않습니다. 이를 활성화하려면 DNS 공급자에게 지침을 문의해야 합니다.
- DNS 리소스 소진 공격 – 대상 리소스 또는 서비스가 완전히 소진되어 중지 또는 재부팅해야 하는 지점까지의 DNS 리소스 활용. 대역폭, 메모리, CPU는 문제의 가장 표적이 되는 리소스 중 일부입니다. 피해 – 캐시를 채우는 DNS 서버에 대한 악의적인 요청이 많은 동안 다른 요청에 대한 해결 시간도 늘어납니다. 이러한 공격은 ISP(인터넷 서비스 제공업체)에게 특히 불쾌합니다.
- DNS 유출은 온라인 안전과 익명성에 대한 실질적인 위협입니다. 우리의 모든 온라인 활동은 ISP에 의해 기록되므로 이러한 누출이 발생하면 개인 정보가 노출됩니다. 예방책으로 VPN 솔루션을 고려해야 합니다. 먼저 DNS 누출 테스트를 수행해야 합니다.
불행히도 그러한 DNS 공격에 대한 은총알은 없습니다. 그러나 고유한 하위 도메인에 대한 쿼리 증가 또는 네임서버의 시간 초과에 대해 DNS 재귀 서버를 모니터링할 수 있습니다. 이것은 뭔가 잘못되었다는 신호를 울려야 합니다.
가장 좋은 방법은 DNS 인프라의 정기적인 유지 관리 및 모니터링을 수행하는 DNS 제공업체를 선정하는 것입니다.
이제 DNS가 무엇인지, 메일의 고유 사용자로서 DNS가 의미하는 바, 온라인 비즈니스 운영, 동료 소셜 미디어 팔로워와 관심사 공유 등을 더 잘 이해하시기 바랍니다.
DNS가 어떻게 작동하는지 더 자세히 알아보기 위해 귀하의 호기심을 불러일으킬 수 있다면 우리는 우리의 일을 잘한 것입니다!
감사합니다. 곧 만나요!
자주하는 질문
우리는 이름을 사용하여 웹사이트에 액세스하지만 컴퓨터는 숫자 주소를 사용합니다. 도메인 이름 시스템은 호스트 이름을 IP 주소와 매핑하는 이름 확인 시스템입니다. 도메인과 IP 주소를 포함하는 가장 널리 사용되는 데이터베이스입니다. DNS 서비스가 없으면 웹에서 검색하는 모든 도메인의 IP 주소를 기억해야 합니다. 상당히 불가능한 작업입니다.
DNS 프로세스는 다음과 같이 진행됩니다.
> 브라우저에 도메인 이름 techjury.net 을 입력 합니다.
> 브라우저는 해당 IP 주소를 찾기 위해 확인 서버에 요청을 보냅니다.
> 서버는 13개의 루트 네임서버 중 하나에 요청을 보냅니다.
> 루트 네임서버 가 요청된 IP 주소를 보유하지 않으면 .NET TLD의 DNS 서버의 IP 주소로 요청을 가리킵니다.
> 이제 요청이 .NET 도메인 이름에 대한 모든 IP 주소를 포함하는 .NET DNS 서버로 전달됩니다.
> techjury.net의 IP 주소가 검색되고 해당 정보가 브라우저로 다시 전송됩니다.
DNS IP 주소가 어떻게 생겼는지 알아보려면 원하는 도메인 이름 을 선택하십시오.
techjury.net과 함께 DNS 예 를 사용 하여 명령 프롬프트/터미널에서 다음 명령을 실행하여 IP 주소를 찾을 수 있습니다.
> techjury.net 발굴
받아야 하는 결과는 다음과 같습니다.
> 45.33.10.130
DNSSEC 확장은 DNS 영역 레코드를 위한 추가 보안 계층입니다. 디지털 서명 및 암호화 메시지 교환을 기반으로 작동합니다. 서명은 쿼리에 대한 DNS 응답의 진위를 확인합니다. 이를 사용하려면 DNS 공급자에게 도움을 요청하거나 BIND 파일을 변경하여 수동으로 활성화해야 합니다.
빠른 인터넷 연결을 제공하는 대체 사설 DNS 확인자.
장점: 일부 ISP는 DNSSEC 확장을 지원하지 않거나 적절한 암호화를 사용하므로 보안이 향상됩니다. 1.1.1.1은 최첨단 암호화를 추가로 제공하고 디버깅 목적으로 사용자 데이터를 24시간 동안만 저장하여 데이터 유출 위험을 완화합니다.
또한 성능도 향상됩니다. 상업적인 용도나 다른 목적(24시간 디버깅 기간 제외)으로 데이터를 저장하지 않기 때문에 과사용으로 인한 느려짐이 없습니다. 또한 전 세계의 모든 Cloudflare 서버에 구현되어 연결 속도가 매우 빠릅니다.
DNS를 사용하면 웹사이트, 이메일 주소, 서버, 파일 및 기본적으로 로컬 네트워크 또는 인터넷의 일부로 접하게 되는 모든 항목의 이름을 지정할 수 있습니다.
모든 요청에 대해 숫자 IP 주소를 외울 필요가 없습니다.
DNS를 사용하면 요청을 즉시 해결할 수 있습니다. 이것은 모든 TLD 이름과 해당 IP 주소의 데이터베이스를 저장하는 전역에 위치한 루트 서버를 통해 발생합니다.
DNS는 오늘날 인터넷의 중요한 구성 요소입니다. 완벽하게 설계된 구조 없이 어떻게 작동할 수 있는지 상상하기 어렵습니다. 인간의 눈에는 보이지 않지만 오늘날 인터넷의 원활한 기능은 DNS 서비스가 없었다면 존재하지 않았을 것입니다.