Kevin,
The problem is server1 has a set of customers and server2 has a set of
customers. Each server is auth for their respective customers.
Customers on server2 can not reach customers on server1 and vice versa.
I have logging on but can not see anything that's strange...
04-Sep-2008 15:06:07.169 client 192.168.0.22#64168: query:
mail.customer2.com IN A +
04-Sep-2008 15:06:07.169 createfetch: mail.customer2.com A
04-Sep-2008 15:06:07.170 client 127.0.0.1#2129: query:
mail.customer2.com IN A +E
04-Sep-2008 15:06:07.170 FORMERR resolving 'mail.customer2.com/A/IN':
127.0.0.1#53
See my logging in named.conf
logging {
channel default_syslog {
// Send most of the named messages to syslog.
syslog local2;
severity debug;
};
channel audit_log {
// Send the security related messages to a separate file.
file "/var/named/named.log";
severity debug;
print-time yes;
};
category default { default_syslog; };
category general { default_syslog; };
category security { audit_log; default_syslog; };
category config { default_syslog; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };
};
On these servers I did not issue the view command in named.conf I have
not had time to break down these servers like that yet I have two more
being built to be implemented as such though.
Kevin Darcy wrote:
> OK, so is the *real* problem here that your authoritative zones can't be
> resolved from anywhere except the authoritative servers themselves?
>
> Turn on query logging to see if the queries are even getting to the
> correct servers, and, if so, what view is being matched.
>
> You mentioned "translation" in an earlier message, so I'm thinking you
> might have some NAT and/or PAT going on, in which case you might also
> want to capture or trace packets "to or from UDP port 53". There might
> be some surprising discoveries to be made there.
>
>
> -Kevin
>
> P.S. wizart1.com resolves for me, by the way, although it took over 3
> seconds on the first attempt.
>
> ListAcc wrote:
>
>> Chris,
>>
>> I have added 127.0.0.1 to the recursion list on both server nothing.
>> Also if you nslookup from remote client computers you can not resolve
>> the domains either it says DNS timeout....
>>
>> Chris Buxton wrote:
>>
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> In the header of the response to the second 'dig' command, note the
>>> 'flags' section. The 'ra' flag is not present.
>>>
>>> In your named.conf, in the 'options' statement block, check your
>>> 'allow-recursion' statement. This is most likely the culprit. Your
>>> query is coming from 127.0.0.1, and that address is probably not
>>> listed in the allow-recursion ACL.
>>>
>>> Chris Buxton
>>> Professional Services
>>> Men & Mice
>>>
>>> On Sep 4, 2008, at 2:16 PM, ListAcc wrote:
>>>
>>>
>>>
>>>> Hello,
>>>>
>>>> For the life of me I can not find the details of the problem: I have
>>>> two servers in question, both are authoritative/cache servers. One
>>>> server is auth for a few zones and the other one for a few zones due to
>>>> a split hosting environment. Running Bind 9.3.5-P2 and Bind 9.3.4-P1 on
>>>> CentOS. For this example I will identify them as server 1 and server
>>>> 2. Also I have checked the logs nothing.
>>>>
>>>> Server 1 can not resolve domains at Server 2 and vice versa. It worked
>>>> before I am not sure what happed. I thought it was the root hints so I
>>>> updated and not the culprit. When I issue a dig here is the output
>>>>
>>>>
>>>> [EMAIL PROTECTED] ~]# dig company.com
>>>>
>>>> ; <<>> DiG 9.3.4-P1 <<>> company.com
>>>> ;; global options: printcmd
>>>> ;; connection timed out; no servers could be reached
>>>>
>>>>
>>>> [EMAIL PROTECTED] ~]# dig company2.com
>>>>
>>>> ; <<>> DiG 9.3.5-P2 <<>> company2.com
>>>> ;; global options: printcmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6067
>>>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 2
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;wizart1.com. IN A
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> com. 140357 IN NS j.gtld-servers.net.
>>>> com. 140357 IN NS k.gtld-servers.net.
>>>> com. 140357 IN NS l.gtld-servers.net.
>>>> com. 140357 IN NS m.gtld-servers.net.
>>>> com. 140357 IN NS a.gtld-servers.net.
>>>> com. 140357 IN NS b.gtld-servers.net.
>>>> com. 140357 IN NS c.gtld-servers.net.
>>>> com. 140357 IN NS d.gtld-servers.net.
>>>> com. 140357 IN NS e.gtld-servers.net.
>>>> com. 140357 IN NS f.gtld-servers.net.
>>>> com. 140357 IN NS g.gtld-servers.net.
>>>> com. 140357 IN NS h.gtld-servers.net.
>>>> com. 140357 IN NS i.gtld-servers.net.
>>>>
>>>> ;; ADDITIONAL SECTION:
>>>> h.gtld-servers.net. 52569 IN A 192.54.112.30
>>>> m.gtld-servers.net. 108692 IN A 192.55.83.30
>>>>
>>>> ;; Query time: 1 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Thu Sep 4 14:39:35 2008
>>>> ;; MSG SIZE rcvd: 285
>>>>
>>>>
>>>> The zones have public IP addresses so the translation should work and
>>>> resolve if using either server as a resolver. Both servers will resolve
>>>> the domains they are auth for any other domain not hosted on the server
>>>> except the ones on each others server if this makes sense.
>>>>
>>>> Thanks in advanced.
>>>>
>>>> Otis
>>>>
>>>>
>>>>
>>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.8 (Darwin)
>>>
>>> iEYEARECAAYFAkjAVkAACgkQ0p/8Jp6Boi38VACfacM3feAJN/x3cmsF3dgRowhi
>>> V4gAoJv9sz723/ZK2Z7HSY6KC5jfZEY/
>>> =DT5y
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>
>>
>>
>>
>
>
>
