As others have pointed out, "allow-update-forwarding" only works for slaves.
Yet another reason to go with a large-authoritative-core approach,
instead of stringing stuff together with recursive arrangements. Would
you rather build an enterprise-strength DNS infrastructure from fragile
filamen
On 02/10/13 11:31, Mark Andrews wrote:
Also TSIG signatures are preserved when UPDATE requests are forwarded.
TSIG was designed to allow signed messages to be forwarded. The
ID field is not covered by the the TSIG to allow the message to be
forwarded. The slave does NOT have to know the shared
In message
, Bojan Tomic writes:
>
> Thanks Phil!
>
> I've tried "allow-update-forwarding", but my understanding is that this
> option only works for slave servers!? What i'm looking for is dynamic
> update forwarding from non-authoritative server. Can allow-update-forwarding
> also work with
Thanks Phil!
I've tried "allow-update-forwarding", but my understanding is that this
option only works for slave servers!? What i'm looking for is dynamic
update forwarding from non-authoritative server. Can allow-update-forwarding
also work with non-authoritative server? We are building an inte
On 10/02/2013 07:51 AM, Bojan Tomic wrote:
Hi,
I'm looking for a way to setup a recursive/forwarding named server to
forward dynamic updates
See "allow-update-forwarding" in the ARM. Obviously you will lose source
IP / TSIG key info, so will need to perform access checks at the
forwarding se
Hi,
I'm looking for a way to setup a recursive/forwarding named server to
forward dynamic updates. I know this is not something that RFC2136 allows,
but wondering if it can be done or someone else needs this functionality?
Basically, instead of returning NOTAUTH a recursive server (or forwarding)
6 matches
Mail list logo
