Building a Hybrid DNS-Routing Container: Combining FRR and CoreDNS for Telecom Infrastructure

Introduction

In the ever-evolving landscape of telecom infrastructure, the need for specialized, high-performance DNS solutions that can seamlessly integrate with routing protocols has become paramount. Recently, I had the opportunity to architect and implement a hybrid container solution that combines Free Range Routing (FRR) with CoreDNS to create a powerful, scalable DNS service for wireless APN (Access Point Name) management.

The Challenge

Our telecom infrastructure required replacing legacy Expeto DNS containers with a more modern, maintainable solution that could:

• Provide external-facing DNS services for telecom partners (Comfone, Sparkle, and future partners)
• Integrate seamlessly with BGP routing for optimal network path management
• Support dynamic configuration based on deployment environments
• Maintain high availability and performance standards required for telecom operations

Architecture Overview

The Foundation: FRR Base Image

The solution starts with a solid foundation using the FRR (Free Range Routing) base image:

ARG BASE_IMAGE=registry.internal..com/infra/cr-frr:frr-stable-jammy@sha256:5e23a0dc827124ea04dce819a2fb336e9c368c61164cbac0d176d5548bda99f0
FROM ${BASE_IMAGE} AS prod

FRR provides enterprise-grade routing capabilities, supporting protocols like BGP, OSPF, and IS-IS. By using it as our base, we get: - Proven stability in production telecom environments - BGP neighbor management for partner connectivity - Dynamic route advertisement capabilities - Comprehensive logging and monitoring

Layer 2: CoreDNS Integration

On top of the routing foundation, we integrate CoreDNS v1.11.3:

ARG VERSION="1.11.3"
ENV COREDNS_VERSION=${VERSION} RUN apt-get update && \
 curl -L https://github.com/coredns/coredns/releases/download/v$COREDNS_VERSION/coredns_${VERSION}_linux_amd64.tgz -o coredns.tgz && \
 tar xf coredns.tgz && \
 rm coredns.tgz && \
 mv coredns /usr/local/bin/

CoreDNS brings modern DNS capabilities: - Plugin-based architecture for extensibility - Built-in metrics and health checking - High performance with minimal resource footprint - Kubernetes-ready design patterns

Service Orchestration with S6

The magic happens in the service orchestration layer using S6 supervision:

CoreDNS Service Runner

#!/usr/bin/with-contenv sh
set -o nounset -o errexit -x # Wait for rsyslog to start so we won't lose messages
if [ -d /var/run/s6/services/rsyslog ] ; then
 echo "Waiting for rsyslog to start so we won't lose messages"
 s6-svc -wu /var/run/s6/services/rsyslog
 sleep 1
fi exec /usr/local/bin/coredns \
 -conf /etc/coredns/Corefile

This approach ensures: - Service Dependency Management: CoreDNS waits for logging services - Process Supervision: Automatic restart on failure - Clean Shutdown: Proper signal handling for graceful termination - Resource Management: Efficient resource utilization

Dynamic Configuration Management

BGP Configuration Template

The FRR configuration uses template-based dynamic configuration:

hostname {{ .SERVER_HOSTNAME }}
!
router bgp {{ .SITE_ASN }}
 neighbor {{ .SIGNALLING_ROUTER_IP }} remote-as {{ .SITE_ASN }}
 neighbor {{ .SIGNALLING_ROUTER_IP }} advertisement-interval 1
 neighbor {{ .SIGNALLING_ROUTER_IP }} timers 3 12
 !
 address-family ipv4 unicast
 network {{ .EXTERNAL_SIGNALLING_IP }}/32
 exit-address-family
!
ip route 10.0.0.0/8 {{ ._ROUTER_IP }}
ip route 172.16.0.0/12 {{ ._ROUTER_IP }}
ip route 192.168.0.0/16 {{ ._ROUTER_IP }}

Environment-Driven Configuration

