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
