County IT must advertise a shared DNS prefix into two VRFs without merging the full routing tables. What is the appropriate technique?
Select an answer to reveal the explanation.
Short Explanation
Shared DNS shouldn’t mean marrying the whole SCADA and corporate maps. Route leaking is the narrow hallway that copies just the DNS prefix between VRFs. Export only what you mean to share—leave the rest in its own cabinet.
Full Explanation
Inter-VRF route leaking selectively imports or exports prefixes so shared services such as DNS are reachable from multiple VRFs without collapsing isolation. County IT that must advertise a shared DNS prefix into two VRFs should use controlled leaking—route-targets with import/export maps, or carefully scoped redistribution—so only the DNS prefix is shared. Least-privilege leaking preserves segmentation for every other prefix while allowing the common resolver to serve both tenants on the civic network.
Disabling VRF separation and placing all interfaces in the global table defeats the isolation goal entirely and recreates a single shared routing domain. Redistributing every VRF into BGP with no filters so tables eventually converge merges far more than DNS and destroys the segmentation auditors expect. Configuring identical OSPF process IDs in both VRFs so they auto-merge prefixes is a myth—process ID sameness does not merge VRF tables or bypass VRF boundaries.
Exam caveat: always verify return paths; one-way leaking of DNS without return routing to clients breaks resolution in subtle ways, and overlapping addressing across VRFs can mask mis-leaks. Operational check: leak only the DNS prefix, resolve names from each VRF, traceroute to confirm the intended path to the resolver, and show that other VRF prefixes remain unshared in each routing table.