DOCSEARCHbyAlgolia
Submit Docs

DNS Proxy Server (DPS)

repository·master·Indexed 21 days ago

https://github.com/mageddo/dns-proxy-server

A DNS Proxy Server (DPS) designed to resolve container names across different Docker networks and environments. It includes a React-based frontend, support for DNS over HTTPS (DoH) with certificate generation guides, and capabilities for wildcard DNS resolution and custom IP registration. The project provides multiple Docker build targets for Linux amd64 and aarch64 architectures.

Tokens
24.4K
Snippets
94
Records
142
Agent score
74%

What's inside dns-proxy-server

  1. Overview of DNS Proxy Server (DPS) features

    master

    DNS Proxy Server (DPS) is a lightweight DNS server tool designed for developers and server administrators. It facilitates environments where a single hostname needs to resolve to different IPs based on the configured environment.

    Key Capabilities:

    • Docker Integration: Resolve hostnames directly to Docker containers.
    • Local Configuration: Solve hostnames using a local configuration database.
    • Recursive Solving: Use a list of configured remote DNS servers for recursive lookups.
    • Pattern Matching: Support for wildcard and regex-based hostname solving.
    • Management UI: A graphic interface to Create, List, Update, and Delete A/AAAA/CNAME records.
    • Host Discovery: Resolve the host machine's IP using the host.docker hostname.

    Compliance and Modes:

    • RFC-1035 Compliant
    • Supports Authoritative, Recursive, and Secondary modes
    • Supports Caching, IPv6, Wildcards, and DNS over HTTPS (DoH)

  2. Overview of Hugo Learn Theme features

    master

    The Hugo Learn Theme is a theme for the Hugo static site generator, inspired by the Grav Learn Theme. Key features include:

    • Search & Navigation: Automatic search, unlimited menu levels, and automatic next/prev buttons for menu entry navigation.
    • Content Display: Multilingual mode, Mermaid diagram support (flowchart, sequence, gantt), list child pages, and attachment files.
    • UI Components: Customizable look and feel/theme variants, buttons, Tip/Note/Info/Warning boxes, and Expandable sections.
    • Media: Image resizing and shadows.

  4. When to use DNS Proxy Server (DPS) with Docker Compose

    master

    DNS Proxy Server (DPS) is primarily used to resolve container names across different networks or environments.

    Important Limitations:

    • If you are using docker-compose v2 or v3, DPS is not necessary to resolve container names that are defined within the same compose file.
    • When using DPS for containers within a compose file, you will not be able to resolve those containers from the host machine.

  5. How Remote Solver Circuit Breaker works

    master

    DNS Proxy Server (DPS) uses circuit breaker strategies to select the most available Remote Server from a configured list. This prevents the system from repeatedly attempting to use remote servers that are offline or failing, thereby improving overall availability and resilience.

    There are two primary strategies available:

    1. CANARY_RATE_THRESHOLD: Uses failure percentages to manage circuit states. It treats all remote servers as open on application startup, testing them immediately to identify healthy ones (transitioning them to HALF_OPEN) to avoid resolution failures caused by an offline first server in the list.
    2. STATIC_THRESHOLD: Uses fixed counts of successes or failures. It treats all remote servers as closed on application startup.

  6. How to Docker Container Solving works

    master
    The DNS Proxy Server includes a feature for Docker Container Solving. This allows the server to resolve the IP addresses of Docker containers, enabling communication between the host and containers or between containers themselves via DNS names. Detailed documentation on this feature can be found in the Docker Solving section of the project documentation.

  7. DNS resolution order in DPS

    master

    When resolving a hostname, the DNS Proxy Server (DPS) follows a specific hierarchical order to find the correct address:

    1. Docker containers: It first attempts to resolve the hostname from existing Docker containers.
    2. Local database file: If not found in Docker, it checks the configured local database file.
    3. Remote DNS servers: If the hostname is still not resolved, it queries the three configured remote DNS servers.

  8. Use the Stub Solver to transform IPs into hostnames

    master

    The Stub Solver allows you to resolve hostnames to IP addresses dynamically without maintaining a configuration file (unlike the Local DB Solver). It uses a specific naming convention inspired by nip.io and sslip.io to map a hostname back to its underlying IP address.

    Usage Patterns

    Without a name: If you only provide the IP representation followed by the .stub suffix, it resolves directly to that IP.

    • 10.0.0.1.stub $\rightarrow$ 10.0.0.1
    • 192-168-1-250.stub $\rightarrow$ 192.168.1.250
    • 0a000803.stub $\rightarrow$ 10.0.8.3

    With a name: You can prefix the IP with a name (separated by a dot or dash) to create human-readable hostnames.

    • app.10.8.0.1.stub $\rightarrow$ 10.8.0.1
    • app-116-203-255-68.stub $\rightarrow$ 116.203.255.68
    • customer1.app.10.0.0.1.stub $\rightarrow$ 10.0.0.1
    • app.2a01-4f8-c17-b8f--2.stub $\rightarrow$ 2a01:4f8:c17:b8f::2 (IPv6)
    app.10.8.0.1.stub

  9. Understanding DNS resolution across different Docker networks

    master

    DNS Proxy Server (DPS) can resolve hostnames for Docker containers residing on different networks. It selects the target container's IP based on which IP has the highest probability of being accessible from the client. This selection logic applies regardless of whether the client is a container or the host machine.

    Connectivity Scenarios

    DPS NetworkClientClient NetworkTarget NetworkResultDescription
    Any bridgeContainerAny bridgeAny bridgeOKWorks fine with bridge drivers, even if networks differ.
    Network xContainerNetwork xNetwork xOKWorks even with restrictive drivers (like overlay) if all are on the same network.
    Network a, bContainerNetwork aNetwork bPARTIALLY OKResolution works, but the client cannot ping the target. Requirement: Client must be on the same network as DPS to query it, AND on the same network as the target to reach it.
    Network aContainerNetwork bNetwork bNOKClient cannot communicate with DPS.
    Any bridgeHostAnyAny bridgeOKHost can ping DPS and the resolved target IP.
    Any bridgeHostAnyNot BridgePARTIALLY OKHost can ping DPS but cannot ping the resolved target IP.
    Network aHostAnyAnyFAILHost cannot ping DPS. DNS resolution fails on the host. (Note: On Linux, you can bypass this by publishing the DPS container port to the host).

  10. Understand DPS versioning and stability

    master

    DNS Proxy Server (DPS) follows semantic versioning.

    • Stable Versions: The latest stable version is identified by the latest label on GitHub releases or the latest Docker tag.
    • Pre-releases: Minor pre-releases are promoted to the stable version after being released for at least one month without confirmed bugs reported on the official GitHub repository.
    • Bleeding Edge: If you require the most recent updates and do not require stability, use the latest pre-release or the Docker nightly tag.

  11. Understand the testing hierarchy

    master

    The project uses three levels of automated testing:

    1. Unit Tests: Verify individual components, functions, or methods.
    2. Comp Tests (Component Tests): Verify entire flows while allowing some parts to be mocked (e.g., mocking an endpoint that modifies a config file).
    3. Int Tests (Integration Tests): Verify the system without mocks (using flags instead of stubs/mocks). These are specifically designed to validate native-image compilation and are run using IntTest.java suffixes.

  12. Use Multiple Environments to group hostnames

    master

    Starting from DPS 2.18, you can group hostnames into different environments. This allows you to resolve the same hostname to different IP addresses depending on your current context (e.g., switching between a local development environment and a qa testing environment).

    To use this feature:

    1. Create an environment (e.g., local or qa).
    2. Within each environment, create the necessary DNS records (e.g., an A record) for your hostnames pointing to the environment-specific IP.
    3. Swap between environments to change how hostnames are resolved without manually updating individual records.