BTW I ran ethereal earlier. That's what I thought so I increase the
datagram size on my pix firewall from 512 to 4096 and it's still the
name thing.
Kevin Darcy wrote:
> 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-----
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
