RFC 9606; doggo; ZTDNS

No Drop tomorrow (July 4th), as your friendly neighborhood hrbrmstr will be taking the day to celebrate our last year of freedom in the U.S.

TL;DR

(This is an AI-generated summary of today’s Drop using Sonnet via Perplexity.)

Aaaaand links are magically back, though oddly constructed.

• RFC 9606 introduces the RESINFO DNS resource record type, allowing DNS resolvers to publish information about their capabilities, enabling clients to make informed decisions when selecting resolvers [https://www.rfc-editor.org/rfc/rfc9606.html]
• doggo is a modern command-line DNS client written in Go that supports multiple DNS protocols (DoH, DoT, DoQ, DNSCrypt) and offers human-readable output with color and JSON formatting options [https://github.com/mr-karan/doggo]
• Microsoft’s Zero Trust DNS (ZTDNS) Framework integrates the Windows DNS client with the Windows Filtering Platform to enable domain-name-based network traffic control, aiming to enhance security but potentially causing compatibility issues with existing applications and services [https://techcommunity.microsoft.com/t5/networking-blog/announcing-zero-trust-dns-private-preview/ba-p/4110366]

RFC 9606

DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) make it possible for us to use (theoretically) more secure/private methods of making DNS queries, but — unless you read HTML support pages (if they exist), you may not know if any given DNS resolver supports these more modern query techniques.

RFC 9606 introduces a new DNS resource record type called RESINFO (Resource Record Type 261) that allows DNS resolvers to publish information about their capabilities. This mechanism enables DNS clients to make informed decisions when selecting resolvers based on their features and policies.

These RESINFO queries use the same format as DNS TXT records, employing key/value pairs to convey resolver information. Also, DNS clients can retrieve resolver information using the RESINFO RR type and the QNAME of the resolver’s Authentication Domain Name (ADN) or “resolver.arpa” for Special-Use Domain Names.

The RFC defines three initial resolver information keys:

• qnamemin: Indicates support for QNAME minimisation
• exterr: Lists supported Extended DNS Error (EDE) codes
• infourl: Provides a URL for additional resolver information

I keep forgetting I’m not using Substack anymore, so I figured today was as good as any other to see how well tables work in WP! The following example RESINFO record indicates that the resolver:

• supports QNAME minimization
• can return Extended DNS Error codes 15, 16, and 17
• provides additional information at the specified URL

Can’t wait to RESINFO poke at this list of resolvers to see if/when any adopt this new RR type!

doggo

Since one can never have too many DNS clients, let’s take a peek at a new-ish Golang one dubbed doggo.

This new pup on the block is designed to provide a human-friendly alternative to traditional tools like dig. It offers a range of features and supports multiple DNS protocols:

• DNS over HTTPS (DoH)
• DNS over TLS (DoT)
• DNS over QUIC (DoQ)
• DNS over TCP
• DNS over UDP
• DNSCrypt

making it a fairly versatile tool for DNS queries and troubleshooting.

This spiffy tool also provides a wide range of command-line options for customizing queries, output format, and resolver behavior. These include options for specifying DNS record types, nameservers, output formatting (JSON, colored output, short format), and various resolver configurations like IPv4/IPv6 preference, TLS options, and timeout settings.

Basic doggo usage:

$ doggo mrkaran.dev
NAME         TYPE  CLASS  TTL   ADDRESS        NAMESERVER
mrkaran.dev. A     IN     20s   13.250.205.9   127.0.0.1:53
mrkaran.dev. A     IN     20s   206.189.89.118 127.0.0.1:53

Specifying a resource record:

$ doggo MX github.com @9.9.9.9
NAME       TYPE  CLASS  TTL    ADDRESS                    NAMESERVER
github.com. MX   IN     3600s  10 alt3.aspmx.l.google.com. 9.9.9.9:53
github.com. MX   IN     3600s  5 alt1.aspmx.l.google.com.  9.9.9.9:53
github.com. MX   IN     3600s  10 alt4.aspmx.l.google.com. 9.9.9.9:53
github.com. MX   IN     3600s  5 alt2.aspmx.l.google.com.  9.9.9.9:53
github.com. MX   IN     3600s  1 aspmx.l.google.com.       9.9.9.9:53

DOH:

$ doggo archive.org @https://cloudflare-dns.com/dns-query
NAME        TYPE  CLASS  TTL  ADDRESS       NAMESERVER
archive.org. A    IN     41s  207.241.224.2 https://cloudflare-dns.com/dns-query

JSON output:

$ doggo internetfreedom.in --json | jq
{
  "responses": {
    "answers": [
      {
        "name": "internetfreedom.in.",
        "type": "A",
        "class": "IN",
        "ttl": "22s",
        "address": "104.27.158.96",
        "rtt": "37ms",
        "nameserver": "127.0.0.1:53"
      },
      // ... additional answers ...
    ],
    "queries": [
      {
        "name": "internetfreedom.in.",
        "type": "A",
        "class": "IN"
      }
    ]
  }
}

Extra query metadata:

$ doggo duckduckgo.com --time
NAME           TYPE  CLASS  TTL  ADDRESS      NAMESERVER   TIME TAKEN
duckduckgo.com. A    IN     30s  40.81.94.43  127.0.0.1:53 45ms

If you would rather not pollute your system, give the web version a (heh) go!

ZTDNS

Microsoft’s Zero Trust DNS (ZTDNS) Framework is a new security feature designed to enhance DNS security within Windows networks. It integrates the Windows DNS client with the Windows Filtering Platform (WFP) to enable domain-name-based network traffic control.

To use it, admins must provision Windows with a set of DoH (DNS over HTTPS) or DoT (DNS over TLS) capable Protective DNS servers that are expected to resolve only allowed domain names.

Since we do not live in a perfect world, ZTDNS can further be configured with a list of IP address subnets that should always be allowed, accommodating endpoints without domain names.

By default, ZTDNS blocks all outbound IPv4 and IPv6 traffic, except for connections to the Protective DNS servers and essential network discovery protocols (DHCP, DHCPv6, NDP). DNS responses from configured Protective DNS servers containing IP address resolutions will trigger outbound allow exceptions for those IP addresses.

In theory, ZTDNS is designed to be interoperable, using network protocols from open standards to satisfy “Zero Trust” requirements, such as those found in OMB M-22-09 and NIST SP 800-207.

When applications attempt to send traffic to an IP address not learned through ZTDNS (and not on the manual exceptions list), the traffic is blocked. Since that has the potential to break things, ZTDNS can initially be deployed in an audit mode, allowing administrators to test its impact without enforcing blocks. Note that some virtualization technologies that implement their own networking stack (e.g., Windows Subsystem for Linux) may bypass ZTDNS enforcement.

Look at me all grown up and going six paragraphs without some scathing remark(s) about Microsoft! We need to fix that error right now. I’ve got some bones to pick with this new MS initiative. I’ll try to be brief:

• ZTDNS disrupts many insecure networking features, including mDNS, LLMNR, NetBIOS Name Resolution, UPnP, and WebRTC. This may cause compatibility issues with existing applications and services.
• ZTDNS may also struggle with IPv6 address allocation in some scenarios, potentially complicating IPv6 adoption.
• While VPNs and SASE/SSE solutions can work with ZTDNS, all traffic through these tunnels will appear associated with the gateway’s domain or IP, potentially reducing granular control.
• The full benefits of ZTDNS may require the use of Microsoft Intune or other Mobile Device Management (MDM) solutions, potentially locking organizations into specific management ecosystems.
• Moving DNS lookup control to the remote side, ZTDNS may limit clients’ freedom to control what is allowed or blocked locally.
• Folks at home (if this becomes tech they can use or tech that is forced upon them by Redmond) who employ DNS blocking devices (e.g., Pi-Hole, AdGuard Home) may find these tools less effective if ZTDNS enforces DoH, potentially benefiting Microsoft by making it harder to block their ads or telemetry. Thankfully, it does seem to be only designed for enterprises.
• I have serious concerns that this technology could be used to chip away at user freedom and privacy under the guise of security.
• As ZTDNS is tightly integrated with Windows and potentially Microsoft’s cloud services, adopting this framework may create dependencies on Microsoft’s ecosystem, making it challenging to switch to alternative operating systems or security solutions in the future.
• And (finally!) orgs with mixed operating system environments may face challenges in maintaining consistent DNS security policies across all devices.

It won’t be a shocker to know that I’ll never configure this in any org I’m in, and most certainly won’t have to deal with it at home, as we’re a macOS shop.

If you’re stuck in an enterprise or academic setting where admins adopt this, get ready to feel some serious pain.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️