Two DNS Servers inside a firewall

ListAcc listacc at ocosa.com
Fri Sep 5 02:06:50 UTC 2008


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
>>>>>>
>>>>>>
>>>>>> [root at server2 ~]# dig company.com
>>>>>>
>>>>>> ; <<>> DiG 9.3.4-P1 <<>> company.com
>>>>>> ;; global options:  printcmd
>>>>>> ;; connection timed out; no servers could be reached
>>>>>>
>>>>>>
>>>>>> [root at server1 ~]# 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-----
>>>>>           
>>>>>           
>>>>       
>>>>         
>>>   
>>>       
>>
>>     
>
>
>   



More information about the bind-users mailing list