[Day #93 PyATS Series] Automate DNS Resolution Validation Across Sites Using pyATS for Cisco [Python for Network Engineer]

Introduction on the Key Points

Welcome to Day #93 of our 101 Days of pyATS (Vendor-Agnostic) series designed to equip network engineers with production-ready frameworks for automation. Today, we focus on automating DNS resolution validation across distributed sites using pyATS with multi-vendor environments such as Cisco, Arista, Palo Alto, and Fortigate.

DNS plays a critical role in modern networks, enabling hostname resolution and connectivity across services and devices. In large-scale distributed architectures, ensuring consistent and correct DNS resolution across sites is essential to prevent application failures and service disruptions.

With the power of Python for Network Engineer, combined with pyATS automation and structured test frameworks, this masterclass provides a realistic, step-by-step, production-ready validation workflow using both CLI and GUI-based verification techniques.

I will build an end-to-end solution where pyATS automates DNS resolution checks after network changes, providing actionable insights to network engineers in structured reports.

Topology Overview

My testbed includes a multi-site setup with:

• Site 1: Cisco Catalyst switches and Cisco IOS routers.
• Site 2: Arista switches with EOS.
• Site 3: Palo Alto firewalls (PAN-OS).
• Site 4: FortiGate firewalls (FortiOS).

Each site has a DNS server configured to resolve specific domain entries, with inter-site routing enabled via BGP/MPLS or OSPF. The goal is to validate DNS resolution of critical services from any site to another, ensuring no degradation after configuration changes or upgrades.

Topology & Communications

IP Scheme Example:

Communication Flow Diagram

The goal of the validation is to:

• Verify A records
• Ensure PTR lookups work properly
• Validate the correct DNS server is used per site

Workflow Script

from genie.testbed import load
from genie.libs.parser.utils import get_parser_exclude
from genie.libs.clean.stages import CleanStage
import logging

logger = logging.getLogger(__name__)

testbed = load('testbed.yml')

def validate_dns_resolution():
    logger.info("Starting DNS resolution validation...")

    # Iterate through devices
    for device in testbed.devices.values():
        device.connect()
        logger.info(f"Connected to {device.name}")

        # Run DNS test command per vendor
        if 'cisco' in device.platform.lower():
            cmd = 'ping vrf MANAGEMENT host.example.com'
        elif 'arista' in device.platform.lower():
            cmd = 'ping vrf management host.example.com'
        elif 'paloalto' in device.platform.lower():
            cmd = 'ping host.example.com'
        elif 'fortigate' in device.platform.lower():
            cmd = 'execute ping host.example.com'
        else:
            logger.warning(f"Unsupported platform {device.platform}")
            continue

        output = device.parse(cmd)
        logger.info(f"DNS resolution result for {device.name}: {output}")

        # Validate if resolved IP is correct
        resolved_ip = output.get('ping_reply', {}).get('address', None)
        if resolved_ip == 'expected_ip_address':
            logger.info(f"{device.name}: DNS resolution successful")
        else:
            logger.error(f"{device.name}: DNS resolution failed")

        device.disconnect()

    logger.info("DNS validation completed.")

Explanation by Line

1. from genie.testbed import load: Loads the testbed YAML file containing device definitions.
2. logger = logging.getLogger(__name__): Sets up logging for status reporting.
3. testbed = load('testbed.yml'): Loads the production-ready testbed definition.
4. device.connect(): Establishes SSH/NETCONF connection to each device.
5. Conditional logic selects the correct ping command depending on vendor platform.
6. device.parse(cmd): Runs CLI commands and parses the output into structured data.
7. IP validation logic compares resolved IP with expected IP address.
8. Logs outcomes and disconnects cleanly.

testbed.yml Example

testbed:
  name: DNSValidationTestbed
  devices:
    Site1_CiscoRouter:
      type: router
      os: ios
      connections:
        cli:
          protocol: ssh
          ip: 10.1.1.1
          username: admin
          password: CiscoPass
    Site2_AristaSwitch:
      type: switch
      os: eos
      connections:
        cli:
          protocol: ssh
          ip: 10.2.1.1
          username: admin
          password: AristaPass
    Site3_PaloAltoFW:
      type: firewall
      os: panos
      connections:
        cli:
          protocol: ssh
          ip: 10.3.1.1
          username: admin
          password: PaloPass
    Site4_FortiGateFW:
      type: firewall
      os: fortios
      connections:
        cli:
          protocol: ssh
          ip: 10.4.1.1
          username: admin
          password: FortiPass

Post-validation CLI (Real Expected Output)

Cisco Router Example

Router# ping vrf MANAGEMENT host.example.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to host.example.com, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 ms

Arista Switch Example

Switch# ping vrf management host.example.com
Sending 5, 100-byte ICMP Echos to host.example.com
.....
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

FAQs

Q1: Why should DNS resolution be validated across multiple sites using automation?
A1: DNS is a foundational service that underpins routing, application access, and end-user experience. In multi-site enterprise networks, DNS misconfiguration or propagation delays can cause localized outages (e.g., users in one branch cannot resolve corporate apps while others can). Automating DNS resolution validation ensures:

• Each site can resolve critical internal/external domains.
• Latency and response consistency are measured.
• DNS redundancy (primary/secondary servers) is verified.
  This reduces troubleshooting time and ensures reliable application availability.

Q2: How does pyATS perform DNS validation across sites?
A2:

• Step 1: pyATS connects to edge routers/firewalls or test devices at each site using the testbed.yml.
• Step 2: It executes DNS lookup commands (e.g., ping <hostname>, nslookup, or dig) depending on platform support.
• Step 3: The Genie parsers convert CLI outputs into structured data, capturing A/AAAA records, response times, and server IPs.
• Step 4: A policy file defines expected resolutions (e.g., www.corporate.com → 192.168.10.50).
• Step 5: The framework compares actual vs expected results and flags mismatches in reports.

Q3: What specific checks should an automated DNS validation workflow include?
A3:

1. Hostname-to-IP Resolution – Does the hostname resolve to the expected IP?
2. Redundancy Check – Do both primary and secondary DNS servers respond?
3. Latency Measurement – How quickly does the DNS response return?
4. Record Type Validation – Are A/AAAA (IPv4/IPv6) records returned properly?
5. Split-Horizon Consistency – Are internal/external sites resolving correctly?
6. Negative Testing – Do non-existent domains return NXDOMAIN instead of random IPs?

Q4: How do you handle multi-site test execution efficiently?
A4: pyATS supports parallel testing using job files and distributed testbed definitions. Each site’s router/firewall/client is treated as a unique testbed device. Tests are dispatched concurrently, and results are aggregated into a single report. This enables operators to validate 20–30 sites simultaneously without manually logging into each location.

Q5: How can DNS resolution validation be integrated into CI/CD pipelines?
A5:

• Include DNS validation scripts in a Jenkins/GitLab pipeline that runs before and after major rollouts.
• Trigger tests automatically whenever a DNS policy change or new zone entry is pushed.
• Publish results as HTML/PDF reports so management can track DNS health continuously.
  This integration ensures DNS changes don’t break critical services.

Q6: What are common failure scenarios DNS validation can catch early?
A6:

1. Site A resolves intranet.company.com but Site B resolves to NXDOMAIN.
2. A DNS server at one branch responds slowly (>1s latency).
3. Primary DNS server unreachable; secondary not configured.
4. Incorrect DNS records propagated to only part of the global network.
5. IPv6 clients failing because AAAA records are missing.
   By catching these issues proactively, teams prevent escalations before users complain.

Q7: How are results presented to both engineers and management?
A7:

• Engineers: Detailed CLI outputs (nslookup, ping, show hosts) plus structured pyATS parsed results for root-cause analysis.
• Management: Summarized compliance report (e.g., All 25 sites resolved critical services, 2 sites failed with latency >1s).
  Reports can be auto-exported into CSV, Markdown, or PDF formats, making them suitable for both technical and non-technical stakeholders.

YouTube Link

Watch the Complete Python for Network Engineer: Automate DNS Resolution Validation Across Sites Using pyATS for Cisco [Python for Network Engineer] Lab Demo & Explanation on our channel:

Join Our Training

To deeply master network automation using Python for Network Engineer and pyATS, join our 3-month instructor-led training course by Trainer Sagar Dhawan.

Learn real-world production-ready frameworks, automation workflows, and gain hands-on expertise in integrating Python, Ansible, and APIs for multi-vendor environments.

Explore the course now → https://course.networkjourney.com/python-ansible-api-cisco-devnet-for-network-engineers/

Unlock the full potential of network automation in your organization today!

Enroll Now & Future‑Proof Your Career
Email: info@networkjourney.com
WhatsApp / Call: +91 97395 21088