Apple 기기용 콘텐츠 캐시와 DNS TXT 레코드 사용하기
DNS 영역 파일에 TXT 레코드 추가하기
하나 이상의 TXT 레코드를 사용자의 DNS 서버에 있는 로컬 도메인의 영역 파일에 추가합니다. 다음을 만족하는 영역에 DNS TXT 레코드를 추가하십시오.
도메인을 신뢰할 수 있음
네트워크 클라이언트의 기본 검색 도메인과 일치함
예를 들어, 사용자의 조직에서 사용자의 도메인을 위한 DNS 서비스를 제공하고 betterbag.com의 호스트 이름에 대한 인증 기관의 소스인 경우 betterbag.com 영역 파일에 캐싱 TXT 레코드를 배치합니다.
중요사항: 사용자의 도메인을 신뢰할 수 있는 DNS 서비스에 호스트하지 않았다면 TXT 레코드 자체를 추가할 수 없습니다. DNS 제공업체와 협의하여 제공된 TXT 레코드를 추가하십시오.
BIND9 DNS를 사용하는 경우 생성된 TXT 레코드를 복사하여 사용자의 DNS 영역 파일에 붙여넣으십시오.
Linux에 있는 BIND9-기반 DNS의 경우 이 파일은 /private/etc/bind/ 디렉토리에 있으며 영역 파일 이름은 /private/etc/bind/named.conf(아마도 ‘db.betterbag.com.’일 것임)로 정의되었습니다.
Windows DNS를 사용하는 경우 다음 중 하나를 수행하십시오.
콘텐츠 캐싱 서비스를 사용하여 텍스트 레코드를 생성한 경우: 생성된 명령어에 있는 ZoneName 변수를 네트워크의 DNS 영역 이름으로 대치한 다음, Windows DNS 컴퓨터에서 명령어를 실행하십시오.
텍스트 레코드를 수동으로 생성한 경우: Windows Server 관리 도구를 사용하여 수동으로 TXT 레코드 정보를 입력하십시오.
DNS TXT 레코드를 사용해서 여러 공인 IP 주소에서 콘텐츠 발행하기
사용자의 네트워크가 여러 개의 공용 IP를 사용하여 인터넷에 연결하는 경우, 클라이언트가 콘텐츠 캐시를 탐색하는 데 사용하는 주소와 다른 주소를 사용하여 콘텐츠 캐시가 등록할 수 있도록 사용자는 콘텐츠 캐시와 클라이언트에 해당 주소 목록을 제공해야 합니다. Apple은 이 목록을 사용하여 여러 개의 공인 IP 주소가 포함된 등록 및 인식 요청을 교차 연결합니다.
클라이언트를 수동으로 구성하지 않기 위해 콘텐츠 캐싱은 DNS TXT 레코드를 사용하여 사용자 네트워크 클라이언트의 공용 IP 주소 정보를 제공합니다. TXT 레코드는 클라이언트가 사용하는 기본 DNS 검색 도메인에서 발행되어야 합니다.
macOS 10.15 이상 버전에서 사용자 네트워크상의 다른 콘텐츠 캐시의 영향을 줄이기 위해, 선호하는 로컬 IP 주소를 지정할 수 있습니다. 선호하는 로컬 IP 주소가 TXT 레코드에 지정되지 않은 경우, 모든 클라이언트는 사용 가능한 모든 콘텐츠 캐시를 사용하게 됩니다.
공용 IP 주소 범위에 대한 TXT 레코드의 올바른 데이터는 자동으로 생성하거나 수동으로 생성할 수 있습니다. 두 경우 모두 DNS 레코드를 편집하거나 DNS 제공업체에 설정을 제공하여 영역 파일에 TXT 레코드를 생성 또는 편집해야 합니다. 선호하는 로컬 IP 주소에 대한 TXT 레코드는 자동으로 생성할 수 없으며 수동으로 생성해야 합니다.
참고: 이 레코드는 내부 네트워크에만 필요합니다. 외부 DNS는 추가 레코드를 요구하지 않습니다.
DNS TXT 레코드 포맷
TXT 레코드를 지정하기 위한 구문 및 TXT 레코드의 비ASCII 문자는 사용자의 DNS 서버에 따라 다를 수 있습니다. 여기에 나타난 예제는 참조용입니다.
콘텐츠 캐싱의 DNS 텍스트 레코드는 다음과 같이 DNS-SD TXT 레코드와 동일한 포맷을 가집니다(키 값 쌍).
name._tcp 10800 IN TXT "[prs|prn|fss|fsn]=addressRanges"공용 IP 주소 범위에는 prs 및 prn 키를 사용하고, 선호하는 콘텐츠 캐시의 로컬 IP 주소 범위에는 fss 및 fsn 키를 사용하십시오.
다음 예제에서는 각 유형이 동일한 두 가지 IP 주소 범위 세트를 정의합니다. ‘17.53.22.2’와 ‘17.53.22.254’ 사이의 범위와 단일 IP 주소인 ‘17.53.23.1’를 포함하는 범위. 두 예제는 첫 번째가 prs 키를 사용하고 두 번째가 prn 키를 사용한다는 것이 다릅니다.
_aaplcache._tcp 10800 IN TXT "prs=17.53.22.2-17.53.22.254,17.53.23.1"_aaplcache._tcp 10800 IN TXT_aaplcache._tcp 10800 IN TXT "prn=\x24\x11\x35\x16\x02\x11\x35\x16\xfe\x14\x11\x35\x17\x01"해당 키들은 키 값으로 지정된 IP 주소 범위에 따라 다음과 같이 서로 다른 포맷을 사용합니다.
prs 또는 fss:
prs또는fss키의 값은 프레젠테이션 포맷(ASCII 점 표기법)의 쉼표로 분리된 IP 주소 범위의 시퀀스입니다. 이 구문은 쉽게 구성하기 위한 것입니다. 범위는 단일 IP 주소나 하이픈으로 분리된 2개의 IP 주소로 구성됩니다.prn 또는 fsn:
prn또는fsn키의 값은 바이너리 네트워크-바이트-순서 포맷의 연결된 IP 주소 범위의 시퀀스입니다. 이 구문은 프레젠테이션 포맷으로 지정했을 때 DNS 레코드로는 너무 긴 범위 시퀀스를 위한 것입니다. 시퀀스의 각 범위는 다음과 같이 범위 유형을 지정하는 바이트 값이 앞에 나타납니다.‘0x14’는 단일 IPv4 주소를 나타냅니다.
‘0x24’는 시작 및 끝 IPv4 주소 범위를 나타냅니다.
여러 개의 레코드를 함께 연결할 수 있습니다. 레코드를 연결한 다음, 첫 번째 레코드의 이름을 _aaplcache._tcp로 지정하고 두 번째부터는 _aaplcache1._tcp부터 _aaplcache24._tcp까지 이름을 지정하여 최대 25개의 연결된 레코드의 이름을 지정할 수 있습니다.
macOS 10.14 또는 이전 버전을 사용하는 클라이언트와 호환성을 유지하려면, fss 또는 fsn keys를 사용하는 레코드 이전에 prs 또는 prn 키를 사용하는 레코드를 배치하십시오.
마지막 TXT 레코드를 제외한 모든 레코드에 계속 표시자를 두어 레코드를 연결합니다.
prs 및 prn 구문은 체인에 있는 레코드 사이에서 혼합할 수 있습니다. prs 구문으로 레코드 값 끝에 ‘,more’를 추가합니다. prn 구문으로 레코드 값 끝에 ‘+’(0x2b)를 추가합니다. 이러한 계속 표시자가 없는 첫 번째 레코드는 체인을 종료합니다.
연결된 레코드는 한 번에 5개의 배치로 처리됩니다. 즉, _aaplcache._tcp 및 _aaplcache1._tcp 부터 _aaplcache4._tcp까지 먼저 병렬로 처리됩니다. 그리고 모두 연속 표시자로 끝날 경우 _aaplcache9._tcp를 통해 _aaplcache5._tcp가 다음으로 처리되는 방식입니다.
다음은 연결된 3개의 레코드에 대한 예입니다.
_aaplcache._tcp 10800 IN TXT "prs=17.250.1.1,17.250.2.1-17.250.2.254,more"_aaplcache1._tcp 10800 IN TXT "prn=\x24\x11\xfa\x03\x01\x11\xfa\x03\xfe+"_aaplcache2._tcp 10800 IN TXT "prs=17.250.4.5"예제 1
이 예제는 prs 또는 prn 레코드와 fss 또는 fsn 레코드가 동시에 필요한 상황을 나타냅니다.
‘prs=203.0.113.10-203.0.113.19’ 값을 가지고 ‘_aaplcache._tcp’라는 이름이 붙은 하나의 DNS TXT 레코드와, 10.0.0.30, 10.1.0.30, 및 10.2.0.30의 로컬 주소가 할당된 세 개의 콘텐츠 캐시가 있다고 가정합니다. 앞선 두 개의 로컬 주소는 공유 콘텐츠만을 제공하며 마지막 로컬 주소는 공유 및 iCloud 콘텐츠 모두를 제공합니다.
클라이언트가 권한이 없는 콘텐츠 캐시를 사용하지 못하게 하려면, 다음과 같이 위에서 언급한 레코드에 ‘,more’를 덧붙이고 두 번째 레코드를 추가할 수 있습니다.
_aaplcache._tcp prs=203.0.113.10-203.0.113.19,more_aaplcache1._tcp fss=10.0.0.30,10.1.0.30,10.2.0.30세 개의 콘텐츠 캐시 중 최소 하나가 이 방식을 사용하는 한, 공유 콘텐츠를 찾는 iOS 13, iPadOS 13.1, macOS 10.15, tvOS 13 이상이 설치된 기기는 독점적으로 이 세 개의 콘텐츠 캐시를 사용합니다. 세 개가 모두 오프라인인 경우, 공유 콘텐츠를 찾는 클라이언트는 사용 가능한 콘텐츠 캐시를 사용할 수 있습니다.
로컬 주소 10.2.0.30이 이 방식을 사용하는 경우, iCloud 콘텐츠를 찾는 iOS 13, iPadOS 13.1, macOS 10.15, tvOS 13 이상이 설치된 기기는 독점적으로 이 로컬 주소를 사용합니다. 이 로컬 주소가 오프라인인 경우, iCloud 콘텐츠를 찾는 클라이언트는 사용 가능한 콘텐츠 캐시를 사용하게 됩니다.
iOS 12 또는 이전 버전 및 macOS 10.14 또는 이전 버전이 설치된 기기는 위의 세 가지 콘텐츠 캐시 외에도 지원되는 모든 콘텐츠 캐시를 사용합니다.
예제 2
이 예제는 prs 또는 prn 레코드가 필요하지 않은 상황을 나타냅니다.
하나의 공용 IP 주소만이 제공되며 DNS TXT 레코드 기능을 전혀 사용하지 않지만, 서브넷상에 서버 기기(192.168.50/24)에 한정된 약간의 콘텐츠 캐시는 가지고 있다고 가정합니다.
인증되지 않은 콘텐츠 캐시를 방지하려면, 하나의 레코드를 다음과 같이 설정하십시오.
_aaplcache._tcp fss=192.168.50.1-192.168.50.254원하는 클라이언트 유형(공유 또는 iCloud)에 대해 최소 하나의 콘텐츠 캐시가 해당 범위 안에서 사용 가능한 경우, iOS 13, iPadOS 13.1, macOS 10.15, tvOS 13 이상 버전의 클라이언트는 독점적으로 이 콘텐츠 캐시를 사용하게 됩니다.