Innledning
Ville det ikke være fint å ha en metode du kan bruke til å kontrollere hva DNS-server blir brukt av en DNS-klient basert på FQDN eller noen andre kriterier du setter i Group Policy? Denne typen funksjonen vil utvide din klient-side navn løsningsalternativene ved å la klienten til å bruke DNS-tjenere som er satt på systemenes NIC (s) eller
bruke forskjellige DNS-servere basert på FQDN, DNS suffiks, DNS prefiks, IPv4 Network ID, IPv6 Network ID eller noe annet! Vel, kan du gjøre det i et begrenset sett med scenarier ved å utnytte den Name Resolution Regler Tabell følger med Windows Server 2008 R2.
NRPT definerer DNS klienten atferd basert på søk fra DNS-klienten. Dersom kunden gjør en spørring for en FQDN, ville dette søket sendes til DNS-serveren er konfigurert på klientens NIC. Dersom kunden gjør en spørring for en annen FQDN, ville dette søket sendes til en annen DNS-server, ikke konfigurert på kundens NIC, men basert på en oppføring i NRPT. Faktisk, Windows 7 og Windows Server 2008 R2 dra nytte av denne muligheten til å kontrollere hva DNS-servere er brukt og hva DNS-klienten atferd bør være basert på spørre emnet i sine implementeringer av DNSSEC og Direct.
Før DNS-klienten utsteder en DNS-spørring, vil den sjekke med NRPT å se om det bør sette noen flagg på forespørsel. Etter å ha mottatt et svar fra DNS-serveren, vil DNS-klienten sjekke på nytt for å se om det er noen andre krav til behandling før du går fremover. Hvis det ikke er NRPT konfigurert på klient, så kunden vil bruke innstillingen DNS-serveren skjønte på sin NIC å sende DNS-spørringer til, og det vil ikke være noen spesiell behandling av DNS-spørringer enten før eller etter forespørsel er sendt.
For å få et bedre inntrykk av hva du kan gjøre i NRPT, la oss ta en titt på NRPT innstillingene i Active Directory Group Policy. Du finner dem ved å åpne Group Policy Editor og navigere til Datamaskinkonfigurasjon \\ Policies \\ Windows-innstillinger \\ Name Resolution Regler
, sett i figuren nedenfor.
Figur 1
I den høyre ruten i konsollen du vil se NRPT konfigurasjonsgrensesnitt, som vist i figuren nedenfor.
Figur 2
La oss nå undersøke alternativene og se hvordan de blir brukt til å konfigurere en NRPT oppføring.
I I hvilken del av navne gjelder denne regelen?
Vel, bestemmer du om du vil at regelen skal gjelde for en suffiks
, en Prefix
, en FQDN
, en Subnet (IPv4)
, en Subnet (IPv6)
eller Alle
. Hvis du velger "Alle" vil alle forespørsler vil bli kontrollert av den politikken du satt for denne NRPT oppføring. I dette eksempelet har vi valgt suffiks
alternativ og gikk inn i en DNS-suffiks av ipadsux.org
.
Det neste alternativet er Certification Authority (valgfritt)
setting. Dette brukes når du bruker NRPT for en DNSSEC distribusjon. DNSSEC er en metode du kan bruke for å sikre at DNS-spørringer og tiltak er gjort på en sikker måte, og at DNS-klienter kan autentisere DNS-servere for spørringer som er laget for vertene i bestemte domener. Du kan klikke på Bla
knappen for å finne et CA-sertifikat som du vil at DNS-klienten til å stole på når autentisering av DNS server i et DNSSEC distribusjon.
Det er to kategorier som du kan bruke til å skape denne regelen for NRPT: fanen DNSSEC Hotell og DNS-innstillinger for Direct
. Når du oppretter regelen, bruker bare én av disse fanene på en gang. Generelt er det bedre å bryte reglene ut, separere DNSSEC regler fra Direct regler; dette gjør dem lettere å holde styr på og rydde uavhengig om du noen gang har behov for å gjøre det.
I kategorien DNSSEC Når du har gjort ditt DNSSEC utvalg konfigurasjonen, kan du klikke på Oppdater Nå la oss undersøke muligheter for DNS-innstillinger for Direct Legg merke til at hvis du ønsker å opprette en ny regel, bør du klikke på Clear De alternativene du har her inkluderer : Det er ett mer dialogboksen som er av interesse hvis du distribuerer en Windows Direct løsning. Klikk på Avansert global politikk Settings Dette Dialogboksen utsetter tre deler: Network Location Dependency Query Failure Løse både IPv4 og IPv6-adresser for navnene Alt dette kan være en moot problem uansett, som Tom forteller meg at når du bruker UAG for Direct løsning håndterer UAG konfigurasjonen av NRPT og leverer de riktige innstillingene til Direct kunder bruker en GPO som er brukt bare til Directklientmaskiner som er medlemmer av en sikkerhetsgruppen som GPO er brukt. Så, når du arbeider med UAG Direct, du trenger ikke å forholde seg til denne dialogboksen. Likevel, det ville være fint å få noen dokumentasjon på de manglende innstillinger. I denne artikkelen ble du introdusert til Name Resolution Regler Table (NRPT) og noen av de konfigurasjonsmuligheter tilgjengelig i NRPT. Den NRPT lar deg tilpasse navneoppslag oppførsel på DNS-klienter, avhengig av innstillingene i tabellen. De to viktigste scenarier der NRPT er påført inkluderer miljøer som er konfigurert til å støtte DNSSEC og Direct. DNSSEC er en metode du kan bruke til å sikre infrastrukturen navn oppløsning, og Directaccess er en ny ekstern tilgang teknologi som gjør at datamaskiner til å koble til corpnet fra hvor som helst uten en VPN-tilkobling. Vi vil følge opp denne artikkelen ved å gå inn i flere detaljer om DNSSEC og hvordan du kan bruke og konfigurere DNSSEC til at din infrastruktur bedriftens navn oppløsning i en fremtidig artikkel. Ser deg da! -Deb.
, sett i figuren under, har du følgende alternativer :
Aktiver DNSSEC i denne regelen.
Når denne er aktivert, spørsmål for FQDN angitt ovenfor vil kreve bruk av DNSSEC
Innstilling denne verdien til å kontrollere hvordan DNS klient behandler DNS-spørringer; det hverken DNS server atferd eller konfigurasjon av en "tillitsanker" (brukes av DNSSEC å sikre soner) på DNS-serveren. Hva det gjør er å fortelle de DNS-klienter for å se etter den "Godkjente data" litt i DNS-svar returneres av DNS-serveren for DNS-spørring utstedt av klienten. Hvis "Godkjente data" bit ikke er satt (noe som bekrefter at responsen data ikke er validert) DNS-klienten vil slippe respons og vurdere spørringen som mislyktes.
, Lav: 3DES, AES (128, 192, 256)
, Medium: AES (128, 192 256)
, eller Høy: AES (192256)
. Den "ingen kryptering" alternativet gir for maskin godkjenning, og DNS-spørring trafikken vil gå i klartekst. Hvis du velger en krypteringsalternativet, vil koblingen IPsec bli både autentisert og kryptert ved hjelp av krypteringsnivå du velger her, og det støttes av klienten og serveren.
Figur 3
knappen og deretter se NRPT oppføring i Name Resolution Regler Tabell
sett i figuren nedenfor. Legg merke til at det er to knapper under bordet: Slett regel Hotell og Rediger regel
. Disse knappene vises når du klikker på linjen på bordet for retts interesse. Hvis du ønsker å redigere regelen, klikker du på Rediger regel
knappen. Hvis du ønsker å slette regelen, klikker du på Slett regel
knappen. Det er ganske enkelt.
Figur 4
. Legg merke til at det er en liten stavefeil på denne gruppepolicy siden Object konfigurasjon. Direct bør være ett ord
men er oppført som en to-ord sikt flere ganger i denne konfigurasjonen grensesnittet. Jeg fortalte Tom om dette, og nå er det hans problem :)
knappen og start konfigurasjon over fra Å hvilken del av navne gjelder denne regelen
seksjonen og Certification Authority
delen. Deretter kan du klikke på Opprett
knappen for å opprette den nye regelen og bruke Rediger regel
knappen for å gjøre endringer senere hvis du vil.
Aktiver DNS-innstillingene for Direct Access [sic] i denne regelen Bilde:. Dette valget slår på DNS-innstillingene er konfigurert her for Direct kunder
Dette er et interessant alternativ, som kan ha flere betydninger. Imidlertid synes dette å ikke være dokumentert, så jeg anbefaler at du unngår dette alternativet inntil slik dokumentasjon blir tilgjengelig
Dette valget gjør det samme alternativer som IPsec valgene sett tidligere. Du har de samme mulighetene, som inkluderer Ingen kryptering, Low, Medium Hotell og Høy
.
Figur 5
knappen for å avsløre denne dialogboksen, som vist i figuren nedenfor.
Figur 6
Network Location Dependency
alternativet kan du konfigurere roaming-innstillinger. Standard er La Network ID (NID) avgjøre når Direct Access [sic] innstillingene skal brukes
. Dette er en udokumentert alternativ, men jeg tror det er knyttet til hvorvidt klienten er i stand til å koble til en bestemt ressurs på corpnet å avgjøre hvilke DNS-innstillingene til å bruke når klienten fungerer som en Direct klient. Dersom kunden oppdager at det er på nett, vil den bruke DNS-innstillingene er konfigurert på sin NIC. Hvis Direct klienten ikke er i stand til å koble til en ressurs som ligger på corpnet, så Direct klienten forutsetter at det er off-nettverk og vil bruke Direct innstillinger for navneløsing. Men dette er en kvalifisert gjetning, siden disse innstillingene er udokumentert på dette tidspunktet.
opsjonen bestemmer hvordan navneoppslag skal håndteres hvis det er et DNS-navn spørring svikt. Hvis du velger Konfigurer spørfeilalternativer
boksen, er standardinnstillingen alltid falle tilbake til Link-Local Multicast Name Resolution (LLMNR) og NetBIOS hvis navnet ikke eksisterer i DNS eller hvis DNS Serverne er uoppnåelig når du er på et privat nettverk (moderat sikker).
Dette alternativet tillater bruk av lokale navn resolusjonen om et privat nettverk når corpnet DNS-serverne er utilgjengelige til Direct klienten.
Query Resolution delen er også interessant. Igjen, dette er hele dialogboksen ikke dokumentert, men jeg tror vi kan finne ut av det. Når du velger Konfigurer spørløsningsalternativene
boksen, har du to alternativer: Løse kun IPv6-adresse for navnene (anbefales) Hotell og Løse både IPv4 og IPv6-adresser for navn
. Dette er interessant fordi når Direct klienten kobler til ressurser på corpnet over en Directaccess-tilkobling, er bruker bare
IPv6-adresser, som all kommunikasjon fra Direct klienten til corpnet er IPv6 kommunikasjon - IPv4 er aldri brukt når den Direct klienten kobler til corpnet. Kanskje det er derfor det er anbefalt.
ikke synes å være fornuftig i Direct klient sammenheng gitt de fakta som nevnt ovenfor. Men kanskje dette betyr at du kan bruke IPv4 for lokale navnet oppløsning eller navn som ikke er behandlet av NRPT? Jeg tror vi blir nødt til å vente til Microsoft for å lage noen dokumentasjon på dette konfigurasjonssiden før vi gjør noen harde og raske beslutninger om nytten av disse innstillingene.
Sammendrag