[dhcwg] Why draft-ietf-dhc-addr-notification-13 and not DNS up date instead?

Petr Menšík <[email protected]> Mon, 18 Nov 2024 20:33:29 +0100
Newsgroups	gmane.ietf.dhc
Message-ID	<[email protected]>
Hello,

I work in Red Hat as a software engineer and one of components I work on 
is dnsmasq. It combines DNS and DHCP service into simple box. It made me 
think how to solve IPv6 and registration of machines with SLAAC.

I just today stumbled on draft draft-ietf-dhc-addr-notification-13 [1]. 
It seems nice, but I think DNS dynamic update (RFC 2136) might be a 
better solution. When I were thinking about my home network and how to 
pair my hostname to IPv6 address, similar way in IPv4 dnsmasq does 
itself automatically. Because it uses DHCP, including hostname option. 
But in IPv6 most clients do not even try to use DHCPv6.

DNS offers potential improvements, which are not common in DHCP, any 
version. DNS over TLS is becoming relatively common. It has relatively 
common registration of hostnames to network servers, protected also by 
advanced authentication methods like kerberos 5. When you already have 
working IP address, why should be DHCP protocol used to register the 
host? Is any relatively good authentication available in DHCP? Is it 
common even on home networks?

One primary problem would be that we want records to have limited 
lifetime. But I think that can be solved by 
draft-ietf-dnssd-update-lease-08 [2]. While it is needed also for 
publishing services only when machine is still in radio range, it 
applies to how DHCP registers machines as well. That is mainly why DHCP 
were chosen, right? To refresh periodically the record and have it 
deleted, even if the client did not ask for deleting explicitly.

I think that would work well enough for enterprise and home networks. On 
a home network, no authentication might be needed. I think update done 
over TCP is okay. Requires handshake, so client address cannot be 
trivially forged.

The only thing I am missing is indication from network, that clients may 
attempt registration to network servers and it is willing to accept 
them. It may even provide own set of servers, but reusing already 
provided DNS servers, maybe with TLS name certificate, might be more 
useful. I think RA needs to contain just indication network provided 
servers are willing to accept registrations. It may specify how they 
need to be authenticated to be accepted. And what domain should clients 
register into.

I thought about implementing dynamic update into dnsmasq, similar way it 
accepts hostnames in DHCP requests. For enterprise networks it can be 
improved significantly. TSIG signatures can provide shared password or 
krb5 authentication. Good for CEO's laptop, I suppose?

If DNS request can pass along IP address, it may be integrated with 
network to obtain also hardware from it. For dnsmasq it would be 
trivial, if it is on the same link as client. We may need EDNS0 
extension for relayed networks. But do we even care for MAC address, if 
we have strong authentication instead?

What do you think about my idea?

Best Regards,

Petr Menšík

1. https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/
2. https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/

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

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
OpenPGP_0x4931CA5B6C9FC5CB.asc (application/pgp-keys, 9.5 KB)
OpenPGP_signature.asc (application/pgp-signature, 495 B)