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/[email protected]
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
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
