Forwarding updates between views

[Chris Hills]

Hi

I have a zone "example.com" configured in two views, internal-in and
external-in. I have a dynamic zone "dyn.example.com" configured only as
an external zone. Internal clients can lookup hosts in dyn.example.com,
but cannot update ("not authorised") as the updates are matched by the
zone internal-in and not forwarded. Is it possible for bind to forward
the updates from the internal-in zone to the external-in zone? I want to
avoid having to have 2 dynamic zones (faq node/291) for simplicity of
configuration.

The configuration is like so (note local-networks does /not/ include ::1
to allow recursive queries from internal-in to external-in):-

view "internal-in" IN {
match-clients { local-networks; };
allow-recursion { local-networks; };
forwarders { ::1; };

zone "example.com." {
type master;
file "master/example.com.internal.zone";
};
zone "dyn.example.com." {
type forward;
forward only;
forwarders { ::1; };
};
};

view "external-in" IN {
match-clients { any; };

zone "example.com." {
type master;
file "master/example.com.zone";
};
zone "dyn.example.com." {
type master;
file "master/dyn.example.com.zone";
allow-update { local-networks; };
};
};

Regards,

Chris

[Chris Buxton]

On Nov 22, 2009, at 1:49 AM, Chris Hills wrote:
> Hi
>
> I have a zone "example.com" configured in two views, internal-in and external-in. I have a dynamic zone "dyn.example.com" configured only as an external zone. Internal clients can lookup hosts in dyn.example.com, but cannot update ("not authorised") as the updates are matched by the zone internal-in and not forwarded. Is it possible for bind to forward the updates from the internal-in zone to the external-in zone? I want to avoid having to have 2 dynamic zones (faq node/291) for simplicity of configuration.
>
> The configuration is like so (note local-networks does /not/ include ::1 to allow recursive queries from internal-in to external-in):-
>
> view "internal-in" IN {
> match-clients { local-networks; };
> allow-recursion { local-networks; };
> forwarders { ::1; };
>
> zone "example.com." {
> type master;
> file "master/example.com.internal.zone";
> };
> zone "dyn.example.com." {
> type forward;
> forward only;
> forwarders { ::1; };
> };
> };

Change the zone from type forward to type slave, and add allow-update-forwarding.

zone "dyn.example.com." {
type slave;
masters { ::1; };
allow-update-forwarding { local-networks; };
};

Then in the external-in view, change allow-update to:

allow-update { ::1; };

Chris Buxton
Professional Services
Men & Mice

[Chris Hills]

On 22/11/09 21:01, Chris Buxton wrote:
> Change the zone from type forward to type slave, and add allow-update-forwarding.
>
> zone "dyn.example.com." {
> type slave;
> masters { ::1; };
> allow-update-forwarding { local-networks; };
> };
>
> Then in the external-in view, change allow-update to:
>
> allow-update { ::1; };

Great, works like a charm... but... the update log only records ::1 as
the source and not the original address. Is it possible to keep that?

[Chris Buxton]

The internal-in view should have some log entry of the forwarded update. I'm not sure what category or severity level that would be, though.

Of course, if you were to start using signed updates (either TSIG or GSS-TSIG), you would know what key was used.

[Chris Hills]

On 23/11/09 18:05, Chris Buxton wrote:
> The internal-in view should have some log entry of the forwarded update. I'm not sure what category or severity level that would be, though.

I could not find it in either the query log or the update log. Bug?

> Of course, if you were to start using signed updates (either TSIG or GSS-TSIG), you would know what key was used.

The purpose is to provide a free ipv6-only playground that anyone may
use. Normal updates from external clients are logged as intended. Feel
free to add, modify or remove records under dyn.ipv6.chaz6.com. When
security is required I do of course use keys!