Brug DNS TXT-poster med indholdsbuffere til Apple-enheder
Føj TXT-posterne til DNS-zonearkivet
Føj en eller flere TXT-poster til zonearkivet for dit lokale domæne på DNS-serveren. Føj DNS TXT-posten til den zone, der:
Er autoritativ for domænet
Svarer til standardsøgedomænet for netværksklienter
Hvis din organisation f.eks. leverer DNS-tjenesten til dit eget domæne og er autoritetskilde for værtsnavnene til betterbag.com, skal du placere TXT-posten til bufferlagring i zonearkivet betterbag.com.
Vigtigt: Hvis du ikke er vært for den autoritative DNS-tjeneste til dit domæne, kan du ikke selv tilføje TXT-posten. Kontakt DNS-udbyderen for at få dem til at tilføje TXT-posten.
Hvis du bruger BIND9 DNS, kan du kopiere den TXT-post, der blev oprettet, og indsætte den i DNS-zonearkivet.
Hvis der er tale om BIND9-baseret DNS på Linux, befinder arkivet sig i biblioteket /private/etc/bind/, og zonearkivnavnet er defineret i /private/etc/bind/named.conf (sandsynligvis “db.betterbag.com.”).
Hvis du bruger Windows DNS, skal du gøre et af følgende:
Hvis du oprettede tekstposten vha. tjenesten til indlæsning af indhold i buffer: Erstat variablen ZoneName i den oprettede kommando med dit netværks DNS-zonenavn, og start derefter kommandoen på din Windows DNS-computer.
Hvis du oprettede tekstposten manuelt: Angiv TXT-postoplysningerne manuelt vha. Windows Server-administrationsværktøjerne.
Brug DNS TXT-poster til at publicere indhold på tværs af flere offentlige IP-adresser
Hvis dit netværk bruger flere offentlige IP-adresser til at oprette forbindelse til internettet, så en indholdsbuffer muligvis registreres med en anden adresse end den, som en klient bruger til søgning, skal du forsyne både indholdsbufferen og klienterne med en liste med de pågældende adresser. Apple bruger disse lister til at krydstilpasse registrerings- og søgningsanmodninger, der omfatter flere offentlige IP-adresser.
For at undgå manuel konfiguration af klienter bruger indlæsning af indhold i buffer DNS TXT-poster til publicering af oplysningerne om offentlige IP-adresser til klienter på dit netværk. TXT-posten skal publiceres i det standard DNS-søgedomæne, der bruges af klienterne.
Med macOS 10.15 og nyere versioner kan du også angive foretrukne lokale IP-adresser for at reducere omfanget af andre indholdsbuffere på dit netværk. Hvis du ikke angiver foretrukne lokale IP-adresser i en TXT-post, vil alle klienter benytte en vilkårlig indholdsbuffer.
De korrekte data til TXT-posten for offentlige IP-adresseudsnit kan genereres automatisk eller angives manuelt. I begge tilfælde skal du redigere DNS-posten eller give indstillingerne til din DNS-udbyder for at oprette eller redigere TXT-posten i zonearkivet. Bemærk, at du ikke automatisk kan generere TXT-poster til foretrukne lokale IP-adresser. Disse skal oprettes manuelt.
Bemærk: Posterne er kun nødvendige til dit interne netværk. En ekstern DNS har ikke behov for den ekstra post.
DNS TXT-postens format
Syntaksen til angivelse af TXT-poster og andre tegn end ASCII i TXT-poster afhænger af DNS-serveren. De viste eksempler skal blot illustrere mulighederne.
DNS-tekstposterne til indlæsning af indhold i buffer har samme format som DNS-SD TXT-poster (nøgle-/værdipar):
name._tcp 10800 IN TXT "[prs|prn|fss|fsn]=addressRanges"Brug prs- og prn-nøglerne til offentlige IP-adresseudsnit; brug fss- og fsn-nøglerne til lokale IP-adresseudsnit i foretrukne indholdsbuffere.
Følgende eksempler angiver begge samme sæt af to IP-adresseudsnit: et udsnit, der begynder med 17.53.22.2 og slutter med 17.53.22.254, og et udsnit, der består af en enkelt IP-adresse, 17.53.23.1. Forskellen mellem dem er, at første eksempel bruger nøglen prs, og andet eksempel bruger nøglen 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"Nøglerne anvender forskellige formater til de IP-adresseudsnit, der angives i værdien:
prs eller fss: Værdien af nøglen
prsellerfsser en rækkefølge af kommaadskilte udsnit af IP-adresser i præsentationsformat (ASCII-priknotation). Denne syntaks er beregnet til nem konfiguration. Et udsnit består af enten en enkelt IP-adresse eller to IP-adresser adskilt af en bindestreg.prn eller fsn: Værdien af nøglen
prnellerfsner en rækkefølge af sammenkædede udsnit af IP-adresser i binært big-endian-format. Denne syntaks er beregnet til udsnitsrækkefølger, der er for lange til en DNS-post, når de angives i præsentationsformat. Foran hvert udsnit i rækkefølgen står en byte, der angiver det efterfølgende udsnits type:0x14 angiver en enkelt IPv4-adresse.
0x24 angiver et start- og slut-IPv4-adresseudsnit.
Du kan kæde flere poster sammen. I så fald skal du give den første post navnet _aaplcache._tcp og efterfølgende poster fra _aaplcache1._tcp til _aaplcache24._tcp, dvs. højst 25 serieforbundne poster i alt.
Af hensyn til kompatibiliteten med klienter, der bruger macOS 10.14 og tidligere versioner, skal poster, der benytter prs- eller prn-nøgler, placeres før poster, der bruger fss- eller fsn-nøgler.
Sammenkæd poster ved at placere et fortsættelsesmærke på alle TXT-poster undtagen den sidste.
Syntaksen for prs og prn kan blandes mellem poster i serien. I syntaksen fpr prs skal du tilføje “,more” sidst i postværdien. I syntaksen for prn skal du tilføje “+” (0x2b) sidst i postværdien. Den første post, der ikke har et fortsættelsesmærke, afslutter serien.
Serieforbundne poster fortolkes i bundter af fem ad gangen. Det vil sige, at _aaplcache._tcp og _aaplcache1._tcp til _aaplcache4._tcp fortolkes parallelt først. Hvis de alle slutter med fortsættelsesmærker, fortolkes derefter _aaplcache5._tcp til _aaplcache9._tcp og så videre.
Her er et eksempel på tre serieforbundne poster:
_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"Eksempel 1
Dette eksempel viser et scenarie, hvor der både kræves en prs- eller prn-post og en fss- eller en fsn-post.
Lad os antage, at du allerede har en DNS TXT-post med navnet “_aaplcache._tcp” med værdien “prs=203.0.113.10-203.0.113.19” og tre anvendte indholdsbuffere med de lokale adresser 10.0.0.30, 10.1.0.30 og 10.2.0.30. De to første anvendes udelukkende til delt indhold, og den sidste anvendes både til delt indhold og iCloud-indhold.
For at forhindre klienter i at benytte en uautoriseret indholdsbuffer kan du føje ”more” til denne post og tilføje en ny post som vist her:
_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.30Så længe mindst en af de tre indholdsbuffere bruger denne metode, vil enheder med iOS 13, iPadOS 13.1, macOS 10.15 og tvOS 13 eller nyere versioner, udelukkende bruge disse indholdsbuffere, når de leder efter indhold. Hvis alle tre er offline, kan klienter, der leder efter delt indhold, benytte en vilkårlig, tilgængelig indholdsbuffer.
Så længe 10.2.0.30 bruger denne metode, vil enheder med iOS 13, iPadOS 13.1, macOS 10.15 og tvOS 13 eller nyere versioner udelukkende brugde den, når de leder efter iCloud-indhold. Hvis den er offline, bruger klienter, der leder efter iCloud-indhold, en vilkårlig, tilgængelig indholdsbuffer.
Enheder med iOS 12 eller ældre versioner og macOS 10.14 eller ældre versioner bruger en vilkårlig, tilgængelig indholdsbuffer og ikke kun disse tre.
Eksempel 2
Dette eksempel viser et scenarie, hvor der hverken kræves en prs- eller prn-post.
Lad os antage, at du kun har én offentlig IP-adresse og ikke bruger DNS TXT-postfunktionen overhovedet, men har nogle få indholdsbuffere på et subnet, der er reserveret til servere (192.168.50/24).
For at forhindre uautoriserede indholdsbuffere, kan du oprette en post således:
_aaplcache._tcp fss=192.168.50.1-192.168.50.254Så længe der er mindst en tilgængelig indholdsbuffer inden for dette interval for den klient, den søger efter (delt eller iCloud), vil klienter med iOS 13, iPadOS 13.1, macOS 10.15 og tvOS 13 og nyere versioner udelukkende bruge denne indholdsbuffer.