Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
zone delegation/forwarding in a non-recursive view
904 views
Skip to first unread message
Yiorgos Stamoulis
Oct 25, 2013, 6:46:45 AM10/25/13
to bind-...@lists.isc.org
Hi,
I have authoritative dns system (1 master bind-9.8.2 & 2 slaves
bind-9.8.2 & bind-9.3.6) with several zones and two views.
The internal view allows recursion and the external not.
I now have the requirement to delegate/forward a zone to an external
nameserver.
This works OK for the internal view, but fails for the external as
recursion is not allowed.
Is it possible to do this? how?
Regards
Yiorgos
I have authoritative dns system (1 master bind-9.8.2 & 2 slaves
bind-9.8.2 & bind-9.3.6) with several zones and two views.
The internal view allows recursion and the external not.
I now have the requirement to delegate/forward a zone to an external
nameserver.
This works OK for the internal view, but fails for the external as
recursion is not allowed.
Is it possible to do this? how?
Regards
Yiorgos
Mark Andrews
Oct 25, 2013, 9:21:18 AM10/25/13
to Yiorgos Stamoulis, bind-...@isc.org
In message <526A4C15...@stamoulis.eu>, Yiorgos Stamoulis writes:
> Hi,
>
> I have authoritative dns system (1 master bind-9.8.2 & 2 slaves
> bind-9.8.2 & bind-9.3.6) with several zones and two views.
>
> The internal view allows recursion and the external not.
>
> I now have the requirement to delegate/forward a zone to an external
> nameserver.
>
> This works OK for the internal view, but fails for the external as
> recursion is not allowed.
a referral it is working correctly.
> Is it possible to do this? how?
>
> Regards
>
> Yiorgos
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Kevin Darcy
Oct 25, 2013, 1:04:01 PM10/25/13
to bind-...@lists.isc.org
Although you lump them together, forwarding and delegation are very
different things.
Forwarding is a way to bypass the normal resolution mechanism, forcing
your resolver to essentially "daisy-chain" recursion on behalf of a
requesting recursive client. Another way to put it, is that you're
dumbing down your nameserver to the level of a PC or embedded device
that only knows to send recursive queries to a predefined list of
upstream resolvers. In fact, forwarding in BIND is in a sense even
_dumber_ than recursive resolution in a PC or embedded device, because
those device types can usually get a list of recursive resolvers
*dynamically* (via DHCP options), whereas in BIND one configures
forwarders *statically*.
Delegation, on the other hand, is the way the whole namespace hierarchy
is joined together. If you delegate a subzone, you allow iterative (=
non-recursive) resolvers to follow the namespace hierarchy down into
another branch of the tree. One branch links to another branch, and so
on. That's how the whole tree is formed, all of the way from the root
down to the "leaf" nodes.
So, what is the real requirement here? To create or link in a new branch
of the tree? Or merely to enlarge the set of clients which are allowed
to use your nameserver instance in a recursive manner? The answers to
those questions will determine whether forwarding or delegation is the
appropriate solution.
- Kevin
On 10/25/2013 6:46 AM, Yiorgos Stamoulis wrote:
> Hi,
>
> I have authoritative dns system (1 master bind-9.8.2 & 2 slaves
> bind-9.8.2 & bind-9.3.6) with several zones and two views.
>
> The internal view allows recursion and the external not.
>
> I now have the requirement to delegate/forward a zone to an external
> nameserver.
>
> This works OK for the internal view, but fails for the external as
> recursion is not allowed.
>
different things.
Forwarding is a way to bypass the normal resolution mechanism, forcing
your resolver to essentially "daisy-chain" recursion on behalf of a
requesting recursive client. Another way to put it, is that you're
dumbing down your nameserver to the level of a PC or embedded device
that only knows to send recursive queries to a predefined list of
upstream resolvers. In fact, forwarding in BIND is in a sense even
_dumber_ than recursive resolution in a PC or embedded device, because
those device types can usually get a list of recursive resolvers
*dynamically* (via DHCP options), whereas in BIND one configures
forwarders *statically*.
Delegation, on the other hand, is the way the whole namespace hierarchy
is joined together. If you delegate a subzone, you allow iterative (=
non-recursive) resolvers to follow the namespace hierarchy down into
another branch of the tree. One branch links to another branch, and so
on. That's how the whole tree is formed, all of the way from the root
down to the "leaf" nodes.
So, what is the real requirement here? To create or link in a new branch
of the tree? Or merely to enlarge the set of clients which are allowed
to use your nameserver instance in a recursive manner? The answers to
those questions will determine whether forwarding or delegation is the
appropriate solution.
- Kevin
On 10/25/2013 6:46 AM, Yiorgos Stamoulis wrote:
> Hi,
>
> I have authoritative dns system (1 master bind-9.8.2 & 2 slaves
> bind-9.8.2 & bind-9.3.6) with several zones and two views.
>
> The internal view allows recursion and the external not.
>
> I now have the requirement to delegate/forward a zone to an external
> nameserver.
>
> This works OK for the internal view, but fails for the external as
> recursion is not allowed.
>
Barry Margolin
Oct 25, 2013, 2:34:20 PM10/25/13
to comp-protoc...@isc.org
In article <mailman.1563.1382698...@lists.isc.org>,
Forwarding is a modification of recursion -- it tells the server
"Instead of querying the servers in the NS records, query these specific
servers." But if you're not recursing (either because recursion is
disabled, or because the client didn't request it), you won't forward.
Authoritative servers usually don't get requests with the Recursion
Desired flag -- external caching servers usually do iterative queries. I
don't understand why this is a problem for you, though. You said you're
delegating to an external nameserver, so when you return the referral
they should be able to go there by themselves.
--
Barry Margolin
Arlington, MA
"Instead of querying the servers in the NS records, query these specific
servers." But if you're not recursing (either because recursion is
disabled, or because the client didn't request it), you won't forward.
Authoritative servers usually don't get requests with the Recursion
Desired flag -- external caching servers usually do iterative queries. I
don't understand why this is a problem for you, though. You said you're
delegating to an external nameserver, so when you return the referral
they should be able to go there by themselves.
--
Barry Margolin
Arlington, MA
Yiorgos Stamoulis
Oct 26, 2013, 8:24:27 AM10/26/13
to bind-...@lists.isc.org
Hi Kevin, Mark & Kevin,
thank you for your questions that pointed me to the right track.
A quick summary:
I did my testing in a dev server (let's say with IP address 123.123.123.10) , that is serving the same zones as the live server. I added to the zone file, lets call it example.com, the following:
$ORIGIN subdn
@ IN NS ns
ns IN A 123.123.123.20
the server at running at 123.123.123.20 was configured to as authoritative for zone subdn.example.com.
From a client in the internal view:
dig xxx.subdn.example.com @123.123.123.10
dig xxx.subdn.example.com @123.123.123.20
would work OK
From a client in the external view:
dig xxx.subdn.example.com @123.123.123.10
would fail with 'recursion requested but not available'.
I was testing with dig @123.123.123.10 as it is a dev server not advertised as handling example.com in the dns hierarchy proper.
After applying the same settings on the live servers dig A xxx.subdn.example.com +trace shows delegation now works OK, and after allowing negative caches to expire host xxx.subdn.example.com also gives the right answer.
Lessons learned:
Y
thank you for your questions that pointed me to the right track.
A quick summary:
I did my testing in a dev server (let's say with IP address 123.123.123.10) , that is serving the same zones as the live server. I added to the zone file, lets call it example.com, the following:
$ORIGIN subdn
@ IN NS ns
ns IN A 123.123.123.20
the server at running at 123.123.123.20 was configured to as authoritative for zone subdn.example.com.
From a client in the internal view:
dig xxx.subdn.example.com @123.123.123.10
dig xxx.subdn.example.com @123.123.123.20
would work OK
From a client in the external view:
dig xxx.subdn.example.com @123.123.123.10
would fail with 'recursion requested but not available'.
I was testing with dig @123.123.123.10 as it is a dev server not advertised as handling example.com in the dns hierarchy proper.
After applying the same settings on the live servers dig A xxx.subdn.example.com +trace shows delegation now works OK, and after allowing negative caches to expire host xxx.subdn.example.com also gives the right answer.
Lessons learned:
- If you are going to have a dev server,
have a dev domain too (and not a shadow of the live
domain), with working delegation from the root servers
down, and do not try to cut corners with dig @dev-server
- In dev servers, use really short TTLs!
- delegation & forwarding are VERY
different and you should be very clear to which one is
ppropriate. A workaround is NOT a solution.
Y
0 new messages