[Freeipa-devel] DNS update mechanism: news about update authorization

[Petr Spacek]

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 192.0.2.31 is able to modify only PTR 
record with name 31.0.2.192.in-addr.arpa., 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 we implement configurable realm check? I.e. the update will be allowed 
only if the update is signed by principal from specified Kerberos realm?

How it should work with Kerberos trusts?

Also, it should be possible to implement more strict check: Updated name in 
reverse zone (e.g. 31.0.2.192.in-addr.arpa.) 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: 192.0.2.31
- client's principal: host/client.example.com at TRUSTED.EXAMPLE.COM

This particular client is allowed only to add record:
31.0.2.192.in-addr.arpa. 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.

-- 
Petr^2 Spacek