Wes Ellis./ a personal notebook
Technology. Stories. Side projects.
A few things worth writing down.
SearchSubscribe
← Back to Engineering

Engineering

Pushing DNS Servers to Clients with RADIUS Vendor-Specific Attributes

By Wes Ellis4 min read

The old version of this post said "contact your DNS vendor for the attribute ID." That's not how it works, and I'd rather replace it with something that'll actually help you on a Tuesday afternoon when the VPN clients are resolving everything through the coffee shop's router.

Here's the real picture: your RADIUS server can include DNS server addresses in the Access-Accept it sends back, and the device asking (the VPN concentrator, firewall, or other network access server) can hand those to the client. Whether that works depends almost entirely on the network access server, not the RADIUS server and definitely not your DNS server.

Why a vendor-specific attribute?

The core RADIUS RFCs define standard attributes for things like the username, the assigned IP address, and session timeouts. There's no standard IPv4 DNS server attribute. (IPv6 got one later, DNS-Server-IPv6-Address, in RFC 6911.)

So vendors fill the gap with Vendor-Specific Attributes (VSAs). Every VSA rides inside standard attribute 26 and contains:

  • a 4-byte Vendor-ID, which is the vendor's IANA private enterprise number,
  • the vendor's own attribute type number,
  • and the value, in whatever format the vendor defines.

The NAS reads attribute 26, checks the Vendor-ID, and only acts on it if it recognizes both the vendor and the attribute. Everything else it silently ignores. Keep that last bit in mind; it's the source of most "I configured it and nothing happened" stories.

Figure out which attribute your NAS listens for

Go to the documentation for the box that terminates the connection: the VPN appliance, firewall, or RAS server. Search for "RADIUS attributes" or "RADIUS dictionary." You're looking for three things: the Vendor-ID, the attribute number (or name), and the value format.

The one set I'll give you by number is Microsoft's, because it's written down in an RFC. RFC 2548 defines Microsoft VSAs under Vendor-ID 311, including:

Attribute Type Value
MS-Primary-DNS-Server 28 IPv4 address
MS-Secondary-DNS-Server 29 IPv4 address

They came out of Microsoft's dial-up and VPN world, and some third-party VPN and PPP servers honor them. Plenty don't. For anything else, trust the vendor's dictionary, not a forum post, and definitely not a number you half-remember.

Adding it in Windows NPS

In the Network Policy Server console:

  1. Open Policies > Network Policies and edit the policy that matches your VPN or wireless connections.
  2. On the Settings tab, under RADIUS Attributes, select Vendor Specific and click Add.
  3. If your vendor and attribute are in the list, pick it. If not, choose Vendor-Specific (the custom entry), click Add, and enter the vendor code.
  4. Say yes, it conforms to the RFC VSA format (almost everything does), then enter the vendor-assigned attribute number, the value format the vendor documents, and the DNS server address.
  5. Add a second entry for the secondary server if the NAS supports one.

Put it on the network policy, not the connection request policy, so it only goes out on a successful match.

Adding it in FreeRADIUS

FreeRADIUS ships dictionaries for most vendors, including Microsoft, so you can use attribute names. A catch-all reply in the users file (mods-config/files/authorize in FreeRADIUS 3) might look like this:

DEFAULT
        MS-Primary-DNS-Server := 192.0.2.53,
        MS-Secondary-DNS-Server := 192.0.2.54

If your vendor isn't in the bundled dictionaries, add a small dictionary file with a VENDOR line and ATTRIBUTE lines from their documentation rather than guessing.

Prove it works

Don't trust the config screen. Check each hop:

  1. Is the RADIUS server sending it? In FreeRADIUS, run radiusd -X and watch the Access-Accept. For NPS, a packet capture on the server shows the attribute in the reply. radtest or radclient against FreeRADIUS is a quick way to trigger one without a real client.
  2. Is the NAS accepting it? Most VPN appliances have a debug or session view that shows received RADIUS attributes. If the attribute isn't listed there, the NAS doesn't recognize it.
  3. Is the client getting it? On Windows, ipconfig /all against the VPN adapter, or Get-DnsClientServerAddress in PowerShell.

Gotchas

Local settings can win. If the VPN pool or DHCP scope on the NAS already hands out DNS servers, it may ignore the RADIUS value, or the other way round. Check the NAS's precedence rules.

Format matters. An IP address sent as a string when the NAS expects a 4-byte address will be dropped without a word.

Wi-Fi is usually a dead end. On 802.1X wireless, clients get DNS from DHCP after the network lets them on, not from RADIUS. Use DHCP options there.

If your NAS doesn't document a DNS attribute at all, that's your answer. Set DNS on the NAS or in DHCP and move on.

Keep reading