[Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp

[Brendan Kearney]

On Wed, 2014-12-31 at 19:06 +0100, Jan Pazdziora wrote:
> On Mon, Dec 29, 2014 at 07:12:26PM -0500, Brendan Kearney wrote:
> > On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote:
> > > bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP 
> > > storage.
> > > The updates are done by BIND. The IPA BIND accepts kerberos based updates.
> > > 
> > > http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG
> > 
> > this allows for a ticketed client to update DNS records directly, which
> > is not a best practice and is a huge security risk.  clients should not
> > be able to manipulate DNS zones.
> 
> Only if you configure that. But you don't have to grant krb5-self,
> you can grant the
> 
> 	SERVICE\047ipaserver.example.com at EXAMPLE.COM wildcard * ANY;
> 
> and just have the DHCP service call nsupdate -g.
> 
> > dynamic updates to DNS zones should come from DHCP, where dynamic
> > addressing is managed.  as such, i have directives in DHCP and DNS to
> > establish authenticated updates between DHCP and DNS.  for example:
> > 
> > /etc/named.conf:
> > 
> > key "dhcp" {
> >         algorithm hmac-md5;
> >         secret SomeRandomString;
> > };
> 
> With FreeIPA, Kerberos authentication is really the preferred way
> of integrating pieces together because it provides the identity of
> the service running the action, not just some shared secret / password.
> 
> > because the DHCP daemon is not kerberized, the update policies do not
> 
> [...]
> 
> > i am wondering how to manage DDNS updates from DHCP, where kerberized
> > updates are not likely going to happen.
> 
> What DHCP software is that and how hard would it be to Kerberize it?
> 

i have played with nsupdate, and it does look like updates will be
allowed if i remove the access restriction, but i am losing the
authenticity of the update, since the TSIG shared secret signs the
update.

regardless of authentication, client updates to DNS zones are still a
risk and a rogue app or user can still perform direct updates to zones,
leading to impersonation/interception of services, denial of service
attacks and more.  endpoints, or their users, should not be trusted to
make updates to DNS zones.  TSIG signed updates from servers are still
preferred over authenticated updates from endpoints or users.

i am using ISC DHCP, and cannot speak to any level of effort required to
incorporate Kerberos into the code.