Releases · containers/netavark

Fixed an issue where invalid dns names that included a space would cause aardvark-dns to crash. Instead such names are now ignored and generate a warning. (#1019)
Netavark teardown now ignores SIGTERM and SIGINT signals to prevent interfaces/firewall rules from leaking during teardown. (#1223)
Netavark no longer set the dns.podman search domain in the response. Aardvark-dns sill uses that name and resolves it but it will no longer be added to the containers resolv.conf because of that. (#1133)
The MSRV has been bumped to v1.77.
Dependency updates.

Fixed an issue where the Makefile did not install the netavark-firewalld(7) man page. (#1179)
Fixed the detection of Firewalld's StrictForwardPorts property.
Upstream tests no longer check for the commit sha in the version output by default so downstream tests on packaged versions without the commit info can pass.

bridge: Add support for a new option called mode. When set to unmanaged only the veth pair and ip addresses are setup. The bridge must exist and no firewall or sysctl setting will be configured in this mode. (#1090)
bridge: Add support for DHCP when using unmanaged mode. (#868)
bridge: Add support for the vlan option. (#1028)
When using DHCP netavark will now send the container hostname in the DHCP request and use the container id as client id. (#676)
The firewalld driver was improved and major outstanding bugs were addressed but is still considered experimental. A new man page netavark-firewalld(7) has been added to document some of the firewalld interactions.
Dependency updates.

Fixed a bug where port forwarding rules might not be removed correctly on nftables when different host ips are used for the same port. (#1129)
On aardvark-dns setup errors properly cleanup interfaces and firewall rules again. (#1121)

Fixed bug where port forwarding rules might not be removed correctly on nftables
Add DNS DNAT rules first with nftables

Fixed problem with categories in Cargo.toml that prevented us from publishing v1.12.0

Fixed a bug where the netavark update command could sometimes incorrectly start a new Aardvark DNS server instead of restarting the existing server

Provide feedback