Re: internal network PTR records, necessary?
Thanks for the help figuring out where to direct my research! I'll check all those sources out. Really appreciate it On Wed, Aug 14, 2013 at 7:00 AM, Chris Thompson c...@cam.ac.uk wrote: On Aug 14 2013, SM wrote: Hi James, At 19:06 13-08-2013, James Chase wrote: I noticed if I do a reverse lookup on an internal IP it seems to reference an iana server. Do we have a misconfiguration to be going out there for an answer? Could it be that this iana server was not responding monday morning? See RFC 6303 and RFC 6305. Also see the BIND documentation on automatic empty zones. In BIND 9.9, empty reverse zones for RFC1918 ranges will be defined by default. In earlier versions, since 9.6-ESV-R6, 9.7.5 or 9.8.1 respectively, the same will happen only if you include the option empty-zones-enable yes; explicitly. -- Chris Thompson Email: c...@cam.ac.uk -- Beware of all enterprises that require new clothes. -- Henry David Thoreau ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
internal network PTR records, necessary?
This isn't a problem with bind, that I'm aware of but I was hoping someone could shed a little DNS expertise on a situation that happened Monday morning. I'll be very brief: We started experiencing problems with connectivity from our application servers to a couple database servers. I narrowed the problem down to remote logins over tcp/ip and then by noticing SSH was also connecting slowly, found that the SSH connection was hanging doing a reverse lookup on the internal ip address. After doing some mysql research I was able to find the option to tell mysql to skip this lookup and it solved our problem My dillema has been trying to figure out why the issue started in the first place. There have been no DNS changes for months, and we have never kept PTR records for our internal IPs at our nameservers. This has always just worked, so why would these lookups start hanging monday morning without any configuration changes? Later in the day the SSH connections were quick again within the internal network. Could it just have been that our DNS server wasn't functioning properly for a period of time? We are monitoring this server with nagios so I would be surprised. Should I be concerned about not having internal PTR records? I have never even considered the necessity of setting this up. I noticed if I do a reverse lookup on an internal IP it seems to reference an iana server. Do we have a misconfiguration to be going out there for an answer? Could it be that this iana server was not responding monday morning? ; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 -x 192.168.1.50 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 1252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;50.1.168.192.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 168.192.in-addr.arpa. 300 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800 ;; Query time: 147 msec ;; SERVER: 192.168.1.180#53(192.168.1.180) ;; WHEN: Tue Aug 13 22:00:25 2013 ;; MSG SIZE rcvd: 120 -- Beware of all enterprises that require new clothes. -- Henry David Thoreau ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dns update issue
This isn't exactly a bind issue but I recently changed our slave dns server to a new IP address in a remote location for our domain 'mandala-designs.com'. I updated our dns record in bind to point to the new location of our dns server: dns3.mandala-designs.com at 192.241.200.20. I added the PTR for the new IP address. I think it's been about 4 weeks since I made this change. However if I try to ping dns3.mandala-designs.com from different network locations it still returns the IP address of our old server, which I have been forced to leave on for now to avoid resolution issues. I can't figure out the reason for this. Our TTL is only 5 minutes so why should people still be getting the wrong address? If you dig @ dns1.mandala-designs.com, the authoritative NS, then you get the correct ip for dns3. What am I not understanding? -- Beware of all enterprises that require new clothes. -- Henry David Thoreau ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Issue with recursion in a view
Hi, I have two views, one for a specific range of 8 IP's on the internet and one view for any inluding internal servers. In my main named.conf I have allowed recursion to specific hosts, including all of the hosts in both views (which are specific using ACL's). I can use recursion on this server from any of the IP's which are in the default view (matching any IP) but the IPs in the other view (the 8 IP's on the internet) do not work. It doesn't give me an access denied message in dig, it just times out. I have tested this by taking the 8 IP's out of the view and then they do recursion just fine. I have also tried adding the allow recursion line with specific IPs to the view where recursion doesn't work but this did not help. Adding to the interest is that I have a second DNS server (the master server) on the same network with the same ACL and views setup and behind the same external firewall, with the same rules on the external firewall and the internal firewall where recursion works just fine! Also the two servers are clones of each other. I'm on 64 bit version of CentOS 5.5 with bind packge: bind-9.3.6-4.P1.el5_4.2 bind-chroot-9.3.6-4.P1.el5_4.2 Thanks, James -- Beware of all enterprises that require new clothes. -- Henry David Thoreau ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
