On 15/02/11 01:15, Mark Andrews wrote:

      * There is a new update-policy match type "external". This allows
        named to decide whether to allow a dynamic update by checking with
        an external daemon. Contributed by Andrew Tridgell of the Samba
        Project. [RT #22758]

This is a useful feature (which I've just tested). However it has some rather serious flaws for certain use-cases[1].

Specifically, the data supplied to the external helper loses much of the context from the original update request. Imagine you have a zone:

foo.domain.com  TXT "some data"
foo.domain.com    A 192.168.1.10

...and someone sends:

update delete nx.domain.com
update delete foo.domain.com
update add www.domain.com 300 A 192.168.1.1
update add www2.domain.com 300 AAAA 2001:db8::1

...the helper will receive 4 separate external lookups:

name=foo.domain.com rrtype=TXT
name=foo.domain.com rrtype=A
name=www.domain.com rrtype=A
name=www2.domain.com rrtype=AAAA

The problems I see are:

 * You see nothing for "nx.domain.com"
* Each lookup is on a separate unix stream socket, so you don't know they're related.
 * There's no info about whether it's a delete or addition
* Because of this, if you deny the last one, you can't know that the previous 3 didn't apply either

I understand why these happen and that it might be difficult to fix, but thought I'd mention it here.


[1] One of the use-cases we have in mind is logging dynamic updates by windows clients and using the external policy check to order our existing static "SQL->DNS" process to "skip" those; if a client sends an update with multiple add/deletes and we only deny one, we will erroneously mark the others to be skipped, because we lack transactional info (as well as whether it's a delete/add)


Also:

1. It's normally obvious from the keyname or identity, but since it might be possible for those to conflict, the key algorithm would be useful as an explicit field.

2. The documentation says "Requests to the external daemon are sent over the UNIX-domain socket as datagrams"; this is a bit confusing at and could be reworded. The unix socket is a SOCK_STREAM socket (not a datagram socket) receiving version/len/payload frames - this took a few minutes to figure out. Maybe:

"Request to the external daemon are sent over a UNIX stream socket. Request messages are formatted as follows..."
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to