Service Discovery Exposure

Understanding the Risk

Service Discovery records expose information in several ways:

• Revealing internal hostnames - SRV records often point to internal servers
• Exposing service configurations - Records detail port numbers and service priorities
• Mapping infrastructure - Records can reveal how services are distributed
• Identifying technology stacks - Service types indicate what technologies you use

Types of Sensitive Service Records

1. SRV Records

SRV (Service) records specify the location of services like LDAP, SIP, XMPP, and more.

# Example SRV records
_sip._tcp.example.com.    SRV 10 60 5060 sip-server.example.com.
_ldap._tcp.example.com.   SRV 10 0 389 ldap-server.internal.example.com.
_xmpp._tcp.example.com.   SRV 5 0 5222 chat.example.com.
_kerberos._tcp.example.com. SRV 0 0 88 kdc.internal.example.com.

These records can reveal internal server names, ports, and service protocols.

2. SVCB and HTTPS Records

These newer record types provide enhanced service information including connection parameters.

# Example HTTPS record
example.com. HTTPS 1 web.example.com. alpn=h2,h3 port=443 ipv4hint=192.0.2.1

These expose service configurations, supported protocols, and sometimes IP hints.

3. SPF Records with Internal Information

SPF records sometimes include internal mail server information.

# Example SPF record with internal server info
example.com. TXT "v=spf1 ip4:203.0.113.1 a:mail-internal.example.com include:_spf.google.com -all"

4. Unintentional Internal Services

Many organizations expose internal service records without realizing it, particularly for:

• Active Directory services (_ldap, _kerberos, _kpasswd)
• Exchange and email services (_autodiscover)
• Collaboration tools (SIP, XMPP)
• Management interfaces

The Solution

With the exposure risks identified, implementing comprehensive auditing and access controls becomes essential to secure your service discovery infrastructure.

Step 1: Audit Your Service Discovery Records

First, conduct a thorough inventory of your DNS service records:

1. Check for SRV records:

   # Using dig to find SRV records
   dig SRV example.com
   dig _tcp.example.com SRV
   dig _udp.example.com SRV
   
   # Looking for common service prefixes
   for svc in _ldap _kerberos _sip _xmpp _autodiscover; do dig $svc._tcp.example.com SRV; done

2. Check for SVCB/HTTPS records:

   dig SVCB example.com
   dig HTTPS example.com

3. Examine other records for internal information:

   dig TXT example.com  # Check for SPF records with internal servers
   dig MX example.com   # Check for internal mail servers

Step 2: Assess the Necessity of Each Record

For each service discovery record, answer these questions:

• Is this record absolutely necessary for external users?
• Does it expose information about internal infrastructure?
• Could it be restricted to internal DNS only?
• If it must be public, does it reveal more information than necessary?

Step 3: Implement Mitigation Strategies

A. Split DNS Architecture

Implement split DNS (also called split-horizon or split-view DNS), where:

• Internal DNS servers contain all service records needed for internal operations
• External (public) DNS servers only contain records absolutely necessary for external users

# BIND split DNS configuration example (named.conf)
view "internal" {
    match-clients { 10.0.0.0/8; 192.168.0.0/16; };
    recursion yes;

    zone "example.com" {
        type master;
        file "example.com.internal";
    };
};

view "external" {
    match-clients { any; };
    recursion no;

    zone "example.com" {
        type master;
        file "example.com.external";
    };
};

B. Use Different Domains for Internal/External Services

• Keep your public domain (example.com) for external-facing services only
• Use a separate internal domain (example.internal, internal.example.com, or corp.example.com) for internal services
• Ensure the internal domain is not exposed to the public internet

C. Sanitize Necessary Public Records

For service records that must remain public:

• Use generic hostnames instead of descriptive ones (srv01.example.com vs. ldap-primary.example.com)
• Point to proxy or gateway servers instead of directly to internal servers
• Remove unnecessary details from record values

# Instead of:
_sip._tcp.example.com.  SRV 10 60 5060 sip-server-primary.internal.example.com.

# Use:
_sip._tcp.example.com.  SRV 10 60 5060 edge-1.example.com.

D. Use Access Controls for Internal DNS

Ensure internal DNS servers are properly secured:

• Restrict zone transfers to authorized servers
• Implement strict ACLs to prevent external queries
• Use DNS over TLS (DoT) or DNS over HTTPS (DoH) for sensitive internal DNS traffic

E. Regularly Review Public SPF Records

Ensure SPF records don't leak internal information:

• Use IP addresses instead of internal hostnames where possible
• When using the "a:" mechanism, ensure the hostnames don't reveal internal naming patterns
• Consider using a mail gateway to further obscure internal mail infrastructure

Verifying Your Protection

Method 1: External DNS Enumeration

Simulate what an attacker would see by conducting external DNS enumeration:

# Using dig from an external network (not your corporate network)
dig ANY example.com
dig SRV example.com
dig _tcp.example.com SRV

# Using DNSenum or similar tools
dnsenum --enum example.com

Analyze the results to ensure no internal information is leaked.

Method 2: Using Our DNS Security Scanner

Our DNS Security Scanner automatically checks for service discovery information leakage by:

• Scanning for all types of service records
• Identifying records that reveal internal infrastructure
• Detecting naming patterns that suggest internal systems
• Providing recommendations for each potentially sensitive record

Method 3: Regular Security Assessments

Include DNS reconnaissance in your regular security assessments:

• Have a third-party security team attempt to map your infrastructure using only public DNS
• Include DNS information gathering in penetration testing scope
• Use the results to identify and remediate information leakage

Special Considerations

Microsoft 365 and Exchange Online

Microsoft services require specific SRV records for proper functionality:

• _sip, _sipfederationtls, and _autodiscover records are required for proper service operation
• These records should point to Microsoft's services, not your internal infrastructure
• Verify your Microsoft 365 DNS records follow Microsoft's current best practices

Active Directory Federation Services

ADFS requires specific SRV records for federation to work:

• Design your ADFS implementation to minimize exposure of internal details
• Use edge servers and proxies where possible
• Ensure the public-facing components don't leak information about internal structure

XMPP and Collaboration Tools

Many collaboration tools use SRV records for federation and discovery:

• Route external federation through edge servers
• Use separate internal and external domains for these services where possible
• Minimize information disclosure in required public records

Common Misconceptions

• "Nobody looks at our DNS records" - DNS reconnaissance is one of the first steps in any targeted attack. Automated tools regularly scan and index DNS information across the internet.
• "Internal hostnames don't matter if IPs aren't public" - Hostname patterns reveal organizational structure and can help attackers identify potential targets, even without direct access.
• "SRV records are obscure and not widely checked" - Modern security scanning tools automatically enumerate all record types, including SRV records, making this information readily available to attackers.