[Dnsmasq-discuss] Do we have good way to register SLAAC clients?

[Petr Menšík]

I have just found RFC draft EDNS(0) option to negotiate Leases on DNS 
Updates [1]. It seems it would be good not only for SRV records of 
DNS-SD, but also for hostnames registered from SLAAC clients.

Of course there would have to be some indication to clients to try 
sending update. Maybe new RA option for that? I think we may allocate 
similar record that we create for DHCP clients. Just allow DNS client to 
do UPDATE query on domain offered to them, unless they conflict. If they 
do not send another update, delete it after leased time. Could work, right?

I guess accepted should be only A, AAAA and PTR. Maybe also SRV with a 
correct service prefix.

Found a reference for that on dnsextd [2]. It acompanies RFC 8764, which 
is more useful for Avahi than dnsmasq. But limited updates might be 
useful even for us.

Cheers,
Petr

1. https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-07.html
2. 
https://github.com/apple-oss-distributions/mDNSResponder/blob/d31f3447dfb1997e6457abf83502390b1f42f2ce/mDNSShared/dnsextd.8
3. https://datatracker.ietf.org/doc/rfc8764/

On 6/12/23 19:53, Simon Kelley wrote:
> Dnsmasq has a feature, enabled by "ra-names" which attempts to solve 
> this problem for dual-stack hosts.
>
> It works like this.
>
> When a host gets a DHCPv4 address, dnsmasq calculates the address that 
> the client would assign itself using SLAAC, and pings that address. If 
> it gets a reply it adds the address and the name derived from the 
> DHCPv4 transaction to the DNS.
>
> This used to work for Android, but modern Android seems to have 
> implemented SLAAC privacy extensions, which makes it impossible for 
> dnsmasq to predict which SLAAC address  the host will chose (by 
> design) and therefore breaks the hack.
>
> Looking at the logs on my network, it's still working for a Chromecast 
> and Nest Audio, but not the Android phones.
>
> This isn't a good solution, but it's the best I've come up with.
>
> Simon.
>
--

Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB