Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Netwerkdiagram

Achtergrondinformatie

Configureren

Verifiëren

Gerelateerde informatie

Inleiding

Dit document beschrijft de werking van Domain Name System (DNS) op Cisco adaptieve security applicatie (ASA) wanneer FDQN-objecten worden gebruikt.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van Cisco ASA.

Gebruikte componenten

Om de werking van de DNS te verduidelijken wanneer in een gesimuleerde productieomgeving meerdere FQDN’s op de ASA zijn geconfigureerd, is een ASAv ingesteld met één interface met het internet en één interface die is aangesloten op een pc-apparaat dat op de ESXi-server wordt gehost. Voor deze simulatie werd de ASAv interim code 9.8.4(10) gebruikt.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Netwerkdiagram

De topologieopstelling wordt hier getoond.

Achtergrondinformatie

Wanneer meerdere FQDN-objecten (Fully Qualified Domain Name) op een ASA zijn geconfigureerd, zou een eindgebruiker die probeert toegang te krijgen tot een van de URL’s die in de FQDN-objecten zijn gedefinieerd, meerdere DNS-vragen waarnemen die door de ASA zijn verzonden. Dit document is bedoeld om beter te begrijpen waarom dit soort gedrag wordt waargenomen.

Configureren

De client-pc is geconfigureerd met deze IP-, subnetmasker- en naamservers voor DNS-resolutie.

Op de ASA waren twee interfaces geconfigureerd, 1 binneninterface met een beveiligingsniveau van 100 waarmee de PC was verbonden en 1 buiteninterface die verbinding met het internet heeft.

Hier is de Gig0/1 interface de buiteninterface met een interface IP van 10.197.223.9 en de Gig0/3 interface is de binneninterface met een interface IP van 10.10.10.1 en verbonden met PC op het andere eind.

Configureer de DNS-instelling op de ASA zoals hier wordt getoond:

Configureer 4 FQDN-objecten voor www.facebook.com, www.google.com, www.instagram.com en www.twitter.com.

Stel een opname in op de ASA buiteninterface om DNS-verkeer op te nemen. Probeer vervolgens vanaf de client-pc www.google.com te openen vanuit een browser.

Wat observeer je? Neem een kijkje bij de pakketopname.

Hier zien we dat hoewel we alleen www.google.com probeerden op te lossen, er DNS-vragen werden verzonden voor alle FQDN-objecten.

Kijk nu hoe DNS-caching werkt voor IP's op de ASA om te begrijpen waarom dit gebeurt.

- Wanneer www.google.com wordt getypt in de webbrowser van de client-pc's, stuurt de pc een DNS-query om de URL opgelost te krijgen naar een IP-adres.

- De DNS-server lost vervolgens het PC-verzoek op en geeft een IP-adres terug dat aangeeft dat google.com zich op de opgegeven locatie bevindt.

- De PC initieert vervolgens een TCP verbinding met het opgeloste IP-adres van google.com. Wanneer het pakket echter de ASA bereikt, heeft het geen ACL-regel die aangeeft dat het opgegeven IP is toegestaan of geweigerd.

- De ASA weet echter dat het 4 FQDN-objecten heeft en dat elk van de FQDN-objecten mogelijk kan worden opgelost aan de betreffende IP.

- Vandaar stuurt de ASA DNS-vragen voor alle FQDN-objecten omdat het niet weet welk FQDN-object kan worden opgelost voor het betreffende IP. (Daarom zijn er meerdere DNS-vragen waargenomen).

- De DNS-server lost de FQDN-objecten op met de bijbehorende IP-adressen. Het FQDN-object kan worden opgelost op hetzelfde openbare IP-adres als door de client is opgelost. Anders maakt de ASA een dynamische toegangslijst voor een ander IP-adres dan het adres dat de client probeert te bereiken, waardoor de ASA het pakket laat vallen. Als de gebruiker bijvoorbeeld google.com tot 203.0.113.1 heeft opgelost en de ASA het tot 203.0.113.2 heeft opgelost, creëert de ASA een nieuwe dynamische toegangslijst voor 203.0.113.2 en heeft de gebruiker geen toegang tot de website.

- De volgende keer wanneer een verzoek aankomt, dat om resolutie van een bepaalde IP verzoekt, als dat bepaalde IP op ASA wordt opgeslagen, vraagt het niet alle FQDN voorwerpen opnieuw aangezien een dynamische ACL ingang nu aanwezig zou zijn.

- Als een client bezorgd is over het grote aantal DNS-vragen verzonden door ASA, verhoog de DNS-timer verlopen, en opgegeven eindhosts probeert toegang te krijgen tot de IP-adressen van de bestemming die zich in het DNS-cache bevinden. Als de PC vraagt om een IP, niet opgeslagen op de ASA DNS-cache, worden DNS-vragen verzonden om alle FQDN-objecten op te lossen.

- Een mogelijke oplossing hiervoor, als u nog steeds het aantal DNS-vragen wilt verminderen, zou zijn om het aantal FQDN-objecten te verminderen of om het hele bereik van openbare IP's te definiëren die u zou oplossen van de FQDN-objecten, die echter het doel van een FQDN-object in de eerste plaats verslaat. Cisco Firepower Threat Defence (FTD) is een betere oplossing voor deze use case.

Verifiëren

Om te verifiëren welke IP's aanwezig zijn in de ASA DNS cache waaraan elk van de FQDN-objecten wordt opgelost, kan de opdracht ASA# sh dns worden gebruikt.

Gerelateerde informatie

Cisco technische ondersteuning en downloads