authorative-only and NS delegation conflict?
Kevin Darcy
kcd at daimlerchrysler.com
Thu Oct 19 22:23:06 UTC 2006
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
>
>
>
>
>
>
>
>
>
More information about the bind-users
mailing list