telnet App not recursive

[kcd at daimlerchrysler.com]

The names will get cached regardless. Master zones are probably not an option 
for you, since you indicated that the zones are being maintained on the other 
box (right?). For future reference, I was just pointing out that the 
"forwarders { }" can be specified for a master zone, if you want. As for the 
differences between slave/stub/forward zones, here's a little matrix (hope it 
lines up):

                                        Slave     Stub      Forwarding
Fully Redundant & Authoritative?          Y        N            N

Latency hit for names not in memory      N/A(1)  Small(2)   Small/Variable(3)

Replication Impact(4)              Substantial(5) Small(6)     N/A

Authorization Required:

             "allow-transfer"             Y        N            N

             "allow-recursion"(7)         N        N            Y

Change Propagation Time(8)              Fixed   Variable     Variable

TTL values(9)                           Fixed    Eroded       Eroded

Footnotes:
(1) Answers come straight from local server's authoritative data.
(2) Adaptable. With iterative querying, "fastest" nameservers, based on RTT 
    values, are used.
(3) Prior to BIND 8.2.3, "variable", i.e. dependent on speed/reliability
    of forwarders. In BIND 8.2.3, RTT is used for forwarder-selection,
    as it is for iterative querying, so latency should be the same as for 
    stub, i.e. "small".
(4) "Impact" includes network bandwidth usage, disk space, memory footprint 
    and zone-loading time.
(5) Especially for large and/or frequently-changing zones.
(6) Only SOA and NS records for the zone are replicated.
(7) Applies only to names which the forwarder has not cached and for which the 
    forwarder is not authoritative.
(8) How long do changes to DNS records take to propagate to our server? As a 
    slave, I get a NOTIFY and transfer the zone, which normally takes about 
    the same time every time, hence "fixed". If not a slave, then the TTL on 
    the record determines its persistence, which can vary wildly, hence 
    "variable". Variable persistence can be a good thing: if you know a record 
    is about to change, you can lower its TTL, which speeds up change 
    propagation ito forwarders and stubs, as well as ordinary iterative-
    querying nameserves, but not for slaves.
(9) Slaves always give "fixed" TTL's for a given record in a given zone, 
    assuming the record has not changed. Stubs and forwarding servers give 
    eroded TTL's when answering from their caches. This can be important if 
    other servers are using yours as a forwarder: you'd generally want to give 
    "fixed" TTL's in that case, in order to reduce traffic between your server 
    and the downstream ones. But, this will slow down change propagation. Yet 
    again, the eternal tradeoff between the benefits of caching and its effect 
    on change propagation....

							- Kevin

Quadri, Jay wrote:

> 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
> >
> 
> 
> 
> 
> 
> 
>