Bug #32879 for bind9-public: New update-policy match type proposal: authenticated PTR update

> Please let us know if you are interested in this functionality. We > could contribute patches. Yes, thank you, this sounds useful. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.

---

Hello Evan, it is still in my TODO list. At the moment, I work on support for DNSSEC in our own LDAP database driver for BIND9. We contacted ISC regarding this LDAP driver in [ISC-Bugs #24733]. (Home page is https://fedorahosted.org/bind-dyndb-ldap/) Update policy for authenticated changes to PTR records will be the next step. Are there some rough deadlines we have to meet for earliest possible inclusion in BIND9? I mean something like 'patches for upcoming releases are accepted till end of August, December, and then April'? Thank you. Petr Spacek On 23.7.2013 21:06, Evan Hunt via RT wrote: > Hello Petr, > > I never heard back from you about patches for this work. Has any progress > been made on it? I still think it sounds like a useful idea. > > On Fri Mar 15 11:40:38 2013, pspacek@redhat.com wrote: >> Hello, >> >> I would like to propose new match-type usable in BIND's update-policy >> for >> secure (authenticated and TCP-verified) PTR updates. >> >> The idea came from project FreeIPA (www.freeipa.org), sponsored by Red >> Hat. >> >> Previous discussion about PTR record updates can be found in mailing >> list archive: >> https://www.redhat.com/archives/freeipa-devel/2013-March/msg00006.html >> >> Please let us know if you are interested in this functionality. We >> could >> contribute patches. >> >> >> Current state - why we need a new type: >> - With krb5-self and ms-self match-types it is possible to require >> TSIG/GSSAPI >> authentication, but it is not possible to use IP address of the signer >> for >> additional verification. >> I.e. in the case where all hosts are allowed to update reverse zone, >> single >> compromised host can mess with whole reverse zone. >> >> - With tcp-self match-type it is possible to limit PTR record updates >> in >> reverse zone to names matching source IP address of the TCP >> connection, but >> request signature is ignored in that case. >> E.g. any user logged to a machine can send update request and modify >> PTR >> record of the machine to arbitrary value. >> >> >> Proposal: >> Add new match-types tcp-krb5-self and tcp-ms-self for secure PTR >> updates. >> - Proposed match-types require same valid signature as krb5-self and >> ms-self. >> i.e. host/<hostname>@CONFIGURED.REALM and >> <hostname>$@CONFIGURED.REALM. >> >> - Source IP address of the TCP connection have to exactly match >> updated name >> in the same way as for tcp-self. >> >> - New PTR data sent by client have to match host name in the >> signature. >> >> >> Example: A update request allowed by tcp-krb5-self: >> >> update-policy = 'grant EXAMPLE.COM tcp-krb5-self;' >> source IP address = 192.0.2.1 >> Kerberos principal = host/client.example.com@EXAMPLE.COM >> update request = >> update add 2.0.192.in-addr.arpa. 3600 IN PTR client.example.com >> >> Request above should be *denied* if: >> - Source IP address doesn't match updated name (property of current >> tcp-self >> match-type). I.e. compromised host can mess only with record >> associated to >> it's actual IP address. >> >> - Signer's REALM doesn't match realm specified in update policy >> (property of >> current krb5-self match-type), i.e. hosts coming via cross-realm >> trusts are >> not allowed to update records if realm is not '*'. >> >> - New PTR data doesn't match signer's name, i.e. client.example.com is >> not >> allowed to update PTR record associated with it's IP address with data >> like >> secureserver.example.com. >> >> If we combine requirements above, one compromised host is able to mess >> only >> with PTR record associated with it's actual IP address and is not able >> to >> create record pointing to a fake name. >> >> >> Record deletion is a problem, but we tend to allow client to delete >> all PTR >> records under name associated with it's IP address. >> >> Please let us know if you are interested in this functionality. We >> could >> contribute patches. -- Petr^2 Spacek

---