DNS 역방향 조회
Reverse DNS lookup컴퓨터 네트워크에서 역 DNS 룩업 또는 역 DNS 해결(rDNS)은 도메인 [1]이름에서 IP 주소를 "전송"하는 일반적인 DNS 룩업과 반대로 IP 주소에 관련된 도메인 이름을 결정하는 Domain Name System(DNS; 도메인 이름 시스템)의 쿼리 기법입니다.IP 주소의 역해결 프로세스에서는 PTR 레코드를 사용합니다.rDNS 에는 도메인네임 레지스트리와 레지스트라 테이블의 검색이 포함됩니다.인터넷의 역 DNS 데이터베이스는 .arpa 최상위 도메인에 있습니다.
정보 RFC 1912(섹션 2.1)에서는 "인터넷에 접속할 수 있는 모든 호스트에는 이름이 있어야 한다" 및 "모든 IP 주소에 일치하는 PTR 레코드가 있어야 한다"고 권장하고 있습니다만, 이것은 인터넷 표준 요건이 아니며, 모든 IP 주소에 역엔트리가 있는 것은 아닙니다.
이력 사용
최신의 「역 DNS 검색」은, 에 지정되어 있는 낡은 「역 쿼리」(IQUERY) 메카니즘과 혼동하지 말아 주세요. RFC 1035:
역쿼리는 메시지의 응답 섹션에 빈 질문 섹션이 있는 단일 리소스 레코드(RR) 형식을 취합니다.쿼리 RR의 소유자 이름과 그 존속 가능 시간(TTL)은 중요하지 않습니다.응답에는 네임서버가 인식하고 있는 쿼리 RR을 소유하는 모든 이름을 식별하는 질문 섹션의 질문이 포함됩니다.네임 서버가 모든 도메인 이름 공간에 대해 알지 못하기 때문에 응답은 절대 완전하다고 가정할 수 없습니다.따라서 역쿼리는 주로 데이터베이스 관리 및 디버깅액티비티에 도움이 됩니다호스트 주소에 호스트 이름을 매핑하는 방법은 사용할 수 없습니다.
in-addr.arpa
대신 도메인을 지정합니다.[2]
IQUERY 메시지유형은 항상 "옵션"[2]으로 "광범위한 [3]사용을 달성한 적이 없다"며 2002년에 RFC 3425가 채택됨에 따라 "영구적으로 폐기"[3]되었습니다.
구현 상세
IPv4 역해상도
IPv4 주소의 DNS 역방향 조회는 특수 도메인을 사용합니다.in-addr.arpa
이 도메인에서 IPv4 주소는 점으로 구분된 10진수 4개의 연속된 시퀀스로 나타나며, 여기에 두 번째 수준의 도메인 접미사가 추가됩니다..in-addr.arpa
4 개의 10 진수는, 32 비트의 IPv4 주소를 4 개의 옥텟으로 분할해, 각 옥텟을 10 진수로 변환하는 것으로 얻을 수 있습니다.다음으로 이들 10진수는 최하위 옥텟의 선두(왼쪽 끝), 최상위 옥텟의 마지막(오른쪽 끝) 순으로 연결됩니다.이것은, IPv4 주소를 텍스트 형식으로 기술하는 통상의 닷이 있는 10 진표기와는 반대의 순서인 것에 주의해 주세요.
예를 들어, IP 주소 8.8.4.4를 역룩업 하려면 , 도메인명의 PTR 레코드를 사용합니다.4.4.8.8.in-addr.arpa
찾아보고, 지적할 수 있다는 것을 알 수 있다.dns.google
.
A가 다음을 위해 기록되는 경우dns.google
다시 8.8.4.4를 가리킨다면, 그것은 전향적이라고 할 것이다.
클래스리스 리버스 DNS 방식
지금까지 인터넷 레지스트리와 인터넷서비스 공급자는 256(클래스 C의 경우) 이상의 옥텟 기반 블록으로 클래스 B 및 A에 IP 주소를 할당했습니다.정의상 각 블록은 옥텟 경계에 속합니다.리버스 DNS 도메인의 구조는 이 정의에 기초하고 있습니다.그러나 Classless Inter-Domain Routing의 도입으로 IP 주소는 훨씬 작은 블록으로 할당되었습니다.따라서 포인터 레코드의 원래 설계는 작은 블록의 관리 자율성을 부여할 수 없었기 때문에 실용적이지 않았습니다.RFC 2317은 CNAME 레코드를 사용하여 이 문제에 대처하는 방법을 고안했습니다.
IPv6 역해상도
IPv6 주소의 DNS 역방향 조회는 특수 도메인을 사용합니다.ip6.arpa
(이전에는ip6.int
IPv6 주소는, 이 도메인내의 이름으로서 역순으로 니블의 시퀀스로 표시됩니다.서브 도메인으로 16 진수로 표시됩니다[4].예를 들어, IPv6 주소 2001:db8::567:89ab 에 대응하는 포인터 도메인명은, 다음과 같습니다.b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
.
다중 포인터 레코드
대부분의 rDNS 엔트리에 PTR 레코드는 1개뿐이지만 DNS에 의해 그 수는 제한되지 않습니다.예를 들어 웹 서버가 많은 가상 호스트를 지원하는 경우(즉, 여러 호스트 이름이 단일 주소로 해결되고 여러 호스트 이름이 해당 공유 주소의 PTR 검색에 대해 반환됨)에 여러 PTR 레코드가 사용됩니다.단, 일반적으로 DNS 룩업은 UDP를 통해 이루어집니다.UDP의 메시지사이즈는 한정되어 있기 때문에 극단적인 경우 여러 PTR에 의해 DNS 응답이 UDP 제한을 초과할 수 있습니다.
PTR 레코드 이외의 레코드
PTR 레코드 이외의 레코드 타입도 리버스 DNS 트리에 표시될 수 있습니다.예를 들어 IPsec, SSH 및 IKE에 대해 암호화 키를 배치할 수 있습니다.DNS 기반 서비스 검색은 역 DNS 트리에서 특별히 명명된 레코드를 사용하여 서브넷별 서비스 검색 [5]도메인에 대한 힌트를 클라이언트에 제공합니다.덜 표준화된 사용법에는 IP 주소의 지구물리학적 위치를 식별하기 위해 TXT 레코드와 LOC 레코드에 배치된 코멘트가 포함됩니다.
사용하다
리버스 DNS 의 가장 일반적인 용도는 다음과 같습니다.
- rDNS의 원래 용도:SMTP 전자 메일, 유저를 추적하는 Web 사이트(특히 인터넷포럼)의 traceroute, ping, 「Received:」트레이스 헤더필드등의 툴을 사용한 네트워크의 트러블 슈팅.
- 전자 메일 안티스팸 기술 중 하나는 다이얼업 사용자가 도메인 이름을 지정했는지, 또는 정규 메일서버가 사용할 가능성이 낮은 주소가 동적으로 할당되었는지 여부를 rDNS에서 확인합니다.이러한 IP 주소의 소유자는, 통상은 「1-2-3-4-dynamic-ip.example.com」등의 범용 rDNS 이름을 할당합니다.안티스팸 필터에 따라서는, 이러한 주소로부터 송신된 전자 메일이 스팸이라고 상정해,[6][7] 접속을 거부할 가능성이 있습니다.
- Forward-Confirmed Reverse DNS(FCRDNS; 전송 확인 역 DNS) 검증에서는 도메인 이름 소유자와 IP 주소가 부여된 서버 소유자 간의 유효한 관계를 나타내는 인증 형식을 작성할 수 있습니다.스패머와 피셔는 일반적으로 좀비 컴퓨터를 사용하여 도메인 레코드를 위조할 때 순방향 검증을 수행할 수 없기 때문에 이 검증은 화이트리스트에 자주 사용될 정도로 강력하지는 않습니다.
- 시스템 로깅 또는 모니터링 도구는 대부분의 경우 IP 주소로만 지정된 관련 장치를 가진 엔트리를 수신합니다.인간이 사용할 수 있는 데이터를 더 많이 제공하기 위해 이러한 프로그램은 로그를 쓰기 전에 역방향 조회를 수행하여 IP 주소가 아닌 이름을 씁니다.
레퍼런스
- ^ "Reverse DNS". Cloudflare. Archived from the original (html) on 30 March 2019. Retrieved 25 July 2019.
A reverse DNS lookup is a DNS query for the domain name associated with a given IP address. This accomplishes the opposite of the more-commonly-used forward DNS lookup, in which the DNS is queried to return an IP address.
- ^ a b "RFC 1035 — Domain names - implementation and specification". November 1987. Retrieved 2017-12-28.
- ^ a b "RFC 3425 — Obsoleting IQUERY". November 2002. Retrieved 2017-12-28.
- ^ G. Huston (August 2005). Deprecation of "ip6.int". Network Working Group IETF. doi:10.17487/RFC4159. BCP 109. RFC 4159.
- ^ S. Cheshire; M. Krochmal (February 2013). DNS-Based Service Discovery. IETF. sec. 11. doi:10.17487/RFC6763. ISSN 2070-1721. RFC 6763.
- ^ 스팸하우스의 FAQ
- ^ AOL Archived 2006년 12월 10일 Wayback Machine 참조 페이지
외부 링크
- ICANN DNS 동작
- IP 버전6을 지원하기 위한 RFC 3596 DNS 확장
- RDNS 정책: AOL, Comcast, Craigslist, Misk.com