[Feature] Support for node attributes (nodeattrs)

[nielscil]

Use case

I would like to use headscale and NextDNS together. Tailscale supports configuring different profiles using node attributes. This is something I would like to use in headscale too.

In addition some other features also need the use of node attributes, like #2146

Description

This feature request would implement the use of nodeattrs inside the policy file and support nextDNS profile options as metioned in the official tailscale docs.

example of policy

{
	"acls": ["..."],
	"nodeAttrs": [
		{
			"target": ["*"],
			"attr": [
                                "nextdns:abc123",
				"nextdns:no-device-info",
			],
		},
	],
}

this issue is a duplicate of #1407, but is closed because it got stale.

Contribution

• I can write the design doc for this feature
• I can contribute this feature

How can it be implemented?

• Add nodeAttrs to policy file and parse inside ACLPolicy
• Retrieve attributes in mapper.go
• When using NextDNS DOH (already checked in mapper.go)
  • When nextdns-attribute is provided, change the profile of the uri
  • When nextdns:no-device-info is provided, skip adding the extra device info (currently done in mapper.go)
• Add attributes to tnode.CapMap inside tail.go.

[kradalby]

I think we already support nextdns via the config, just not via nodeattrs.

[nielscil]

Yeah, but that is on global level, isn't it? I would like to have different profile for different users.

[mindolo]

Hello!

Just wanted to note that support for node attributes would be critical for enabling MagicDNS AAAA records, a feature recently added to Tailscale (1.84+).

This is now supported via a new magicdns-aaaa node attribute, as seen in this upstream issue: tailscale/tailscale#1152

Implementing this would also resolve the functionality requested in this old and closed issue: #1027

And btw, thank you for headscale.

[tywil04]

Just to bump, support for nodeAttrs would (I believe) enable support for Taildrive: https://tailscale.com/kb/1369/taildrive.

[englut]

Would also like support for nodeAttrs as I want to disable captive portal detection.

[kradalby]

An observation, some of these nodeAttrs seem to be "just a string" sent to the client, and then the client knows what to do with it, meaning it will just work when we implement nodeAttrs.

Some are more involved, like ippool (#2912), requiring us additional server-side features.

It would be good to understand which features fall in each group and create separate issues for the ones that require server-side changes.

taildrive, and captive portal might be "string only", would you be able to help investigate this @tywil04 and @englut ?

[kradalby]

I did a research session with claude:

Research summary on nodeAttrs implementation:

After investigating the Tailscale client, nodeAttrs fall into two categories:

"String only" (client handles everything):

• disable-captive-portal-detection - client skips captive portal checks
• magicdns-aaaa ([Feature] Add support for the MagicDNSPeerAAAA Node Attribute #2723) - client synthesizes AAAA records locally
• randomize-client-port - already implemented globally, nodeAttrs would enable per-node
• drive:share / drive:access - enables Taildrive UI (but permissions need [Feature] "grants" feature support #2180 grants)

These just require passing the string in CapMap - minimal server work.

Server-side work required:

• nextdns: - server must build DNSConfig.Resolvers per-node
• ipPool ([Feature] IP pool #2912) - server must allocate IPs from specified pool
• funnel (tailscale cert + serve tracking #2527) - requires DNS/ACME infrastructure

Dependencies:

• [Feature] IP pool #2912 (IP Pool) → depends on nodeAttrs
• [Feature] Add support for the MagicDNSPeerAAAA Node Attribute #2723 (MagicDNS AAAA) → depends on nodeAttrs

A minimal nodeAttrs implementation could start with the "string only" capabilities, then add server-involved features incrementally.