telnet App not recursive

[Quadri, Jay]

It now definitely work using selective forwarders, it's a pain to have to do
this because it requires me to start investigating what the zone names are
on these old boxes, and believe me there are plenty of them, and don't even
know who administrates what, but it shouldn't be too difficult a task
considering.  Thanks again, glad to get to the bottom of it finally.

Would you agree if I said that using the master/slave/stub with the
"forwarders { }" syntax is more efficient than using the "zones of type
"forward""  since the later gets cached.


-----Original Message-----
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
Sent: Friday, September 08, 2000 8:18 PM
To: 'bind-users at isc.org'
Subject: Re: telnet App not recursive



Quadri, Jay wrote:

> Sorry, Please ignore the last mail I sent about being nominated for an
> Oscar, the bastard still doesn't work properly.  I can resolve everything
> but the Internet.  I'll never use nslookup to test again, and if I ever do
> I'll do it more than ones using differ names to test.
>
>  The second IP (Internet) in the forwarder is not being tried for a second
> opinion that's why it's not working.

Exactly. That's what I keep telling you. Multiple forwarders is only for
redundancy, not for "second opinion"s. If you want to resolve Internet names
without having Internet connectivity, your global forwarder(s) need to be
set
to Internet-aware nameservers *only*. Then if you want to forward other
things
to internal servers, you use zones of type "forward". If you'd rather use
iterative resolution instead of forwarding for certain internal domains,
then
set them up as master/slave/stub with the "forwarders { }" syntax.

Sounds like you're trying to do everything you can to avoid generating a
list
of what the "old box" is serving and then adding the appropriate zone
definitions to your machine. And you're trying to circumvent this chore by
defining multiple "default" places to forward. This is a dead end. You can
only
reasonably have one "default" place to forward things (note that I said
"place", not "server"; obviously you could forward to multiple Internet
nameservers, or multiple internal nameservers, but you can't reasonably mix
Internet and internal servers, i.e. servers in different "places").
Everything
which doesn't fall under the default needs to be explicitly specified. So,
either you set your default to the "old box" and explicitly specify every
domain on the Internet (yeah, right!) or you set your default to one or more
Internet servers and explicitly specify all of the domains on that "old box"
(as forward, slave or stub). As I see it, those are your only two options.
Pick
one.


- Kevin

>
>
> -----Original Message-----
> From: Quadri, Jay
> Sent: Friday, September 08, 2000 1:00 PM
> To: 'Kevin Darcy'
> Cc: 'bind-users at isc.org'
> Subject: RE: telnet App not recursive
>
> 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
>