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@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
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
