Branded, resilient security demos, engineered for trust

Try it yourself: Test the resolver and DNSSEC

Plain‑English explainer: You can point DNS lookups at our branded hostname (dns.securenode.co.uk) and resolve any domain to prove traffic flows through our alias. For DNSSEC, use a signed domain (like securedns.co.uk or cloudgateways.co.uk) and you’ll see the attached cryptographic signatures (RRSIG) and the public keys (DNSKEY). That’s the verifiable “chain of trust” in action.

Resolve any domain through our hostname

This shows that queries are flowing through the SecureNode alias (not your system default resolver).

# Windows PowerShell
Resolve-DnsName -Name example.com -Server dns.securenode.co.uk

• Swap the domain: Replace example.com with any domain you want (e.g. bbc.co.uk, cloudflare.com).
• What you’ll see: Normal A/AAAA/MX/TXT answers, resolved via dns.securenode.co.uk.

Check DNSSEC signatures on signed domains

Use a DNSSEC‑enabled domain to see the attached RRSIG signature block.

# Ask for the A record and include DNSSEC data
Resolve-DnsName -Name securedns.co.uk -Type A -Server dns.securenode.co.uk -DnssecOk

# Or use another signed zone
Resolve-DnsName -Name cloudgateways.co.uk -Type A -Server dns.securenode.co.uk -DnssecOk

• Look for: An RRSIG section with fields like TypeCovered, Algorithm, Signer, and Expiration.
• Why it matters: The RRSIG proves the record was signed by the zone and validated through the DNSSEC trust chain.

Inspect the DNSKEYs (the public keys)

Fetch the zone’s DNSKEY RRset used to verify signatures.

Resolve-DnsName -Name securedns.co.uk -Type DNSKEY -Server dns.securenode.co.uk
Resolve-DnsName -Name cloudgateways.co.uk -Type DNSKEY -Server dns.securenode.co.uk

• What you’ll see: DNSKEY records (typically KSK/ZSK) that your resolver uses to validate the RRSIGs.
• Together with RRSIG: DNSKEY + RRSIG demonstrates an end‑to‑end, verifiable chain of trust.

Optional: Terminal test (macOS/Linux)

If you prefer Terminal with dig, you’ll see the AD flag and signatures inline.

dig @dns.securenode.co.uk securedns.co.uk A +dnssec
dig @dns.securenode.co.uk cloudgateways.co.uk A +dnssec

• Look for: The ad (Authenticated Data) flag in the header and the RRSIG alongside the answer.

Tips and common gotchas

• Unsigned domains: If a zone isn’t DNSSEC‑signed, -Type RRSIG may return SERVFAIL — that’s expected.
• PowerShell quirk: Prefer -DnssecOk with a normal record type (e.g. A) to see attached signatures; direct -Type RRSIG can fail on some resolvers.
• Any domain works: Use any domain for the basic resolution test; use a signed domain for the DNSSEC proof.

Bottom line: You can point queries at dns.securenode.co.uk to prove resolution flows through the branded alias, and you can verify DNSSEC by viewing RRSIG and DNSKEY on signed zones. It’s a practical, zero‑cost pattern you can replicate under your own brand.

Build your own

SecureNode is also a pattern. You don’t need enterprise hardware to explore DNSSEC, resolvers, or branded aliases. A simple home lab setup lets you experiment safely and understand how the pieces fit together. It’s the perfect environment to simulate misconfigurations, DNSSEC failures or firewall rules and to see how real‑world issues surface and can be fixed without risking production. You can replicate this setup under your own brand in two different ways:

1. Alias an existing resolver (our approach)

This is how dns.securenode.co.uk works today:

• Pick a trusted public resolver (e.g. Cloudflare 1.1.1.1, Quad9 9.9.9.9, Google 8.8.8.8).
• Create a branded hostname (e.g. dns.yourbrand.co.uk) and point that hostname at your chosen resolver’s IP using an A record eg: dns.yourbrand.co.uk has an A record of 1.1.1.1
• Sign your zone at the domain registrar so the alias itself is DNSSEC‑protected.
• Result: a zero‑cost, branded resolver alias that looks and feels like a professional service, backed by enterprise infrastructure.

This is the quickest way to demonstrate “engineered trust” without running your own server, exactly what SecureNode does.

2. Run your own resolver (full control)

If you want to operate the resolver yourself, here’s the recipe:

• Run a lightweight resolver (e.g. Unbound) on a free‑tier VM or home lab device.
• Enable DNSSEC validation and open UDP/TCP port 53.
• Just like dns.securenode.co.uk points to 1.1.1.1, you can create your own branded hostname that maps to your home lab resolver.
• Sign your zone at the registrar so the chain of trust is verifiable (enable DNSSEC at your domain registrar).
• Optional: add encrypted DNS (DoT on TCP/853 or DoH on TCP/443) for modern clients (see more below).
• Result: a zero‑cost, enterprise‑ready demo resolver that you fully control.

# Install (Ubuntu/Debian)
sudo apt-get update && sudo apt-get install unbound

# Minimal /etc/unbound/unbound.conf excerpts
server:
  verbosity: 1
  interface: 0.0.0.0
  interface: ::0
  port: 53
  do-ip4: yes
  do-ip6: yes
  do-udp: yes
  do-tcp: yes
  harden-dnssec-stripped: yes
  qname-minimisation: yes
  prefetch: yes
  hide-identity: yes
  hide-version: yes
  rrset-cache-size: 256m
  msg-cache-size: 128m

# Enable and start
sudo systemctl enable unbound
sudo systemctl start unbound

# Open firewall (example, ufw)
sudo ufw allow 53/tcp
sudo ufw allow 53/udp

# Point dns.yourdomain.co.uk A/AAAA to your VM IP when ready
        

This option gives you maximum autonomy and lets you experiment with DNSSEC, DoT/DoH, and custom policies under your own brand.

Bottom line: Whether you alias an existing resolver or run your own, the pattern is the same, a branded, DNSSEC‑signed hostname that demonstrates trust and resilience with minimal overhead.