When I read Chris' post it sounded like something that I was seeing as well, except in my case I am unable to resolve names in the janestcapital.com domain. As I read further, I saw a 66.155.0.0 address and knew we were looking at the same thing. janestcapital's name servers are on that subnet as well. i.e., they're using vianetworks.net as well. And, no, I can't resolve any names in the tower23.com domain either. As for BIND versions, I'm seeing the same thing on name servers running 8.3.4 and 9.2.2. People have requested dig outputs, which I've attached. I hope this list accepts .txt attachments; I didn't want to muck up the body of this thread with lots of dig output. If the attachment gets stripped, I'll repost, but here's a summary of what I've tried & the results. Any help, suggestions would be appreciated. 1. Queried my name server for the A record of www.janestcapital.com - This timed out 2. Queried my name server for the NS record of janestcapital.com - This worked, although it returned only names, and not IPs. 3. Using the results of #2, queried both of janestcapital.com's name servers (by name) for the A record of www.janestcapital.com. - This timed out 4. Queried my name server for the A record of janestcapital.com's name server. - This timed out. 5. Queried my name server for the NS record of the domain hosting janestcapital.com's name server. - This timed out 6. Queried a gTLD name server (by name) for the NS record of the domain hosting janestcapital.com's name server. - This worked. Surprise: It uses the same name server as tower23.com in Chris' original post. 7. Using the results of #6, queried the name server of domain hosting janestcapital.com's name server (by name) for the A record of janestcapital.com's name server. This worked. 8. Using the results of #7, queried janestcapital.com's name server (by IP) for the A record for www.janestcapital.com - This worked. Ronan Flood To Sent by: comp-protocols-dns-bind@isc.org bind-users-bounce cc @isc.org Subject Re: frustrating lookup problem 09/23/04 12:04 Chris Sherman wrote: > I'm having trouble looking up a site(provider) from my master server, > but not from my slave, so, of course, people using the master cannot > browse and send mail to some sites hosted by vianetworks.net. Setting Does it work for other visnetworks sites? > the query type to any on the master - the info shows up fine, but still > no A records(session below). > > I'm having trouble with the following: > > creativeimprintsystems.com 66.155.17.134 > tower23.com 66.155.55.3 > sipco.com 66.155.40.24 > > master is running 8.1.2 on tru64 v5.0(I'm trying to get this fixed > before I upgrade bind) Upgrading BIND might sort it out, unless you have routing/firewall problems between you and the remote nameservers. > in my master's cache: > tower23 155405 IN NS ns1.imconline.net. ;Cr=addtnl > > > #nslookup > Default Server: localhost > Address: 127.0.0.1 > > > server pellns > Default Server: pellns.allegheny.edu > Address: 141.195.5.200 > > > tower23.com > Server: pellns.allegheny.edu > Address: 141.195.5.200 > > *** pellns.allegheny.edu can't find tower23.com: Non-existent host/domain > > set type=any > > tower23.com > Server: pellns.allegheny.edu > Address: 141.195.5.200 > > Non-authoritative answer: > tower23.com nameserver = ns1.imconline.net > tower23.com nameserver = ns2.imconline.net > > Authoritative answers can be found from: > tower23.com nameserver = ns1.imconline.net > tower23.com nameserver = ns2.imconline.net > ns1.imconline.net internet address = 66.155.0.139 > ns2.imconline.net internet address = 66.155.0.27 Can you query those nameservers from nslookup? Can you log on to pellns and query those nameservers from nslookup? If not, can you ping/traceroute to them from pellns? Same questions for the nameservers for sipco.com and the other domain. If there's an underlying network problem, sort that out first. As for working round it, the best thing would be to set up forward zones for the problem domains to your other server, but I don't think BIND 8.1.2 supports them. You could set up master zones on pellns tself for them, with the required entries copied from the true master, if you know what you need, eg for tower23.com tower23.com. IN A 66.155.55.3 tower23.com. IN MX 10 mailserver1.tower23.com. mailserver1.tower23.com. IN A 66.155.127.54 etc, but that is a bit dodgy. Another approach would be for pellns to forward all queries to your secondary, though that isn't a great idea either. -- Ronan Flood working for but not speaking for Network Services, University of London Computer Centre (which means: don't bother ULCC if I've said something you don't like) (See attached file: dig.txt) -- Binary/unsupported file stripped by Ecartis -- -- Type: application/octet-stream -- File: dig.txt