On 1.3.2013 15:39, Simo Sorce wrote:
On Fri, 2013-03-01 at 15:29 +0100, Petr Spacek wrote:
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 18.104.22.168.in-addr.arpa., nothing else.
See examples in following how-to:
Simo pointed to fact that "TCP authenticated" update requests can be more
secure than current approach with "PTR synchronization" magic (done inside
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 ->
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. 22.214.171.124.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
- 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
This particular client is allowed only to add record:
126.96.36.199.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.
I agree. We could imitate krb5-self semantics:
Service part is hardcoded to 'host/' and REALM part is configurable:
'grant IPA.EXAMPLE.COM tcp-krb5-self;'
Variant for AD machines:
'grant AD.EXAMPLE.COM tcp-ms-self;'
AD variant will match names "machine$@AD.EXAMPLE.COM".
Freeipa-devel mailing list