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