On Fri, 2013-03-01 at 15:29 +0100, Petr Spacek wrote:
> Hello list,
> we would like to share some news about DNS update mechanism:
> - It is possible to allow particular principal to update all records in a 
> zone.
> - It is possible to allow clients to update own PTR records. PTR update can 
> be 
> "authenticated and authorized" by source IP address of the TCP connection 
> from 
> the client. E.g. client with IP address is able to modify only PTR 
> record with name, nothing else.
> See examples in following how-to:
> http://freeipa.org/page/Dynamic_updates_with_GSS-TSIG#Dynamic_update_policy
> Simo pointed to fact that "TCP authenticated" update requests can be more 
> secure than current approach with "PTR synchronization" magic (done inside 
> bind-dyndb-ldap).
> Unfortunately, it is not possible to combine TCP "authentication" with 
> GSS-TSIG signature. BIND's ACL check mechanism stops at first match, so it is 
> not possible to combine multiple requirements.
> 'tcp-self' rule ignores request signature completely. Implementation of (TCP 
> && signed) requirement will require patching BIND. I don't like that idea, 
> because we will deviate from plain BIND docs and it will cause confusion.
> We can propose a change and send patches to ISC. It should be possible to 
> implement new 'tcp-signed-self' mechanism with only few lines of code. The 
> question is how it should behave:
> Is *any* signature enough? I.e. anybody with valid Kerberos ticket is allowed 
> to do tcp-self update?

Should be at least a host/ principal, otherwise a mere user could change
the PTR record, would be even better if we can match the fqdn int the
host/ principal to the content of the PTR record.

So if you sign with principal for host/foo.bar.baz and come from then you can only create a PTR record of ->

> Should we implement configurable realm check? I.e. the update will be allowed 
> only if the update is signed by principal from specified Kerberos realm?

This too would be nice but not as important.

> How it should work with Kerberos trusts?

You would prevent principals from a trusted domain to update DNS
Checking for the REALM part should be optional. 

> Also, it should be possible to implement more strict check: Updated name in 
> reverse zone (e.g. has to match client's IP address 
> and *at the same time* name stored to PTR record has to match name in 
> client's 
> principal.
> Example:
> - client's IP address:
> - client's principal: host/client.example....@trusted.example.com

Yeah I should have read the whole message trough before starting
replying :-)

> This particular client is allowed only to add record:
> IN PTR client.example.com.
> Question is how to authorize record deletion. I tend to allow all delete 
> operations for (reverse) name matching client's IP address.

Yes this would be ok, worst case the PTR is lost.
Again I would allow only by principals of the type host/* or maybe DNS/*
not from every principal.


Simo Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to