telnet App not recursive
Quadri, Jay
Jay.Quadri at gmk.cwplc.com
Fri Sep 8 11:59:54 UTC 2000
It worked like a dream, I just needed to add forwarders { }; to the zone
file as Kevin suggested. I can't believe it. Kev we should be nominated
for an Oscar in Bindwood. You're star mate.
-----Original Message-----
From: Quadri, Jay
Sent: Friday, September 08, 2000 10:01 AM
To: 'Kevin Darcy'
Cc: bind-users at isc.org
Subject: RE: telnet App not recursive
I have used intra.net in the file I sent you for security reasons, I also
changed the IP's and names, by the way my girlfriend is called Annika,
(using find & replace), I also changed a few things without deviating from
the basic concept of what I am trying to achieve.
I need to use forwarders for another internal DNS server (I don't
administrate this old box), this box contains lots of zones, I'll take me
ages to configure my NS to act as secondary to it, don't even know all the
zones one it, some clients need to resolve names on this old box, eventually
(phahaps next year), I will get ride of this old box. I need it now though.
I also must use forwarders to reach the Net. So you See I need to forward
to 2 differ machines, one to the Internal old DNS box (on a differ site) and
the other one is the Internet DNS.
Could you point me to any document that talks about the forwarders { } you
mentioned.
-----Original Message-----
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
Sent: Thursday, September 07, 2000 11:46 PM
To: bind-users at isc.org
Subject: Re: telnet App not recursive
Quadri, Jay wrote:
> I do have a design (below) of which I am very proud off, the only problem
> is that it does not work correctly. It works perfectly if I remove the
> forwarders.
Do you need them? I assume the reason you put them there is because of a
requirement to be able to resolve Internet names internally.
> Leaving just the Internet forwarder results in annika not been
> able to resolve other intra.net sites within the cloud.
This would make sense if there were other zones under "intra.net" besides
"annika.intra.net", since then queries in those zones would be sent to the
Internet forwarder. Note that you can "cancel" forwarding for part of a
namespace hierarchy by specifying "forwarders { }" in the zone statement of
the
apex zone. I.e. if you specified "forwarders { }" in the "intra.net" zone
statement, then forwarding would be turned off for *everything* under
"intra.net". "forwarders { }" can be specified for a master, a slave or even
a
stub zone -- you could convert your "intra.net" slave definition into a stub
zone, if you wanted to reduce zone transfer overhead (don't do this if you
are
a registered slave, however, since stub zones are not authoritative, and
don't
do it if you need the redundancy of having a replicated copy of the zone),
and
you'd still be able to specify "forwarders { }" in the zone definition.
By the way, "intra.net" seems to be a poor choice for a private domain,
since
there is already an "intra.net" defined on the Internet. What if you want to
send mail or otherwise communicate with the *real* "intra.net" someday? I
think
your servers may be a little confused by that. Perhaps the bogus
TLD ".intranet" would have been a better choice...
> Forwarding is a
> bitch, it affects other Internal lookups.
Yes, forwarding is generally to be avoided. But, if you need to look up
Internet names and don't have direct connectivity to Internet nameservers,
forwarding through some other nameserver with better connectivity is really
the
only way to make things work.
I will reiterate, however, that you should *not* mix internal and external
nameservers in your forwarders list. And the only reasonable application of
"forward first" is for *optimization* (i.e. using a central cache). When
using
forwarding to deal with a connectivity issue, "forward only" is the only
kind
of forwarding which makes sense. Otherwise, intermittent failures trying to
talk to the forwarder(s) may cause your nameserver to return totally
*different* answers for the same query at different times, because some of
the
time it'll be talking recursively to an external server or servers, and
other
times it'll be talking iteratively to internal servers. With "forward only",
at
least a communication failure will be reported correctly back to the
client/application, so that it can take appropriate measures, e.g. queue up
and
retry. Which is a whole lot better than sending back false information from
your internal root, e.g. amazon.com doesn't exist.
- Kevin
> The root server (intra.net) acts
> as a slave to all *.intra.net servers and vice visa,I can see that all
slave
> zone files does get transferred on all DNS servers. Any insights?
>
> [root at Annika /root]# more /etc/named.conf
> options {
> directory "/var/named";
> // query-source address * port 53;
> notify YES ;
> forwarders {
> 195.44.11.45 ;
> 148.185.41.13 ;
> //195.44.11.45 is the internet dns
> //142.186.43.18 is another intranet dns server (zone=isops.co.uk)
>
> } ;
> forward first ;
> maintain-ixfr-base yes ;
> };
>
> zone "annika.intra.net" {
> type master ;
> file "annika.intra.net.db" ;
> notify YES ;
> allow-update {
> none ;
> } ;
> maintain-ixfr-base yes ;
>
> } ;
> zone "intra.net" {
> type slave ;
> file "intra.net.db" ;
> masters {
> 10.50.1.5;
> } ;
> } ;
>
> zone "118.135.142.in-addr.arpa" {
> type master ;
> file "118.135.142.in-addr.arpa.db" ;
> notify YES ;
> allow-update {
> none ;
> } ;
> maintain-ixfr-base yes ;
>
> } ;
> // a caching only nameserver config
> //
> zone "." {
> type hint;
> file "named.ca";
> };
>
> zone "0.0.127.in-addr.arpa" {
> type master;
> file "127.0.0.rev.db";
> };
> [root at Annika named]# more 118.135.142.in-addr.arpa.db
> @ IN SOA annika.intra.net. hostmaster.intra.net. (
> 5 ; serial
> 10800 ; refresh
> 3600 ; retry
> 604800 ; expire
> 86400 ) ; minimum
>
> IN NS annika.intra.net.
>
> 221 IN PTR annika.intra.net.
> [root at Annika named]# more 127.0.0.rev.db
> @ IN SOA annika.intra.net. hostmaster.intra.net. (
> 4 ; serial
> 10800 ; refresh
> 3600 ; retry
> 604800 ; expire
> 86400 ) ; minimum
>
> IN NS annika.intra.net.
>
> 1 IN PTR annika.intra.net.
>
> [root at Annika named]# more named.ca
> . 999999 IN NS intra.net.
> intra.net. 999999 IN A 10.50bind-users at isc.org
>
> more annika.intra.net.db
> @ IN SOA annika.intra.net. hostmaster.annika.intra.net.
(
> 9 ; serial
> 10800 ; refresh
> 3600 ; retry
> 604800 ; expire
> 86400 ) ; minimum
>
> IN NS annika.intra.net.
>
> annika.intra.net. IN A 142.135.118.221
> hosts IN A 142.135.118.222
>
> laptop IN CNAME annika.intra.net.
>
> www IN CNAME annika.intra.net.
>
> -- Binary/unsupported file stripped by Listar --
> -- Type: application/octet-stream
> -- File: dns-send.htm
>
> -- Binary/unsupported file stripped by Listar --
> -- Type: image/gif
> -- File: dns-send.gif
More information about the bind-users
mailing list