The container accepts these environment variables: - SERVER_HOSTNAME - Dynamic hostname assignment - SITE_ASN - BGP Autonomous System Number - SIGNALLING_ROUTER_IP - Partner router IP for BGP peering - EXTERNAL_SIGNALLING_IP - Public IP for route advertisement - _ROUTER_IP - Internal routing bridge IP

Network Architecture Considerations

Port Strategy

EXPOSE 11915/tcp # Metrics endpoint
EXPOSE 53 53/udp # DNS service

The dual-port approach provides: - DNS Service (Port 53): Standard DNS resolution - Metrics Endpoint (Port 11915): Prometheus-compatible metrics for monitoring

BGP Integration Benefits

1. Dynamic Route Management: Automatic failover and load balancing
2. Partner Integration: Seamless connectivity with telecom partners
3. Traffic Engineering: Optimal path selection based on network conditions
4. Scalability: Easy addition of new partners and routes

Performance and Monitoring

Built-in Observability

The architecture includes comprehensive monitoring: - CoreDNS metrics for DNS query performance - FRR routing table monitoring - Service health checks through S6 supervision - Structured logging for troubleshooting

Resource Optimization

• Minimal Base Image: Ubuntu Jammy with only necessary components
• Single Binary Approach: CoreDNS as a single, efficient binary
• Process Supervision: Efficient resource management with S6

Deployment and CI/CD Integration

Jenkins Pipeline Integration

The solution integrates with Jenkins for automated building:

# Jenkinsfile optimizations for Docker image building
# Automated testing and deployment pipeline
# Environment-specific configuration management

Container Registry Strategy

• Automated image building and tagging
• Environment-specific image variants
• Secure image storage and distribution

Key Technical Achievements

Code Efficiency Metrics

• Added: 105+ lines of production-ready code
• Removed: 115 lines of obsolete code
• Net Result: Improved functionality with cleaner, more maintainable codebase

Architecture Benefits

1. Modularity: Clear separation between routing and DNS concerns
2. Scalability: Template-driven configuration for easy scaling
3. Maintainability: Standard containerization practices
4. Observability: Built-in metrics and logging
5. Reliability: Process supervision and automatic recovery

Lessons Learned

Container Design Patterns

1. Single Responsibility with Composition: Each service (FRR, CoreDNS) maintains its primary responsibility while working together
2. Environment-Driven Configuration: Template-based configuration allows for flexible deployment across environments
3. Health-First Design: Built-in health checking and metrics from day one
4. Process Supervision: S6 provides robust process management without the overhead of full orchestration

Network Service Architecture

1. Protocol Layering: Proper separation between L3 routing (BGP) and L7 services (DNS)
2. Partner Integration: Design for external connectivity from the beginning
3. Monitoring Integration: Metrics and logging as first-class citizens
4. Configuration Management: Dynamic configuration reduces operational overhead

Future Considerations

Scalability Enhancements

• Horizontal scaling with service mesh integration
• Advanced load balancing with BGP ECMP
• Geographic distribution for latency optimization

Feature Extensions

• Additional CoreDNS plugins for advanced DNS features
• Integration with service discovery systems
• Enhanced security with DNS-over-HTTPS/TLS

Conclusion

Building a hybrid DNS-routing container requires careful consideration of both network protocols and container orchestration patterns. By combining the routing expertise of FRR with the modern DNS capabilities of CoreDNS, we created a solution that not only meets current telecom infrastructure needs but provides a foundation for future growth and innovation.

The key to success in such architectures lies in: - Understanding the unique requirements of each component - Designing for observability from the ground up
- Implementing robust configuration management - Planning for operational excellence

This architecture demonstrates how modern containerization techniques can be applied to traditional telecom infrastructure challenges, resulting in more maintainable, scalable, and reliable systems.

This solution showcases the intersection of container technology, network engineering, and telecom infrastructure - a powerful combination for building next-generation network services.