Docker Networking Fundamentals - Part 2: Custom Networks, DNS Resolution, and Network Management

Master advanced Docker networking with custom bridge networks, automatic DNS resolution, network isolation, port mapping, and comprehensive network management. Learn to build scalable container architectures.

September 12, 2025

12 min read

#docker #custom-networks #dns-resolution #network-isolation #port-mapping #network-management

Building on Part 1's foundation, we'll now explore advanced Docker networking concepts including custom networks, automatic DNS resolution, network isolation, and comprehensive network management strategies for production environments.

💡

🎯 What You'll Learn: In this advanced networking tutorial, you'll discover:

Creating and configuring custom Docker networks
Automatic DNS resolution and service discovery
Network isolation and security patterns
Port mapping for external connectivity
Managing multiple networks and container connections
Network cleanup and maintenance strategies
Best practices for production container networking

Time to read: ~15 minutes | Difficulty: Intermediate to Advanced

🚀 Advanced Docker Networking Architecture

Custom Docker networks provide enhanced features over the default bridge network, including automatic DNS resolution, better isolation, and more granular control over container communication patterns.

Prerequisites

Before we begin, make sure you have:

Completed Part 1: Bridge Networks and Container Communication
Understanding of basic Docker networking concepts
Familiarity with DNS and IP networking concepts
Docker installed and running with no existing test containers

🏗️ Step 1: Creating Custom Docker Networks

Custom networks provide several advantages over the default bridge network, including automatic DNS resolution and enhanced isolation.

Creating a Basic Custom Network

docker network create app-network

Docker creates the custom network and returns its ID:

c45c3893d969b07c2c76898ee5f8fec9cb01f09e21fafd0ae74b1246db7a987a

Verifying Network Creation

docker network ls

The output now shows our new custom network alongside the defaults:

NETWORK ID     NAME          DRIVER    SCOPE
c45c3893d969   app-network   bridge    local
10acedb416a3   bridge        bridge    local
4014e1a64d4c   host          host      local
b84fc03ca6b5   none          null      local

Network Comparison:

Network	Type	Features	Best Use Case
bridge (default)	Default	IP-based communication only	Simple setups, backward compatibility
app-network (custom)	Custom Bridge	DNS resolution, better isolation	Multi-container applications
host	Host	Direct host network access	High-performance networking
none	Null	No networking	Completely isolated containers

Inspecting Custom Network Configuration

docker network inspect app-network

The inspection reveals the network's automatic configuration:

[
    {
        "Name": "app-network",
        "Id": "c45c3893d969b07c2c76898ee5f8fec9cb01f09e21fafd0ae74b1246db7a987a",
        "Created": "2025-09-12T13:42:56.467893559+05:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

Key Differences from Default Bridge:

Property	Default Bridge	Custom Network	Advantage
Subnet	172.17.0.0/16	172.18.0.0/16	Automatic subnet allocation prevents conflicts
DNS Resolution	No	Yes	Container name-based communication
Isolation	Limited	Enhanced	Better security and network segmentation
Configuration	Fixed	Customizable	Flexible subnet and gateway options

🔧 Step 2: Creating Networks with Custom Subnets

For production environments, you may want to specify custom IP ranges and network configurations.

Creating Network with Custom Subnet

docker network create --driver bridge --subnet=192.168.100.0/24 custom-subnet-network

This creates a network with a specific IP range:

f7bae93be935b5499189b5ede9c263b1a3b2dd850cb738a72125882c361fa382

Verifying Custom Subnet Network

docker network ls

Output shows the new network:

NETWORK ID     NAME                    DRIVER    SCOPE
c45c3893d969   app-network             bridge    local
10acedb416a3   bridge                  bridge    local
f7bae93be935   custom-subnet-network   bridge    local
4014e1a64d4c   host                    host      local
b84fc03ca6b5   none                    null      local

Inspecting Custom Subnet Configuration

docker network inspect custom-subnet-network

The network configuration shows our custom subnet:

[
    {
        "Name": "custom-subnet-network",
        "Id": "f7bae93be935b5499189b5ede9c263b1a3b2dd850cb738a72125882c361fa382",
        "Created": "2025-09-12T13:44:10.084966472+05:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "192.168.100.0/24"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

💡

💡 Custom Subnet Benefits: The 192.168.100.0/24 subnet provides 254 usable IP addresses (192.168.100.1-254), perfect for departmental or project-specific container isolation.

🐳 Step 3: Deploying Containers to Custom Networks

Let's deploy containers to our custom network and observe the enhanced features.

Creating Containers on Custom Network

docker run -d --name app-server-1 --network app-network nginx:alpine
docker run -d --name app-server-2 --network app-network nginx:alpine  
docker run -d --name app-client --network app-network alpine:latest sleep 3600

Output confirms successful deployment:

# app-server-1
a4ae5c5613f626f853f041cd9e11a6cf9803f3195e53c468139d0229a8c7e3c1

# app-server-2  
0adc8145ff47297c8034c30de84b885a224bf82a5e0f053f88b547ce384d3e3b

# app-client
88314d61148a39702a97bafa715b5b8f5e83e8b1270116239529dfce542384d8

Testing DNS-Based Communication

Now comes the magic of custom networks - automatic DNS resolution using container names:

docker exec app-client ping -c 3 app-server-1

Successful DNS resolution and connectivity:

PING app-server-1 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.198 ms
64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.096 ms
64 bytes from 172.18.0.2: seq=2 ttl=64 time=0.081 ms

--- app-server-1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.081/0.125/0.198 ms

Testing HTTP Communication with DNS

docker exec app-client wget -qO- http://app-server-1

Successful HTTP communication using the container name:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

✅

✅ DNS Magic: Custom networks provide automatic DNS resolution, allowing containers to communicate using names instead of IP addresses. This is crucial for dynamic, scalable applications.

🔒 Step 4: Demonstrating Network Isolation

One of the key benefits of custom networks is isolation between different network segments.

Testing Cross-Network Communication (Should Fail)

Let's test if containers on the custom network can reach containers on the default bridge network:

docker exec app-client ping -c 3 web-server-1

This fails as expected, demonstrating network isolation:

ping: bad address 'web-server-1'

Network Isolation Characteristics:

Source Network	Target Network	Result	Reason
app-network	app-network	✅ Success	Same network, DNS resolution works
app-network	bridge (default)	❌ Fails	Different networks, no cross-network communication
bridge	app-network	❌ Fails	Networks are isolated by default
Same network	Same network	✅ Success	Full communication within network boundaries

Connecting Container to Multiple Networks

Docker allows containers to connect to multiple networks for hybrid communication patterns:

docker network connect app-network alpine-client

This command connects the existing alpine-client (from the default bridge) to our custom network. The command returns no output on success.

Verifying Multi-Network Connectivity

docker network inspect app-network

The network now shows alpine-client connected:

"Containers": {
    "0adc8145ff47297c8034c30de84b885a224bf82a5e0f053f88b547ce384d3e3b": {
        "Name": "app-server-2",
        "EndpointID": "205ddd0f9d2589f75bd8f4fb3ba7b00b5a4c8103bee69bd15c7e00a7e04f3c84",
        "MacAddress": "0a:47:20:c1:00:df",
        "IPv4Address": "172.18.0.3/16",
        "IPv6Address": ""
    },
    "2b7034890c35344265b6cdfe8dde4237f45ecd59883267ecfa8d39c097ea89fc": {
        "Name": "alpine-client",
        "EndpointID": "3566e3fc83c0c19d102c52b9e3f5a1f0d2c23e117a02c7d72fff0110351c0e42",
        "MacAddress": "ba:10:b4:ca:62:4f",
        "IPv4Address": "172.18.0.5/16",
        "IPv6Address": ""
    },
    "88314d61148a39702a97bafa715b5b8f5e83e8b1270116239529dfce542384d8": {
        "Name": "app-client",
        "EndpointID": "dbc9b7d2dcc27d114cc735b810010e990723efe7ad14bcc4b4f1b74c133883f2",
        "MacAddress": "ae:79:ed:b3:19:7c",
        "IPv4Address": "172.18.0.4/16",
        "IPv6Address": ""
    },
    "a4ae5c5613f626f853f041cd9e11a6cf9803f3195e53c468139d0229a8c7e3c1": {
        "Name": "app-server-1",
        "EndpointID": "4daedfa5b7b07d8996c8f00cfa3e9e6b2c73004172c9ce9a1fa01e6727478b36",
        "MacAddress": "9a:3d:a7:d9:f3:6e",
        "IPv4Address": "172.18.0.2/16",
        "IPv6Address": ""
    }
}

Testing Cross-Network Communication After Connection

docker exec alpine-client ping -c 3 app-server-1

Now the communication works:

PING app-server-1 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.504 ms
64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.099 ms
64 bytes from 172.18.0.2: seq=2 ttl=64 time=0.149 ms

--- app-server-1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.099/0.250/0.504 ms

💡

💡 Multi-Network Strategy: Connecting containers to multiple networks enables hybrid architectures where containers can communicate across network boundaries when needed, while maintaining overall network isolation.

🌐 Step 5: Port Mapping and External Connectivity

To make containerized services accessible from outside the Docker host, we use port mapping.

Creating Container with Port Mapping

docker run -d --name web-public --network app-network -p 8080:80 nginx:alpine

This creates a container with port 8080 on the host mapped to port 80 in the container:

c2e44a84a49ffc8a6a9c335ac0222f4d0c859e432784fe06a9a3c40f32576755

Testing External Connectivity

curl http://localhost:8080

The curl command successfully retrieves the web page from the host:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Testing Internal Network Access to Mapped Service

docker exec app-client wget -qO- http://web-public

The service is also accessible internally by container name:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Port Mapping Communication Patterns:

Access Type	Method	URL/Command	Use Case
External (Host)	Port mapping	http://localhost:8080	Public web services, API access
Internal (Container Name)	DNS resolution	http://web-public	Service-to-service communication
Internal (IP)	Direct IP	http://172.18.0.x	Legacy applications, debugging
Cross-network	Multi-network connection	Various methods	Hybrid architectures

🧹 Step 6: Network Management and Cleanup

Proper network management is essential for maintaining clean, efficient container environments.

Disconnecting Containers from Networks

docker network disconnect app-network alpine-client

This removes the container from the specified network. The command returns no output on success.

Bulk Container Management

For comprehensive cleanup, Docker provides efficient bulk operations:

docker stop web-server-1 web-server-2 alpine-client app-server-1 app-server-2 app-client web-public

Output confirms each container is stopped:

web-server-1
web-server-2
alpine-client
app-server-1
app-server-2
app-client
web-public

Remove All Test Containers

docker rm web-server-1 web-server-2 alpine-client app-server-1 app-server-2 app-client web-public

Container removal confirmation:

web-server-1
web-server-2
alpine-client
app-server-1
app-server-2
app-client
web-public

Network Cleanup

docker network rm app-network custom-subnet-network

Network removal confirmation:

app-network
custom-subnet-network

Verifying Clean Environment

docker network ls
docker ps -a

Final verification shows a clean environment:

# Network list - only defaults remain
NETWORK ID     NAME      DRIVER    SCOPE
10acedb416a3   bridge    bridge    local
4014e1a64d4c   host      host      local
b84fc03ca6b5   none      null      local

# No containers remain
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

✅

✅ Clean Environment: All test containers and custom networks have been successfully removed, returning the system to its original state.

🎯 Production Network Management Best Practices

Network Naming Conventions

Pattern	Example	Use Case	Benefits
Application-based	wordpress-network	Single application stacks	Clear ownership and purpose
Environment-based	prod-frontend-net	Environment isolation	Deployment safety
Tier-based	database-tier-net	Multi-tier architectures	Security and performance optimization
Project-based	project-alpha-net	Development projects	Resource organization

Security Considerations

Network Segmentation: Use separate networks for different application tiers
Principle of Least Privilege: Only connect containers to networks they need
Internal Services: Keep internal services on private networks without port mapping
Monitoring: Regularly audit network configurations and connections

Performance Optimization

Subnet Planning: Choose appropriate subnet sizes for your use case
Network Driver Selection: Use appropriate drivers for different scenarios
Resource Limits: Consider network bandwidth and connection limits
Cleanup Automation: Implement regular cleanup procedures for unused networks

🎯 Key Takeaways

✅ Advanced Networking Mastery

Custom Networks: Provide DNS resolution, better isolation, and enhanced control
Service Discovery: Container names automatically resolve to IP addresses in custom networks
Network Isolation: Different networks are isolated by default, enhancing security
Multi-Network Connectivity: Containers can belong to multiple networks for hybrid architectures
Port Mapping: Enables external access while maintaining internal DNS-based communication
Network Management: Proper cleanup and naming conventions are essential for production

📖 Advanced Topics for Further Learning

Docker Compose Networking: Multi-container application networking
Overlay Networks: Multi-host container communication in Docker Swarm
Network Policies: Advanced security and traffic control
Custom Network Drivers: Building specialized networking solutions
Container Service Mesh: Advanced service-to-service communication patterns

✅

🎉 Networking Mastery Complete! You now understand advanced Docker networking concepts including custom networks, DNS resolution, network isolation, port mapping, and comprehensive network management strategies.

💬 Discussion

I'd love to hear about your advanced Docker networking projects:

What network architectures have you implemented in production?
How do you handle service discovery in complex applications?
What network security patterns do you find most effective?
Have you worked with multi-host networking scenarios?

Connect with me:

🐙 GitHub - Advanced Docker networking examples and configurations
📧 Contact - Complex networking architecture discussions

Written by Owais

Passionate developer sharing insights on technology, development, and the art of building great software.

About Me Projects