IRRd on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of IRRd on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. IRRd is the open source Internet Routing Registry daemon — the reference server behind the Internet Routing Registry (IRR), the distributed system network operators use to publish and look up routing policy: which prefixes an autonomous system originates, which networks a maintainer controls, and the maintainer objects that authorise changes. It is the same software NTT runs for its own IRR and for the public RADb mirror service.

IRRd answers the classic whois protocol on port 43 that every IRR client, prefix-filter generator (bgpq4 and similar) and route-server config tool already speaks, and adds a modern HTTP JSON submission API and a GraphQL query API on top, so routing data can be pulled into automation as structured JSON rather than parsed whois text. An instance can run as an authoritative registry for your own autonomous system's objects, as a mirror of one or more upstream IRR sources, or both at once.

The image ships IRRd 4.5.3 (BSD-2-Clause), installed via the official pip package into a dedicated Python virtual environment, exactly per upstream's own deployment instructions. It runs alongside PostgreSQL (the RPSL object store, with the pgcrypto extension IRRd requires) and Redis (IRRd's internal event stream / cache), all three services co-installed on one VM.

Not a full internet-scale mirror. Upstream's own sizing guidance (32 GB RAM / 4 CPU / 150 GB disk) targets mirroring the entire global IRR corpus with continuous NRTM feeds from dozens of upstream registries — that is a deliberate customer choice (see Step 9), not something a base appliance pre-loads. This image ships a small, self-contained authoritative registry (source CLOUDIMG-TEST) that fits comfortably on Standard_B2s (2 vCPU, 4 GB RAM).

Functional out of the box. On first boot, this image loads one demo RPSL object set into the authoritative source: a person, a mntner, an aut-num (AS65000, a 16-bit private ASN reserved for documentation) and a route (192.0.2.0/24, RFC 5737 TEST-NET-1, reserved and never routable). You can query this real object immediately over whois, HTTP and GraphQL, and it doubles as a working template for loading your own routing objects.

Secure by default. No web login exists — this is a headless daemon. Three independent secrets are generated fresh on every VM's first boot and never shipped in the image: the PostgreSQL role password, the Redis password, and IRRd's override password (the administrator credential needed to create the very first mntner object in a fresh authoritative source — without it, nothing can be written). All three are written once to a root-only file.

Public query surface, by design. The whois (:43) and HTTP/GraphQL (:8000) listeners bind every interface, because being publicly queryable is the entire point of a routing registry — exactly how RADb and every real-world IRR mirror operates. Step 10 covers restricting this if you want a private-only instance.

What is included:

• IRRd 4.5.3 installed via pip into /opt/irrd/venv, run under systemd as irrd.service (non-root, CAP_NET_BIND_SERVICE only)

• PostgreSQL with the pgcrypto extension, and Redis, both co-installed

• A local Postfix instance (loopback-only) so IRRd's own change-notification emails have somewhere to go

• One demo RPSL object set (person, mntner, aut-num, route) loaded into the authoritative CLOUDIMG-TEST source on first boot

• Whois on port 43, HTTP status/submission API and GraphQL API on port 8000

• Per-VM PostgreSQL, Redis and IRRd override passwords, written once to /root/irrd-credentials.txt (0600 root:root)

Prerequisites

• Active Azure subscription, SSH public key, VNet + subnet in target region

• Subscription to the IRRd listing on Azure Marketplace

• Network Security Group rules allowing TCP 22 (admin), TCP 43 (whois queries) and TCP 8000 (HTTP + GraphQL queries and submissions) from whichever networks should be able to query this registry — see Step 10 if you want a private-only instance

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) comfortably runs IRRd, PostgreSQL and Redis together for a small authoritative registry or a handful of mirrored sources. If you plan to mirror many large upstream sources, size up per upstream's own guidance.

Step 1: Deploy from the Azure Portal

1. Open the IRRd offer on the Azure Marketplace and choose Get It Now, then Create.
2. Select your subscription, resource group and region, and choose the Standard_B2s size.
3. Provide your SSH public key for the azureuser account.
4. Allow inbound TCP 22, TCP 43 and TCP 8000 in the Network Security Group, then create the VM.

Step 2: Deploy from the Azure CLI

az vm create \
  --resource-group my-rg \
  --name irrd-01 \
  --image <irrd-marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Step 3: First boot

On the first boot of every VM, irrd-firstboot.service generates a unique PostgreSQL role password, a unique Redis password and a unique IRRd override password, writes them into /etc/irrd.yaml, starts irrd.service, and — once the whois and HTTP listeners are up — loads the demo RPSL object set into the CLOUDIMG-TEST source using the freshly-minted override password. First boot completes in well under a minute; give it a moment before you query it.

Step 4: Confirm the daemon is running

SSH in as azureuser and confirm every service is active and IRRd reports its version:

systemctl is-active irrd irrd-firstboot postgresql redis-server
python3 -c "import irrd; print(irrd.__version__)" 2>/dev/null || /opt/irrd/venv/bin/python3 -c "import irrd; print(irrd.__version__)"
ss -tln | grep -E ':43 |:8000 '

You should see active for every service, version 4.5.3, and listeners on :43 and :8000.

Step 5: Query the demo object over whois

Query the demo route object with a RIPE-style exact match:

whois -h <vm-ip> -p 43 -- '-x 192.0.2.0/24'

This returns the real route object loaded on first boot, with its origin (AS65000), its maintainer (CLOUDIMG-MNT) and its source (CLOUDIMG-TEST).

Other useful whois query forms (see the IRRd whois query documentation for the full syntax):

whois -h <vm-ip> -p 43 -- '-i origin AS65000'      # find every object with this origin
whois -h <vm-ip> -p 43 -- '!maut-num,AS65000'      # IRRd-style primary-key lookup

Step 6: Query over HTTP and GraphQL

The HTTP API exposes a machine-readable status page and a GraphQL endpoint for structured queries:

curl -s -X POST http://<vm-ip>:8000/graphql/ -H 'Content-Type: application/json' \
  -d '{"query":"{ rpslObjects(rpslPk: [\"AS65000\"]) { rpslPk objectClass } }"}'

curl -s http://<vm-ip>:8000/v1/status/

The GraphQL query returns the demo autonomous system object; the status page reports object counts and authoritative/mirror state per source. GraphQL supports much richer queries (filtering by prefix, maintainer, related objects) — see the IRRd GraphQL documentation and the interactive explorer at http://<vm-ip>:8000/graphql/ in a browser.

Step 7: Submit your own routing objects

New objects in a fresh authoritative source can only be created using the override password — this is IRRd's own bootstrap mechanism (a brand-new mntner object has no existing maintainer to authorise it). Retrieve your per-VM override password and use it once to create your own maintainer with its own auth: credential:

sudo cat /root/irrd-credentials.txt   # OVERRIDE_PASSWORD=...

MY_HASH=$(htpasswd -nbB dummy 'a-real-password-you-choose' | cut -d: -f2)

curl -s -X POST http://127.0.0.1:8000/v1/submit/ \
  -H 'Content-Type: application/json' \
  -d "{\"objects\":[{\"object_text\":\"mntner:         MY-MNT\ndescr:          my maintainer\nadmin-c:        CI1-CLOUDIMG-TEST\nupd-to:         me@example.com\nauth:           BCRYPT-PW ${MY_HASH}\nmnt-by:         MY-MNT\nsource:         CLOUDIMG-TEST\n\"}],\"override\":\"<OVERRIDE_PASSWORD>\"}"

Once MY-MNT exists, use its own password (not the override password) as the passwords field for every future change to objects it maintains — that is how a real registry operates day to day.

The same round trip proves the write path works end to end: a submission with the right override password is accepted, and the identical submission with a wrong password is rejected — the credential is doing real work, not just present in a config file.

Step 8: Delete or replace the demo objects

Once you have your own maintainer, remove the demo objects (or leave them — they occupy reserved, non-routable address space and a private ASN, so they cause no harm):

curl -s -X DELETE http://127.0.0.1:8000/v1/submit/ \
  -H 'Content-Type: application/json' \
  -d "{\"objects\":[{\"attributes\":[{\"name\":\"route\",\"value\":\"192.0.2.0/24\"},{\"name\":\"origin\",\"value\":\"AS65000\"},{\"name\":\"mnt-by\",\"value\":\"CLOUDIMG-MNT\"},{\"name\":\"source\",\"value\":\"CLOUDIMG-TEST\"}]}],\"override\":\"<OVERRIDE_PASSWORD>\"}"

Step 9: Mirror an upstream IRR source (optional)

To mirror an upstream registry (RADb, an RIR's own IRR, another operator's IRRd instance) instead of — or alongside — running your own authoritative source, edit /etc/irrd.yaml:

# Illustrative — adapt the source name and NRTM/ftp details to the real registry:
sources:
  CLOUDIMG-TEST:
    authoritative: true
    keep_journal: true
  RADB:
    authoritative: false
    import_source: ftp://ftp.radb.net/radb/dbase/radb.db.gz
    import_serial_source: ftp://ftp.radb.net/radb/dbase/RADB.CURRENTSERIAL
sources_default:
  - CLOUDIMG-TEST
  - RADB

sudo systemctl restart irrd

See the IRRd mirroring documentation for the full set of import/NRTM options per source. Mirroring a large source is what upstream's 32 GB RAM / 150 GB disk sizing guidance is for — size the VM accordingly before enabling a large mirror.

Step 10: Review your credentials and restrict access

sudo cat /root/irrd-credentials.txt

This file holds the unique POSTGRES_PASSWORD, REDIS_PASSWORD and OVERRIDE_PASSWORD generated for this VM, plus the ready-to-use whois/HTTP/GraphQL URLs. If you want a private-only instance rather than a publicly queryable one:

• Restrict the whois listener with an NSG rule limiting TCP 43 to your own networks (IRRd itself has no whois-level access control).
• Restrict the HTTP status page via server.http.status_access_list in /etc/irrd.yaml (an IRRd access list of permitted IPs/prefixes), and restrict TCP 8000 with an NSG rule for the same effect on GraphQL/submissions.
• Writes are already gated by the override password (or, once you have created your own maintainers, by their individual auth: credentials) regardless of network reachability.

Step 11: Security recommendations

• Rotate the override password periodically once you have your own maintainers set up — it is only strictly needed for initial bootstrap.
• Prefer per-maintainer BCRYPT-PW (or PGP) authentication over repeatedly using the override password for routine changes.
• Restrict TCP 43/8000 to the networks that need to query this registry if you are not intentionally running a public mirror.
• Keep the OS patched. The image ships fully updated and with unattended security upgrades enabled.

Step 12: Support and Licensing

IRRd is free and open source software distributed under the BSD-2-Clause License (© NTT Ltd. and Reliably Coded B.V.). This image bundles IRRd unmodified from the official PyPI package; your use of IRRd is governed by its license. cloudimg is not affiliated with, endorsed by, or sponsored by NTT Ltd., Reliably Coded B.V., or the IRRd project.

cloudimg images include 24/7 support. If you need help deploying or configuring IRRd on Azure, contact us.

Deploy on Azure

Find this image on the Azure Marketplace and deploy in minutes.

Need Help?

Email support@cloudimg.co.uk and our team will help you get up and running.