For offices under 50 users, maintaining internal DNS servers presents an interesting optimization challenge. While enterprise environments almost always require internal DNS infrastructure, smaller shops have more architectural flexibility. The fundamental question is whether the benefits of split-horizon DNS outweigh its operational overhead in your specific context.

# Example BIND zone file showing split DNS configuration
$TTL 3600
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2023082001 ; serial
                        3600       ; refresh
                        900        ; retry
                        604800     ; expire
                        86400 )    ; minimum

; Internal records
internal-app IN  A   192.168.1.100
www         IN  A   192.168.1.101

; External records would be in separate public zone file

The primary benefit remains seamless hostname resolution regardless of network location. Consider these technical scenarios:

• Hybrid applications requiring different endpoints for internal/external access
• Development environments needing non-public test domains (dev.example.com)
• Services requiring internal-only discovery (printers, local file servers)

For offices where:

# Example of using public DNS with private IPs (not recommended)
api.internal.example.com.  IN  A  10.0.1.15
db.internal.example.com.   IN  A  10.0.1.16

This approach becomes viable when:

• All services are either fully internal or fully external
• VPN configurations can reliably handle all internal resolution
• You're using cloud-native naming services (Azure Private DNS, Route53)

Internal DNS maintenance includes:

• Server patching cycles
• High availability configuration
• Zone synchronization challenges

Public DNS limitations include:

• No private IP visibility outside VPN
• Potential security exposure of internal topology
• No support for dynamic DNS updates from local clients

Consider these emerging patterns:

# Example using DNS forwarding for hybrid resolution
options {
    forwarders {
        8.8.8.8;
        8.8.4.4;
    };
    forward only;
    allow-query { internal-nets; };
};

zone "internal.example.com" {
    type master;
    file "/etc/bind/zones/internal.example.com.db";
};

Answer these questions:

1. Do you have services requiring different internal/external resolution?
2. What percentage of DNS queries are for internal-only resources?
3. Can your VPN reliably handle all internal name resolution?
4. Are you using any applications that depend on dynamic DNS updates?

For most small offices with hybrid infrastructure, maintaining lightweight internal DNS resolvers (like dnsmasq or Windows DNS) delivers the best balance. But pure cloud environments might justify public-only approaches.

---

As network administrators in small office environments (typically under 50 users), we constantly weigh infrastructure complexity against operational simplicity. The DNS server debate encapsulates this perfectly. Let me walk through some real-world technical considerations from my experience managing these setups.

# Example split DNS configuration (BIND)
zone "company.com" {
    type master;
    file "/etc/bind/zones/company.com.internal";
};

zone "company.com" {
    type forward;
    forwarders { 8.8.8.8; };
    forward only;
};

This traditional approach allows internal resources (like printers or file servers) to resolve differently than public services. However, the VPN complications are real:

• VPN clients often get confused about which DNS server to query
• Split-tunnel VPN configurations require careful DNS routing
• Mobile users experience resolution delays when switching networks

Moving everything to public DNS records seems tempting:

# Example public DNS records (hypothetical)
internal-fileserver.company.com. 300 IN A 192.168.1.100
printer1.company.com. 300 IN A 192.168.1.101

But this approach brings security implications:

• Exposes internal network topology publicly
• Requires ACLs to prevent external access attempts
• Makes IP changes publicly visible

For modern small offices, I've found success with these approaches:

# Cloud-based hybrid solution (e.g., using AWS Route53)
resource "aws_route53_record" "internal_app" {
  zone_id = aws_route53_zone.private.zone_id
  name    = "app.company.com"
  type    = "A"
  ttl     = "300"
  records = ["10.0.1.5"]
}

Key benefits:

• Maintains separation of internal/external resources
• Centralizes management through cloud providers
• Scales better than traditional on-prem DNS

The IPv6 support gap in your current setup suggests it's time for modernization:

# Sample IPv6 DNS configuration
internal-app.company.com. IN AAAA fd12:3456:789a::1

Cloud DNS services typically include IPv6 support by default, eliminating this maintenance burden.

If moving away from internal DNS, consider this phased approach:

1. Audit all internal DNS records and categorize them
2. Implement DNS filtering to block external queries for private records
3. Gradually migrate non-sensitive records to public DNS
4. Monitor resolution performance during transition

For most small offices today, I recommend:

• Keep critical internal DNS for sensitive resources
• Use cloud DNS services for public records
• Implement proper DNS security (DNSSEC, filtering)
• Plan for IPv6 compatibility in next upgrade cycle