[Dnsmasq-discuss] RFC 2136 DNS Update?

[Petr Menšík]

I thought about it very similar way. Yes, SLAAC clients even on trusted 
network have absolutely no good way to make their own name registered 
and recognized similar way as DHCP clients have. Yes, it would first 
have to start on client side to even try to attempt to register the name.

I would like this configurable via Network Manager, which should provide 
way to send name registration on trusted network, but stay as anonymous 
as possible on public networks like mass transit, hotels, conferences or 
airports.

sssd already has some support for sending name updates. I think we need 
two things:

- indication from the network, likely an router advertisement extension, 
indicating router is willing to update names without strong authentication

- client reacting to it if allowed by machine owner/administrator. We do 
not want network on train to tell our laptops to reveal its name. sssd 
or nsupdate backed scripts might work.

- acceptance at dnsmasq with updates requested. It might be restricted 
to --auth-zone. There is no authentication involved in dnsmasq even in 
DHCP case. So this is not significantly less secure.

I am old enough to know Windows 2000 once did that on any network they 
connected. I think unconditionally. It were quite annoying to see logged 
attempts refused in common bind installation. But I think we want 
something like that for ipv6, but tuned up. Those addresses are even 
less friendly to type.

The only problem I see is DHCP requires multiple packets to confirm 
source address and insert the name. Single update DNS packet doing the 
same does not allow checking source address validity.

Should it be allowed only over TCP?

I general I would like that too. Not sure how fast I can prepare some 
proposal, by queue is getting long already.

On 20. 03. 24 21:48, Ronan Pigott via Dnsmasq-discuss wrote:
> Hi dnsmasq,
>
> So I searched around and found some very old discussions about supporting DNS
> Update in dnsmasq. It seems like the feeling was that since dnsmasq already
> gathered it's own information base from DHCP, it wasn't necessary to add DNS
> Update support for clients because we already know their local address.
>
> Today I am interested in DNS Update support for the benefit of IPv6 home lans,
> especially IPv6 only lans, where we cannot derive the host address from DHCP
> leases. With --enable-ra, in some cases we can guess the client address if it
> chooses EUI-64 addresses, but RFC 7217 "stable privacy" addresses are
> increasingly common, and once again it seems there is just no way to resolve
> AAAA records accurately on the lan. I think DNS Update could resolve this
> problem.
>
> Any thoughts on reconsidering support for this protocol in dnsmasq? Or other
> solutions?
>
> Cheers,
>
> Ronan
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9736 bytes
Desc: OpenPGP public key
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20240404/405646fb/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20240404/405646fb/attachment.sig>