Files
moby/libnetwork
Rob Murray 74d77d8811 Revert "Internal resolver for default bridge network"
This reverts commit 18f4f775ed.

Because buildkit doesn't run an internal resolver, and it bases its
/etc/resolv.conf on the host's ... when buildkit is run in a container
that has 'nameserver 127.0.0.11', its build containers will use Google's
DNS servers as a fallback (unless the build container uses host
networking).

Before, when the 127.0.0.11 resolver was not used for the default network,
the buildkit container would have inherited a site-local nameserver. So,
the build containers it created would also have inherited that DNS
server - and they'd be able to resolve site-local hostnames.

By replacing the site-local nameserver with Google's, we broke access
to local DNS and its hostnames.

Signed-off-by: Rob Murray <rob.murray@docker.com>
2024-06-17 20:19:20 +01:00
..
2024-03-07 10:57:03 +01:00
2024-06-13 14:59:54 +02:00
2024-06-14 15:25:07 +02:00
2021-06-01 23:48:32 +00:00
2024-06-11 22:33:58 +01:00
2023-05-29 03:28:35 +02:00
2024-06-14 15:25:07 +02:00
2024-06-14 15:25:07 +02:00
2024-02-29 23:27:00 +00:00
2024-06-13 14:59:54 +02:00

libnetwork - networking for containers

Libnetwork provides a native Go implementation for connecting containers

The goal of libnetwork is to deliver a robust Container Network Model that provides a consistent programming interface and the required network abstractions for applications.

Design

Please refer to the design for more information.

Using libnetwork

There are many networking solutions available to suit a broad range of use-cases. libnetwork uses a driver / plugin model to support all of these solutions while abstracting the complexity of the driver implementations by exposing a simple and consistent Network Model to users.

Contributing

Want to hack on libnetwork? Docker's contributions guidelines apply.

Code and documentation copyright 2015 Docker, inc. Code released under the Apache 2.0 license. Docs released under Creative commons.