Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

An error occurred while submitting your form. Please try again or file a bug report. Close

  1. Blog
  2. Article

Nicholas Morris
on 26 August 2025

Generating allow-lists with DNS monitoring on LXD


Allow-listing web traffic – blocking all web traffic that has not been pre-approved – is a common practice in highly sensitive environments. It is also a challenge for developers and system administrators working in those environments. In this blog, we’ll cover an easy way to mitigate this challenge by using LXD to generate allow-lists. 

The problem

Many applications, tools, and websites pull packages, configurations, and other data from domains that the end user never sees, unless they happen to monitor the associated network traffic. Trying to perform a new operation in an allow-listed environment usually follows an unfortunate pattern:

  1. User runs process in constrained environment
    System administrator or developer attempts to run a software installation, ETL pipeline, or other process inside an environment that implements network allow-listing.
  2. Process reaches a step with non-allow-listed network dependencies and fails
    Even if the user has added known dependencies to the allow-list, such processes will fail when they attempt to connect to additional, previously unknown dependencies.
  3. User adds dependencies to allow-list
    The administrator or developer adds newly-discovered dependencies to the allow-list
  4. Repeat
    This pattern often requires several iterations because processes do not connect to all of their network dependencies simultaneously. Frequently, they exit on the first failure. Fixing that failure allows the process to reach its next step with a network dependency, leading to another failure – and so on.

The solution

The best method to avoid this ‘vicious cycle’ of allow-listing is to pre-identify all required resources by executing your process in an unconstrained environment while monitoring network traffic. After the process has been executed start-to-finish, an allow-list can be generated from network logs with confidence that the result includes all required resources. 

In the context of domain-based allow-listing, DNS logs are the most direct method of monitoring – and, fortunately, Canonical’s LXD makes it easy to create a test environment with DNS logging.

When setting up LXD with default configurations (lxd init --minimal), LXD will create a managed bridge network. This network type supports DHCP and DNS with no extra configuration. LXD does this by running an instance of dnsmasq in the background.

Even better, LXD allows us to customize the configuration of the dnsmasq server via the raw.dnsmasq configuration option. The relevant configuration options for our use case are:

  • log-queries – log DNS queries
  • log-facility=<filepath> – write logs to the specified filepath
  • quiet-dhcp – suppress standard DHCP logging
  • quiet-dhcp6 – suppress standard DHCP6 logging

How-to

  1. Install and initialise LXD by following the official tutorial 
  2. Verify that a managed network has been created
lxc network ls --format json | jq -r '.[] | select(.managed) | .name'

The returned names are managed networks. If the command does not return any output, create a new managed network with lxc network create YOUR_NETWORK_NAME

  1. Configure the managed network
lxc network set YOUR_NETWORK_NAME raw.dnsmasq "$(echo -e 'log-queries\nlog-facility=/tmp/dns.log\nquiet-dhcp\nquiet-dhcp6')"
  1. Verify your managed network looks correct with lxc show network YOUR_NETWORK_NAME
  1. Create a virtual machine or container using this network
lxc launch ubuntu:24.04 dnstest -n YOUR_NETWORK_NAME
  1. Execute DNS queries within the resource
lxc exec dnstest -- su ubuntu
nslookup google.com
nslookup canonical.com
  1. Exit the virtual machine or container and search the dns.log file for DNS A and AAAA query logs:
sudo grep -oP 'query\[A+\]\s\K\S+' /tmp/snap-private-tmp/snap.lxd/tmp/dns.log | sort -u

Conclusion

By following this process, one can generate a complete list of domains used by any process executed within an LXD virtual machine or container. That list of domains can be formatted as an allow-list configuration file, avoiding the iterative cycle all too common with manual approaches.

Learn more about LXD

Related posts


Jehudi
22 August 2025

A complete security view for every Ubuntu LTS VM on Azure

Compliance Article

Azure’s Update Manager now shows missing Ubuntu Pro updates for all Ubuntu Long-Term Support (LTS) releases: 18.04, 20.04, 22.04 and 24.04. The feature was first introduced for only 18.04 during its move to Expanded Security Maintenance. With this addition, Azure highlights where Ubuntu LTS instances would benefit from Expanded Security M ...


Stephanie Domas
11 August 2025

A CISO’s guide to Application Security best practices 

Hardening Article

Effective AppSec is not a one-time fix but a continuous journey across every facet of your application’s lifecycle. By embracing a Secure Software Development Lifecycle (SSDLC) from the outset, diligently uncovering potential risks, and mastering your cybersecurity fundamentals, you lay a robust foundation for resilient applications. ...


ROS Noetic is EOL – take action to maintain fleet security

Robotics Article

As of May 2025, the Robot Operating System (ROS) Noetic Ninjemys officially reached its end of life (EOL). First released in 2020 as the final ROS (1) distribution, ROS Noetic has been the default choice for thousands of developers building on Ubuntu 20.04 LTS. For developers and businesses running mission-critical systems on ROS Noetic, ...