FORMERR is strange. Generally speaking, you should not be seeing FORMERR
in queries between 2 different BIND instances.
It's looking increasingly to me like a bad NAT/PAT device, mangling your
packets. Maybe it doesn't understand EDNS0 (?) My next step would
probably be to run a packet trace/capture, although, on the off-chance
that it's EDNS0-related, you might try turning that off and see if it
makes a difference.
- Kevin
ListAcc wrote:
> 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-----
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
