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 192.0.2.31 is able to modify only PTR > record with name 22.214.171.124.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 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 10.11.22.33 then you can only create a PTR record of 10.11.22.33 -> foo.bar.baz > 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 entries. 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. 126.96.36.199.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....@trusted.example.com Yeah I should have read the whole message trough before starting replying :-) > This particular client is allowed only to add record: > 188.8.131.52.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. 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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel