On Wed, Jan 30, 2013 at 11:14:04AM +0800, Kent Tong wrote:
> Thanks for the kind and excellent replies! So, currently there is no way
> for the client to negotiate the key on-demand automatically?
I don't see a way, no.
There's a partially-implemented feature where negotiated keys can be dumped
t
Hi all,
On Wed, Jan 30, 2013 at 5:27 AM, Evan Hunt wrote:
>
> The key generated by keycreate can then be used on the client side
> to sign transfer requests:
>
> key negotiated-key.server {
> algorithm hmac-md5;
> secret "MlNODIuzTrNMgSLRCFB1Iw==";
> };
>
Thanks for the
On 01/28/2013 18:10, Brian Kroth wrote:
>
> I've had a very similar experience where I'm at.
>
>> At least from the NIST presentation, I got information on how to
>> contact somebody about these problems since its usually hard to send
>> email to the listed RNAME.
>
> Can you share? It's true tha
On Tue, Jan 29, 2013 at 04:22:07PM +0800, Kent Tong wrote:
> I read that Bind9 supports using TKEY for zone transfers. However, I don't
> understand how the TKEY negotiation is triggered.
Huh. That is much harder than it ought to be (a fact I hadn't realized
until now, as I'd never had occasion t
In message
, Kent Tong writes:
>
> Hi,
>
> I read that Bind9 supports using TKEY for zone transfers. However, I don't
> understand how the TKEY negotiation is triggered. In comparison, for
> dynamic updates, the update-policy will require Bind to determine the
> identity of the requester, but f
Hi,
I read that Bind9 supports using TKEY for zone transfers. However, I don't
understand how the TKEY negotiation is triggered. In comparison, for
dynamic updates, the update-policy will require Bind to determine the
identity of the requester, but for zone transfer there is only a
allow-transfer
6 matches
Mail list logo
