telnet App not recursive

[Kevin Darcy]

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
>