authorative-only and NS delegation conflict?

Barry Margolin barmar at alum.mit.edu
Sat Oct 21 06:47:41 UTC 2006


In article <ehc8u0$qqi$1 at sf1.isc.org>, cytroic at moog.netaxs.com wrote:

> Thank you for your answer, Kevin. From what I am understand from your
> explaination, how I am testing the test name server with the new
> configuration (recursion off) is where my problem is.
> 
> Does anyone have any ideas of how I can accuratly test this new
> configuration without hurting our current name server, outside of
> registering a new domain for testing, using the test name server as a
> authorative nameserver, and setting up the domain to test on there?

Use a subdomain of your current domain for testing.  Put 
test.<yourdomain> on the new nameserver, delegate this from your regular 
server, and configure the web sites and load balancers to support the 
name www.test.<yourdomain>.

> 
> On Thu, 19 Oct 2006, Kevin Darcy wrote:
> 
> > Shouldn't be a problem. Any iterative resolver on the Internet, upon
> > receiving the referral from your nameservers, will follow that referral
> > and query the load-balancers directly. This is really no different than
> > following a referral from the root zone to a TLD such as .com, and then
> > from .com to your domain, such as example.com. It's all part of the
> > iterative-resolution algorithm. No special configuration required.
> >
> > - Kevin
> >
> > cytroic at moog.netaxs.com wrote:
> > > I think Ive become a little rusty with my DNS administation over the
> > > last few years. Ive run into a problem and can't figure out a solutions.
> > > My research in the Bind9 mannual and other online resources haven't come
> > > up with anything solid yet. Im sure there are other people out there who
> > > have run into this problem and have found solutions.
> > >
> > > Our authorative nameservers currently allow cacheing and we want to turn
> > > recursion off, thus only handling authorative requests from the intenet.
> > > We are testing this on a test name server before making the change to our
> > > live name servers.
> > >
> > > Testing so far has shown problems caused by our current network
> > > architecture. Our websites are redundant across multiple sites, and we 
> > > use
> > > networking devices which provides load balancing. The networking devices
> > > load balance at each site, but also work together to provide load
> > > balancing between sites. One these methods is determining which site the
> > > customer can get to quicker, and directs the customer to the appropiate
> > > site by sending their local resolver the ip of the website at that site.
> > >
> > > As a result, the dns records of these websites are NS records pointing to
> > > these network devices. Since our authorative name server don't hold the A
> > > record for these websites, queries for these will not work if recursion 
> > > is
> > > turned off.
> > >
> > > I read about the fetch-glue option, but that is obsolete in Bind9, and so
> > > not a solution in this case, let alone that fact that it would be 
> > > pointless
> > > since it seems just as insecure as recurision. I thought of spliting out
> > > the network devicies to subdomains, and setting up forwarder rules for
> > > these subdomains.  I haven't read if this will work with recurrsion
> > > off or not, and it would require a lot of changes on the network devices
> > > as well as on the name servers, and want to use that as a last resort for
> > > now.
> > >
> > > Has anyone enountered this before? If so, were you able to find a safe 
> > > way
> > > around it? I am thinking in the back of my mind that there is a easy
> > > solution to this and Im going to slap myself on the forehead once I find 
> > > a
> > > solution.
> > >
> > > Thanks!
> > >
> > >
> > > Examples of some digs are shown below to help explain the problem I am
> > > trying to get around. I have changed the ips and hostnames for personal
> > > reasons. 111.222.333/24 and 444.555.666/24 are 2 of our sites. .101 are
> > > our authorative name servers, .103 is the test name server, .111 is the
> > > website, and .104 are the network devices.
> > >
> > > Querying the new NS server. Recursion is off, and no answer is given. the
> > > network device addresses are returned.
> > > bash-2.05b$ dig www.mydomain.com @111.222.333.103
> > >
> > > ; <<>> DiG 9.2.3 <<>> www.mydomain.com @111.222.333.103
> > > ;; global options:  printcmd
> > > ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55578
> > > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
> > >
> > > ;; QUESTION SECTION:
> > > ;www.mydomain.com.           IN      A
> > >
> > > ;; AUTHORITY SECTION:
> > > www.mydomain.com.    900     IN      NS      netdev1.mydomain.com.
> > > www.mydomain.com.    900     IN      NS      netdev2.mydomain.com.
> > >
> > > ;; ADDITIONAL SECTION:
> > > netdev1.mydomain.com. 900     IN      A       111.222.333.104
> > > netdev2.mydomain.com. 900     IN      A       444.555.666.104
> > >
> > > ;; Query time: 92 msec
> > > ;; SERVER: 111.222.333.103#53(111.222.333.103)
> > > ;; WHEN: Tue Oct 17 15:25:52 2006
> > > ;; MSG SIZE  rcvd: 111
> > >
> > >
> > > Here I am querying our domain against our live servers via a trace.
> > > recursion is on. notice how final answer is given by the network devices.
> > > dig +trace www.mydomain.com @ns1.netaxs.com | more
> > >
> > >
> > > ; <<>> DiG 9.2.3 <<>> +trace www.mydomain.com @ns1.netaxs.com
> > > ;; global options:  printcmd
> > > .                       425605  IN      NS      D.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      E.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      F.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      G.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      H.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      I.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      J.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      K.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      L.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      M.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      A.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      B.ROOT-SERVERS.NET.
> > > .                       425605  IN      NS      C.ROOT-SERVERS.NET.
> > > ;; Received 436 bytes from 207.106.1.2#53(ns1.netaxs.com) in 244 ms
> > >
> > > com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
> > > com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
> > > ;; Received 497 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 130 ms
> > >
> > > mydomain.com.        172800  IN      NS      ns1.mydomain.com.
> > > mydomain.com.        172800  IN      NS      ns2.mydomain.com.
> > > ;; Received 105 bytes from 192.42.93.30#53(G.GTLD-SERVERS.NET) in 125 ms
> > >
> > > www.mydomain.com.    900     IN      NS      netdev1.mydomain.com.
> > > www.mydomain.com.    900     IN      NS      netdev2.mydomain.com.
> > > ;; Received 111 bytes from 111.222.333.101#53(ns1.mydomain.com) in 72 ms
> > >
> > > www.mydomain.com.    60      IN      A       111.222.333.111
> > > ;; Received 53 bytes from 111.222.333.104#53(netdev1.mydomain.com) in 198
> > > ms
> > >
> > > Here I am querying the domain against one of our live servers again.
> > > recursion is on. notice how final answer is given by the network devices.
> > > dig www.mydomain.com @111.222.333.101
> > >
> > > ; <<>> DiG 9.2.3 <<>> www.mydomain.com @111.222.333.101
> > > ;; global options:  printcmd
> > > ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32222
> > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> > >
> > > ;; QUESTION SECTION:
> > > ;www.mydomain.com.           IN      A
> > >
> > > ;; ANSWER SECTION:
> > > www.mydomain.com.    60      IN      A       111.222.333.111
> > >
> > > ;; AUTHORITY SECTION:
> > > www.mydomain.com.    900     IN      NS      netdev1.mydomain.com.
> > > www.mydomain.com.    900     IN      NS      netdev2.mydomain.com.
> > >
> > > ;; ADDITIONAL SECTION:
> > > netdev1.mydomain.com. 900     IN      A       111.222.333.104
> > > netdev2.mydomain.com. 900     IN      A       444.555.666.104
> > >
> > > ;; Query time: 586 msec
> > > ;; SERVER: 111.222.333.101#53(111.222.333.101)
> > > ;; WHEN: Tue Oct 17 15:31:46 2006
> > > ;; MSG SIZE  rcvd: 127
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***




More information about the bind-users mailing list