using slave NS in glue records
Kevin Darcy
kcd at daimlerchrysler.com
Wed Dec 11 23:28:32 UTC 2002
If you delegate your internal subdomains of cadence.com from the
internal cadence.com zone, then all of your internal nameservers should
be able to resolve names in those subzones without any special
forwarding arrangements. What am I missing? Why are you asserting that
you have to *force* the queries to go the respective internal
nameservers? It all happens automatically if your delegation tree is
properly set up and forwarding doesn't get in the way (see my note about
"forwarding cancellation" below).
Now, if you don't like those delegations to appear in the *external*
version of cadence.com, then you're pretty much stuck doing "split" DNS,
where you maintain different versions of the same zone(s) -- the
internal version of cadence.com would contain delegations for its
subzones, but the external version would not. Using the "view"
mechanism, you should be able to host both versions of the zone(s)
within the same nameserver instance, and might even be able to share an
$INCLUDE file containing common entries between the zone files in the
respective views.
If you really want to *force* your internal nameservers to use
particular nameservers to resolve particular names, you can do this via
global forwarding (in the options statement), or zones of "type
forward". But unless you're trying to get around some sort of networking
or firewall restrictions, I would very much question the utility of
forwarding at all -- it often doesn't reap the performance benefits that
you might expect it to. Note also that if you want to *cancel*
forwarding for a particular part of your namespace, e.g. so that your
internal nameservers can follow your internal delegations properly, then
you need to define the top-level of each relevant branch of your
namespace as a zone of type "slave" or "stub" and then specify
"forwarders { };" in the zone definition to cancel the forwarding.
- Kevin
Gregory Hicks wrote:
>>Date: Tue, 10 Dec 2002 10:22:36 -0500
>>From: Kevin Darcy <kcd at daimlerchrysler.com>
>>
>>Perhaps it would help if you explained what you're trying to accomplish. It
>>looks like you're trying to use zone NS records and/or the contents of the
>>hints file as a general-purpose forwarding or "override
>>forwarding" mechanism. That's doomed to failure. The hints file should only
>>contain information about the root zone, and an authoritative server for a
>>zone will never "forward" queries anywhere else, regardless of what the
>>zone NS records say.
>>
>>
>>- Kevin
>>
>>
>
>1. What am I trying to accomplish?
>
>I am trying to have a 'mini-root' server in our DMZ that can/will get
>request forwarded to it that will 'tie' our various internal subdomains
>together.
>
>We currently have one internal master: iss; with three 'published'
>slave servers: cds2, cds238, and granola.
>
>We have another 'global' Win2K domain that in running the MS active
>directory services (aka global.cadence.com).
>
>We have a 'stealth' master in our DMZ that has only NS records that is
>currently pointed to by the Win2K services only.
>
>I would like the machine iss to have authoritative info on all internal
>hosts with gossip only having info on the nameservers...
>
>I am trying to find a way to have gossip have only pointers to the
>various subdomains such that it will forward queries correctly to th
>various subdomains. My machine metis is set up as I would like to have
>gossip set up, but it does not resolve ANYTHING other than the
>nameservers for cadence.com and hosts outside of cadence.com...
>
>2. The 'hacked' db.cache (hints db...)
>
>The idea was to force all requests for DNS info to go to our external
>name server and have it resolve anything other than .cadence.com.
>Thus, all internal slaves would point to ns.cadence.com instead of
>pointing to the root servers... Unfortunately, as pointed out already,
>this does not work since BIND figures out, on its own, where the REAL
>root servers are located... However, ...
>
>Any ideas? Any thoughts, ideas, attempts to point me in the right
>direction will be appreciated.
>
>Regards,
>Gregory Hicks
>
>
>
>
>>Gregory Hicks wrote:
>>
>>
>>
>>>>Date: Wed, 04 Dec 2002 01:01:53 +0100
>>>>From: Eivind Olsen <eivind at aminor.no>
>>>>
>>>>Are you thinking about having a hidden master server, like this?
>>>>
>>>>Hidden master server (master.example.com)
>>>>====================
>>>>|
>>>>|
>>>>+--------slave1 (ns1.example.com)
>>>>|
>>>>|
>>>>+--------slave2 (ns2.example.com)
>>>>
>>>>
>>>>
>>>I am obviously doing something wrong...
>>>
>>>our 'internet' name server is working. Our internal name servers
>>>work. However, I am trying to set up one of these 'hidden master
>>>servers' by listing all of the 'internal name servers in the
>>>db.cadence.ns and using that as the zone master...
>>>
>>>However, it would appear that I cannot get it to look anywhere else...
>>>How to do this?
>>>
>>>Regards,
>>>Gregory Hicks
>>>-----------db.cadence.ns -----------
>>>$ORIGIN Cadence.COM.
>>>@ IN SOA metis.Cadence.COM. root.metis.Cadence.COM. (
>>> 2002120914 3600 900 604800 3600 )
>>>
>>> 1H IN NS iss.cadence.com.
>>> 1H IN NS cds2.cadence.com.
>>> 1H IN NS cds238.cadence.com.
>>> 1H IN NS granola.cadence.com.
>>>
>>>dr 1H IN NS dc1sjroot.cadence.com.
>>> 1H IN NS dc2sjroot.cadence.com.
>>>
>>>catena 1H IN NS cat0.catena.cadence.com.
>>>
>>>engineering 1H IN NS bsd6.cadence.com.
>>> 1H IN NS bsd21.cadence.com.
>>>
>>>global 1H IN NS dc1sjglobal.cadence.com.
>>> 1H IN NS dc2sjglobal.cadence.com.
>>>
>>>_msdcs.global 1H IN NS dc1sjglobal.cadence.com.
>>> 1H IN NS dc2sjglobal.cadence.com.
>>>
>>>_tcp.global 1H IN NS dc1sjglobal.cadence.com.
>>> 1H IN NS dc2sjglobal.cadence.com.
>>>
>>>_udp.global 1H IN NS dc1sjglobal.cadence.com.
>>> 1H IN NS dc2sjglobal.cadence.com.
>>>
>>>_sites.global 1H IN NS dc1sjglobal.cadence.com.
>>> 1H IN NS dc2sjglobal.cadence.com.
>>>
>>>bsd21 IN A 158.140.5.139
>>>bsd6 IN A 158.140.90.6
>>>cat0.catena IN A 158.140.133.37
>>>cds2 IN A 158.140.32.75
>>>cds238 IN A 158.140.128.1
>>>dc1sjglobal IN A 158.140.128.140
>>>dc1sjroot IN A 158.140.128.40
>>>dc2sjglobal IN A 158.140.128.141
>>>dc2sjroot IN A 158.140.128.41
>>>granola IN A 158.140.128.35
>>>iss IN A 158.140.32.1
>>>metis IN A 158.140.48.93
>>>
>>>--------/etc/named.conf --------------------
>>>options {
>>> directory "/var/yp/nameserver";
>>> //
>>> //the db.cache file below references only ns.cadence.com.
>>> //because of the firewall, it does not talk directly with
>>> //the root servers of the internet
>>> //
>>> //
>>> //the forwarder for ns.cadence.com, below is no typo. it is
>>> //mentioned twice to change the behavior of bind. see p. 143
>>> //of the first ed of _dns & bind_
>>> //
>>> forwarders {
>>> 158.140.128.140;
>>> 158.140.32.1;
>>> };
>>> //
>>> //the slave keyword causes dns to only do recursive queries.
>>> //
>>>
>>>};
>>>
>>>key "rndc-key" {
>>> algorithm hmac-md5;
>>> secret "secret-password";
>>>};
>>>
>>>controls {
>>> inet 127.0.0.1 port 953
>>> allow { 127.0.0.1; } keys { "rndc-key"; };
>>>};
>>>
>>>zone "0.0.127.in-addr.arpa" in {
>>> type master;
>>> file "db.127.0.0";
>>> notify no;
>>>};
>>>
>>> zone "Cadence.COM" in {
>>> type master;
>>> file "db.Cadence.ns";
>>># masters { 158.140.128.1; };
>>>};
>>>
>>> zone "99.139.in-addr.arpa" in {
>>> type slave;
>>> file "db.139.99";
>>> masters { 158.140.128.1; };
>>>};
>>>
>>> zone "140.158.in-addr.arpa" in {
>>> type slave;
>>> file "db.158.140";
>>> masters { 158.140.128.1; };
>>>};
>>>
>>> zone "." in {
>>> type hint;
>>> file "db.cache";
>>>};
>>>---------- end of /etc/named.conf ----------------
>>>
>>>---------- db.cache ------------------------------
>>>; This is a hacked version of the db.cache to fake cds238 into believing
>>>; that all requests should go through the firewall. If you replace this
>>>; with the db.cache from Internic, it won't work as expected.
>>>;
>>>; grif 9/15/97
>>>;
>>>
>>>.. 3600000 IN NS ns.cadence.com.
>>>.. 3600000 IN NS gossip.cadence.com
>>>ns.cadence.com. 3600000 IN A 158.140.1.253
>>>gossip.cadence.com. 3600000 IN A 158.140.2.50
>>>---------- end of db.cache -----------------------
>>>
>>>
>>>
>
>-------------------------------------------------------------------
>Gregory Hicks | Principal Systems Engineer
>Cadence Design Systems | Direct: 408.576.3609
>555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400
>San Jose, CA 95134 | Internet: ghicks at cadence.com
>
>"The trouble with doing anything right the first time is that nobody
>appreciates how difficult it was."
>
>When a team of dedicated individuals makes a commitment to act as
>one... the sky's the limit.
>
>"There is no limit to what a man can do or how far he can go if he
>doesn't mind who gets the credit." - Robert Woodruff
>
>
>
>
>
More information about the bind-users
mailing list