멀티캐스트 DNS
Multicast DNS컴퓨터 네트워킹에서 mDNS(멀티캐스트 DNS) 프로토콜은 호스트 이름을 로컬 이름 서버를 포함하지 않는 소규모 네트워크 내의 IP 주소로 확인합니다.이 서비스는 제로 컨피규레이션서비스입니다.유니캐스트 Domain Name Service(DNS; 도메인네임 서비스)와 기본적으로 동일한 프로그래밍 인터페이스, 패킷 형식 및 동작 시맨틱을 사용합니다.독립형 프로토콜로 작동하거나 표준 DNS [1]서버와 호환되도록 설계되었습니다.IP Multicast User Datagram Protocol(UDP) 패킷을 사용하며 대부분의 Linux 배포판에 포함된 Apple Bonjour 및 오픈소스 Avahi 소프트웨어 패키지에 의해 구현됩니다.Windows 10 의 실장은 네트워크 프린터의 검출에 한정되어 있었습니다만, 이후의 릴리스에서는 호스트명도 [2]해결했습니다.mDNS 는 RFC 6763 [3]에서 별도로 규정되어 있는 제로 구성의 네트워크 기술인 DNS 서비스 디스커버리(DNS-SD)와 조합해 동작할 수 있습니다.
역사
멀티캐스트 DNS는 2000년 IETF에서 Bill Woodcock과 Bill Manning에 의해 처음 제안되어 13년 [1][4]후 Stuart Cheshire와 Marc Krochmal에 의해 표준 트랙 IETF RFC 6762로 발표되었습니다.
프로토콜 개요
mDNS 클라이언트는 호스트 이름을 해결해야 할 경우 IP 멀티캐스트쿼리 메시지를 발송하여 해당 이름을 가진 호스트에 식별을 요구합니다.그런 다음 대상 머신은 IP 주소를 포함하는 메시지를 멀티캐스트합니다.그 서브넷 내의 모든 머신은 이 정보를 사용하여 mDNS 캐시를 갱신할 수 있습니다.모든 호스트는 Time to Live(TTL; 존속 가능 시간)가 0인 응답 패킷을 전송함으로써 이름에 대한 클레임을 포기할 수 있습니다.
기본적으로는 mDNS는 .local 최상위 도메인으로 끝나는 호스트 이름을 배타적으로 해결합니다.이는 .local에 mDNS를 구현하지 않지만 기존 유니캐스트 DNS 서버를 통해 찾을 수 있는 호스트가 포함되어 있는 경우 문제가 발생할 수 있습니다.이러한 경합을 해결하려면 mDNS가 회피하도록 설계된 네트워크 구성을 변경해야 합니다.
패킷 구조
mDNS 메시지는 다음 주소 지정을 사용하여 전송되는 멀티캐스트 UDP 패킷입니다.
- IPv4 주소 224.0.0.251 또는 IPv6 주소 ff02::fb
- UDP 포트 5353
- 이더넷 프레임을 사용하는 경우 표준 IP 멀티캐스트 MAC 주소 01:00:5E:00:00:FB(IPv4 의 경우) 또는 33:33:00:00:00:00:FB(IPv6 의 경우)
payload 구조는 유니캐스트 DNS 패킷 형식을 기반으로 하며 헤더와 [5]데이터라는2개의 부분으로 구성됩니다.
헤더는 유니캐스트 DNS에서 발견된 것과 동일하며 데이터 부분의 서브섹션(쿼리, 응답, 권한 있는 이름 서버 및 추가 레코드)도 마찬가지입니다.각 서브섹션의 레코드 수는 헤더의 대응하는 *COUNT 필드 값과 일치합니다.
쿼리
쿼리 섹션의 레코드 와이어 형식이 유니캐스트 DNS에서 약간 변경되어 싱글비트 UNICAST-RESPONSE [1]필드가 추가됩니다.
들판 | 묘사 | 길이 비트 |
---|---|---|
QNAME | 쿼리가 관련된 노드의 이름 | 변수 |
Q타입 | 쿼리 유형, 즉 응답에서 반환해야 하는 RR 유형입니다. | 16 |
유니캐스트 응답 | 유니캐스트 응답이 필요한지 여부를 나타내는 부울 플래그 | 1 |
Q클래스 | 인터넷 및 IP 네트워크의 클래스 코드, 1 a.k.a. "IN" | 15 |
유니캐스트 DNS와 마찬가지로 QNAME 필드는 "라벨"이라고 불리는 일련의 길이/값 서브필드로 구성됩니다.각 라벨은 Fully Qualified Domain Name(FQDN; 완전 수식 도메인 이름) 내의 도트로 구분된 하위 문자열 중 하나를 나타냅니다.리스트는 DNS의 "루트"를 나타내는 단일 늘바이트 또는 메시지 내의 다른 위치에 대한 간접 포인터를 시그널링하기 위해 2개의 상위 비트가 설정된 바이트(값 192)로 종료됩니다.이것은 RFC-6762에서는 이름 압축이라고 불립니다.
UNICAST-RESPONSE 필드는 네트워크상의 불필요한 브로드캐스트를 최소화하기 위해 사용됩니다.비트가 설정되어 있는 경우 응답자는 네트워크 전체에 응답을 브로드캐스트하지 않고 직접 문의 노드에 다이렉트 유니캐스트 응답을 송신해야 합니다.
QCLASS 필드는 유니캐스트 DNS와 동일합니다.
자원 레코드
Answers 섹션, Authority-Nameserver 섹션 및 추가 레코드 섹션의 모든 레코드는 동일한 형식을 가지며 집합적으로 Resource Records(RR; 자원 레코드)라고 불립니다.
mDNS의 자원 레코드도 유니캐스트 DNS에 비해 일반적인 형식이 약간 변경되었습니다.
들판 | 묘사 | 길이 비트 |
---|---|---|
RRNAME | 레코드가 관련된 노드의 이름 | 변수 |
RRTYPE | 리소스 레코드 유형 | 16 |
캐시 플래시 | 오래된 캐시 레코드를 삭제할지 여부를 나타내는 부울 플래그 | 1 |
RR클래스 | 인터넷 및 IP 네트워크의 클래스 코드, 1 a.k.a. "IN" | 15 |
TTL | RR을 캐시하는 시간 간격(초단위) | 32 |
길이 | RDATA 필드의 길이(8진수)를 나타내는 정수 | 16 |
데이터 | 자원 데이터. 내부 구조는 RRTYPE에 따라 다릅니다. | 변수 |
CASHE-FLUSH 비트는 이 RRNAME 및 RRTYPE의 기존 캐시 엔트리를 레코드가 덮어쓰지 않고 덮어쓰도록 네이버노드에게 지시하기 위해 사용됩니다.
RDATA 필드의 형식은 유니캐스트 DNS 형식과 동일합니다.단, mDNS의 가장 일반적인 사용 예인 DNS Service Discovery(DNS-SD; DNS 서비스 디스커버리)에서는 일부 형식(특히 TXT 레코드)에 약간의 변경을 지정합니다.
「 」를 참조해 주세요.
- 봉쥬르 슬립 프록시
- 링크 로컬 멀티캐스트 이름 해결(LLMNR)
- 네임 서비스 스위치(NSS)
레퍼런스
- ^ a b c Multicast DNS. Internet Engineering Task Force (IETF). doi:10.17487/RFC6762. RFC 6762.
- ^ mDNS and DNS‐SD slowly making their way into Windows 10, Ctrl blog, 21 October 2015, retrieved 2017-08-30
- ^ DNS Service Discovery. IETF. doi:10.17487/RFC6763. RFC 6763.
- ^ Manning, Bill; Woodcock, Bill (August 2000), Multicast Domain Name Service, IETF
- ^ 를 클릭합니다P. Mockapetris (November 1987). DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Network Working Group, IETF. doi:10.17487/RFC1035. RFC 1035..
외부 링크
- 멀티캐스트 DNS - mDNS 설계자인 Stuart Cheshire가 관리하는 정보 사이트
- LAN 상의 LLMNR, 멀티캐스트 DNS 및 이름