Glynn pretty much covered everything. There is one thing though - you are saying you added pcm.com to your named.conf as a slave zone. This is wrong - because if you create a slave zone, you then need to define a master where it will transfer the zone across from and place it on your system in the zone file you specify. You cant directly edit zones on a slave because by definition the slave zone is a copy of the zone from the master. You need to create a master zone and copy across any records such as www etc you need from it into your local zone file (which for your server is a master because its the only one that matters to your organization) and then you need to add all your local machines to it. If you have a $ORIGIN defined as pcm.com (default is the name of the zone/domain) then any hostname that does not end with a . will have this appended to it. You should avoid using the . as it will make your file less cluttered and easier to rename the zone if you ever need to. Once that is done and you have the forward lookup file ready, you can use a script to generate the reverse zones if you like. I prefer using proper reverse zones whenever possible as many applications do a hostname lookup on an IP when accepting connections and in a scenario where DNS is improperly configured the application can seem to "hang" for a while as the dns query times out. You can use the mkrdns script [http://freshmeat.net/projects/mkrdns/] to do this automatically. It seems to do a pretty decent job. Hope this helped! -Ahsan On Fri, 2 Jul 2004 23:23:19 +0100, Glynn Clements <glynn.clements@xxxxxxxxxx> wrote: > > joy wrote: > > > The computers on my lan have hostnames like xxx.pcm.com and this > > nameserver is an internal one to > > serve these machines. > > so i wrote a zone for "pcm.com" and made my server the master for the zone. > > the records look somthing like this: > > xxx.pcm.com IN A 192.xx.xx.xx (is this right?) > > No. Fully-qualified domains must end in a dot, otherwise they will be > treated as relative to the root of the zone. E.g. if the above line > occured in a zone file for pcm.com, it would correspond to > xxx.pcm.com.pcm.com. > > Usually, you use relative names, so the line should look like: > > xxx IN A 192.xx.xx.xx > > > to test it ,I ran dig for one of the hostnames and it appears that > > there is already a master for pcm.com somewhere else > > which (obviously) does not have a record for my machine. > > To make my machine not query other nameservers, I made my nameserver the > > only one in resolv.conf. > > and made it a slave for queries on zone "com" with the main NS outside > > as the master. > > however this causes dig to give a timed out error. > > > > Am I missing something here? > > Probably. > > > What I feel is that dig first tries to resolve "." (root)zone and is > > not able to because my NS does not hold any info on it. > > Am I right in thinking so? > > Probably. > > If named has been configured to allow recursive queries, it should > attempt to forward queries for other domains (ones which don't have an > entry in named.conf) to other DNS servers. > > However, such queries (or, more likely, the replies) may be blocked if > your server is behind a firewall. In that situation, you would need to > forward such queries to a DNS server from which you can receive > replies (e.g. the one which was previously listed in resolv.conf). > > > My NS had a different hostname before and dig could return a valid > > ip.However, my employer insists > > that the hostnames end with pcm.com (for some administrtive reasons ) > > Are these names supposed to be resolvable from outside of the LAN? > > If so, the only solution is to update the authoritative nameserver > (the one to which the ".com" domain has delegated authority over the > "pcm.com" domain) with the additional hosts. > > If not, you need to configure the local nameserver(s) (the one(s) to > which hosts on your LAN send DNS queries) to answer queries for the > pcm.com zone. These nameservers will already be configured to answer > general DNS queries. > > However: > > 1. If you aren't running your own local nameserver(s) (e.g. you're > just pointing the hosts at your ISP's DNS servers), you will have to > do so; your ISP certainly isn't going to add the pcm.com zone to their > recursive nameservers. You should be doing this anyhow. > > 2. The local pcm.com zone file will need to include any public DNS > records for that zone (e.g. www.pcm.com) as well as any local ones > (e.g. xxx.pcm.com). > > > Do I need to to write the PTR records for every A record I add? > > Probably not. > > Most programs don't care whether PTR records exist or if they are > accurate; i.e. they either don't bother to look them up, or if they do > look them up, don't care whether the query succeeds. > > The main exception is for access control. If you are accessing a > service which is restricted to specific hosts, access may be denied if > the PTR records can't be found or if they don't contain the expected > values. > > -- > Glynn Clements <glynn.clements@xxxxxxxxxx> > > > - > : send the line "unsubscribe linux-admin" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > - : send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
