?'s about forwarders
Kevin Darcy
kcd at daimlerchrysler.com
Sat Sep 16 03:02:08 UTC 2000
beetle bailey wrote:
> Sorry, I had a feeling this wasn't going to make the jump from my head to
> anyone else's. I'm still kind of new so I guess I tend to toss technical
> terms around somewhat carelessly.
>
> domain.com has 2 subdomains: corp.domain.com and sales.domain.com.
> ins1.domain.com and ins2.domain.com are authoritative for domain.com and are
> queried and available to internal hosts. ns1.domain.com and ns2.domain.com
> are authoritative for domain.com, corp.domain.com and sales.domain.com but
> have different info available for hosts external to domain.com. ins1 and
> ins2 are slaves for the subdomains corp and sales. they also have the line:
> forwarders {
> ns1.domain.com;
> ns2.domain.com;
> };
> forward only;
> in their named.conf files (with ipadds instead of names). I was told the
> reason behind that is so ns1 and ns2 are the only nameservers with any
> direct interaction with the internet.
Okay, that's a fairly typical split-DNS-with-forwarding setup...
> Sales.domain.com and corp.domain.com
> have their own nameservers which are masters for those domains.
> corp.domain.com is a master for it's domain and a slave for none. It also
> supposedly has a similar line about forwarding in it's named.conf file but
> points to ins1 and ins2.
> They were having problems sending mail to
> sales.domain.com and digging at their servers and ins1 and ins2 showed them
> somehow getting mx records for sales.domain.com from ns1. I just noticed
> that the server we have listed as a master for sales.domain.com in our
> named.conf file responds with the authoritative bit not set and the "db"
> file it gets dumped to when we do a zone transfer hasn't been updated for
> over a week (the ttl is 1 day). I assume that's the problem?
Seems to be. You have your expiry interval set to a week. So those zones have
probably expired *everywhere*. None of the answers from ins1 or ins2 have the
AA bit set, so this is consistent with that speculation. You could check the
logs also for "expired" messages.
> If we have a
> server listed in named.conf as a master but it does not advertise itself as
> such would our queries then be forwarded to ns1 and ns2? If that is the
> case, why does ins1 respond to a dig for mx records on sales.domain.com
> differently than ins2? (Please ignore the discrepencies in the number of
> answers, i tried to simplify.) I hope this is easier to understand, and
> thanks a lot for the help.
I'm not sure why the MX answers differ. Have zone transfers been broken
*close* to a week exactly? Maybe ins1 has only just *recently* gone
non-authoritative for the zone? ins2 may have gone non-authoritative a little
earlier, expired its cache entry and already replaced it with the
(wrong) MX from the forwarder. Eventually, though, I think they'll both end up
responding the same way. The root problem seems to be on the master for the
zone. Typically a syntax error in the zonefile causes a master to respond
non-authoritatively, which then breaks zone transfers and causes these kinds of
ripple effects. You might want to raise your expiry values a little, so that
you have time to discover problems like this before things turn completely to
crap.
- Kevin
>
>
> Here's what a dig of the soa record of sales.domain.com on ins2 states:
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> ;; QUERY SECTION:
> ;; sales.domain.com, type = SOA, class = IN
>
> ;; ANSWER SECTION:
> sales.domain.com. 13h27m28s IN SOA ns1.domain.com.
> root.sales.domain.com (
> 57 ; serial
> 3H ; refresh
> 1H ; retry
> 1W ; expiry
> 1D ) ; minimum
>
> and here's the mx record dug from the same host:
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4
> ;; QUERY SECTION:
> ;; sales.domain.com, type = MX, class = IN
>
> ;; ANSWER SECTION:
> sales.domain.com. 13h32m8s IN MX 100 mail1.domain.com.
> sales.domain.com. 13h32m8s IN MX 110 mail2.domain.com.
>
> here's a dig for soa record at ins1:
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> ;; QUERY SECTION:
> ;; sales.domain.com, type = SOA, class = IN
>
> ;; ANSWER SECTION:
> sales.domain.com. 22h21m48s IN SOA ns1.domain.com.
> root.sales.domain.com(
> 57 ; serial
> 3H ; refresh
> 1H ; retry
> 1W ; expiry
> 1D ) ; minimum
>
> and here's the mx record from ins1:
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 5
> ;; QUERY SECTION:
> ;; sales.domain.com, type = MX, class = IN
>
> ;; ANSWER SECTION:
> sales.domain.com. 1D IN MX 110 mail3.sales.domain.com.
> sales.domain.com. 1D IN MX 115 mail4.sales.domain.com.
>
> here is a dig for mx records at ns1.domain.com:
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 6
> ;; QUERY SECTION:
> ;; sales.domain.com, type = MX, class = IN
>
> ;; ANSWER SECTION:
> sales.domain.com. 1D IN MX 110 mail2.domain.com.
> sales.domain.com. 1D IN MX 100 mail1.domain.com.
>
> >From: Kevin Darcy <kcd at daimlerchrysler.com>
> >To: bind-users at isc.org
> >Subject: Re: ?'s about forwarders
> >Date: Fri, 15 Sep 2000 21:02:33 -0400
> >
> >
> >Sorry, I've read that several times and I still don't understand it. When
> >you
> >say "forwarding", or "forward-only", you're talking about the *global*
> >setting,
> >right? Because it doesn't make sense to say that you are a slave, and that
> >you
> >forward, for the same zone. Also, what do you mean when you say a forwarder
> >is
> >being given as the SOA record? SOA records are composed of multiple values,
> >only 2 of which are names. Do you mean the SOA.MNAME is set to the
> >forwarder? Without knowing the exact relationship of your forwarder to your
> >internal or external namespace, I have no idea what that signifies (other
> >than
> >the fact, that you pointed out, that it differs from what is in your "db"
> >file).
> >
> >If you're a slave, and ZONE TRANSFERS ARE SUCCEEDING, then your answers for
> >the
> >zone, BUT NOT NECESSARILY SUBZONES, should correspond to what's in your
> >(replicated) zone file. So if there are discrepancies, the usual causes
> >would
> >be:
> >
> >1) zone transfers aren't succeeding (which could result in expiration of
> >the
> >zone)
> >
> >2) the discrepancies aren't in the zone you think they are, they're in some
> >other zone, e.g. a subzone
> >
> >That's a couple of things to check, at least. In lieu of real server and
> >domain
> >names, could you at least use symbolic names, e.g. Zone A on Server #1?
> >
> >As for "chaining" forwarders, it's just bad practice. You're building a
> >fragile
> >house of cards. And think of the latency delays you're introducing with
> >that
> >conga-line of nameservers passing the query and response packets back and
> >forth. Forwarding is bad enough with even just *one* hop. When you chain
> >forwarders, you make it a monstrosity.
> >
> >
> >- Kevin
> >
> >beetle bailey wrote:
> >
> > > First I'd like to apologize for not providing any specifics, but this is
> >all
> > > info that's only available internally so I'm afraid it wouldn't help
> >anyway.
> > > I hope it's not too confusing.
> > >
> > > Is there any reason a forward-only nameserver won't respond to a query
> >for a
> > > zone that it is a slave for with info from one of it's db files? We
> >have 2
> > > servers, both forward-only and both slaves for this particular domain
> >but
> > > they give out different mx records. Also, they both give out the same
> >soa
> > > record which is not the master of the zone listed in their named.conf
> >files
> > > but rather the first forwarder listed there. One server gives out the
> >mx
> > > records listed in the db file that should have come from the master for
> >the
> > > zone and the other gives out the mx records from the forwarder (which
> >are
> > > the mail servers available to the rest of the internet but not our
> >internal
> > > network -- hence the initial problem). I would have thought the soa
> >record
> > > for the zone we're a slave for would come from the db file listed in
> > > named.conf but it seems to come from the forwarder even though mx
> >records
> > > seem to come on one server from the local db file and the other from the
> > > forwarder. Can someone explain why that is? On top of this, it turns
> >out
> > > the administrator that called me (who belongs to another subdomain that
> > > controls their own nameservers) with the initial report of undeliverable
> > > mail is forwarding all requests other than their own domain to our
> >servers
> > > which are slaves for all of the internal domains but are also set up as
> > > forwarders themselves. DNS & BIND cautions against this, though I have
> >to
> > > admit I don't understand why. I'd appreciate whatever info you can
> >give
> > > me. Thanks.
> > >
> >_________________________________________________________________________
> > > Get Your Private, Free E-mail from MSN Hotmail at
> >http://www.hotmail.com.
> > >
> > > Share information about yourself, create your own public profile at
> > > http://profiles.msn.com.
> >
> >
> >
> >
> >
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
More information about the bind-users
mailing list