CNAME to an external domain
Hello, We have a bind server (v9.6) that's hosts mydomain.com. I'm trying to create a CNAME for host.mydomain.com to point to host.otherdomain.com. I don't host otherdomain.com. My entry currently reads: sipIN CNAME sip.otherdomain.com. But my DNS server isn't resolving it. It just returns a list of root nameservers. I've searched this mailing list and found threads that said this should work. But also saw a post that said this isn't allowed ( http://www.experts-exchange.com/Networking/Linux_Networking/Q_27656615.html) Thanks Ian ___ 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
Re: CNAME to an external domain
On 25.03.14 09:01, Ian Braun wrote: We have a bind server (v9.6) that's hosts mydomain.com. I'm trying to create a CNAME for host.mydomain.com to point to host.otherdomain.com. I don't host otherdomain.com. My entry currently reads: sipIN CNAME sip.otherdomain.com. But my DNS server isn't resolving it. It just returns a list of root nameservers. Your server apparently does not provide recursive DNS service, which is usually good. Servers people query directly should do that. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Remember half the people you know are below average. ___ 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
High recursive client counts
We recently migrated to BIND for our internal resolvers, and since the migration, we are experiencing periods of high recursive client counts, which will at times cause the BIND server to quit responding. As a workaround, I've been able to point the BIND server to a forwarder, bypassing the root hints, to restore stability, but this morning even with the forwarder, our count spiked. We are using Ubuntu 12.04 LTS, BIND version 9.8.1-P1. The server is configured strictly as a resolver, and is not authoritative for any domains. We have approximately 15-20k client devices on campus. Our average recursive client count is between 10 and 50. When the spikes occur, counts will get upwards of 3-4k (this morning: recursive clients: 2358/9900/1). What are possible causes of high recursive client count? What can be done to prevent this or tune around it? Obviously raising the max clients doesn't solve the problem, and the forwarder seemed to help, but apparently is still susceptible to the issue. Any suggestions would be greatly appreciated. -- Jason K. Brandt Systems Administrator ___ 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
Re: CNAME to an external domain
On 3/25/2014 9:01 AM, Ian Braun wrote: Hello, We have a bind server (v9.6) that's hosts mydomain.com http://mydomain.com. I'm trying to create a CNAME for host.mydomain.com http://host.mydomain.com to point to host.otherdomain.com http://host.otherdomain.com. I don't host otherdomain.com http://otherdomain.com. My entry currently reads: sipIN CNAME sip.otherdomain.com http://sip.otherdomain.com. But my DNS server isn't resolving it. It just returns a list of root nameservers. Are you *just* getting a list of root nameservers (i.e. a totally *empty* Answer Section)? What RCODE is being returned? Or, are you perhaps getting the CNAME in the Answer Section? If you're getting the CNAME, then that's all another nameserver needs in order to resolve the name. Or, were you expecting that your authoritative nameserver would be performing recursion for clients? I've searched this mailing list and found threads that said this should work. But also saw a post that said this isn't allowed (http://www.experts-exchange.com/Networking/Linux_Networking/Q_27656615.html) I couldn't see the incorrect answer, to mock it, since it's behind a paywall. - Kevin ___ 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
Re: High recursive client counts
Hi Jason, I've experienced similar things in the past on 9.8. Since then we've moved to the latest 9.9, but don't think this is at all version specific (that said, you could obviously try upgrading). I don't have an exact solution for you, but some ideas of things to check and personal experiences which might help you. Are the servers in question VM or bare metal? Several years back we made a big push to virtualize everything, and after migrating recursive DNS it worked great for awhile...as sites grew we hit a tipping point where VM-based resolvers seemed to introduce additional query latency. These servers were running far below BIND's capabilities, not taxing virtual resources, optimized per all available BIND/OS/virtualization knobs, and using enterprise (read: not just the latest free bits slapped together and expected to work) network, server and hypervisor tech. I spent several months trying to improve the situation and find a real root cause, but on a whim I setup an identical cluster on bare metal...no more problems. I didn't have time to dig further, so we avoid virtualization on busy resolvers (for now at least). As your client count has grown...is there any bottlenecks on your network that might be unaccounted for? Beyond bandwidth I'm thinking of things like resource constrained firewalls (are the resolvers in a DMZ?) which could cause queries to be dropped/timed out/retried, etc? I've seen issues where overworked NetOps teams got behind in capacity planning/upgrades and as clients/#DMZs grew firewalls couldn't keep up and created all sorts of issues not related to BIND itself. When the recursive client count backs up, you know more queries than usual are taking longer than expected to get answers...if this is not related to BIND itself, your servers, or the network...a bit of spelunking is in order. Capture some packets with tcpdump, and take a look at rndc recursing output. Take a look at the queries causing delays, dig them manually from various locations, and try to find a common theme. If there is no common theme to the query destinations, then look even closer at your network. :-) hth -Original Message- From: Jason Brandt jbra...@fsmail.bradley.edu Date: Tuesday, March 25, 2014 at 10:31 AM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: High recursive client counts We recently migrated to BIND for our internal resolvers, and since the migration, we are experiencing periods of high recursive client counts, which will at times cause the BIND server to quit responding. As a workaround, I've been able to point the BIND server to a forwarder, bypassing the root hints, to restore stability, but this morning even with the forwarder, our count spiked. We are using Ubuntu 12.04 LTS, BIND version 9.8.1-P1. The server is configured strictly as a resolver, and is not authoritative for any domains. We have approximately 15-20k client devices on campus. Our average recursive client count is between 10 and 50. When the spikes occur, counts will get upwards of 3-4k (this morning: recursive clients: 2358/9900/1). What are possible causes of high recursive client count? What can be done to prevent this or tune around it? Obviously raising the max clients doesn't solve the problem, and the forwarder seemed to help, but apparently is still susceptible to the issue. Any suggestions would be greatly appreciated. -- Jason K. Brandt Systems Administrator ___ 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
Re: High recursive client counts
Mike, I appreciate your insight here. We are indeed on virtual systems, using enterprise grade hardware as well. I will be doing more investigation today, to see if I can duplicate the behavior, which I have been able to do recently. Your VM vs Physical point is the thing that got me head scratching. As I stated, this is a new system, replacing our old resolvers; however, even though I've had 2 different types of software doing resolution on our old servers, they were actual physical machines. Load in VMWare monitoring shows what you'd normally expect, that the system isn't being taxed heavily, network usage is fairly low. To us, it seems like an application configuration issue. I could definitely see it being a VM issues of some sort too though, with the strange way it's behaving. I'll keep digging and debugging, to see if I can come up with more detail and correlate results to try and come up with a common theme/cause. Thank you for your help. On Tue, Mar 25, 2014 at 10:52 AM, Mike Hoskins (michoski) micho...@cisco.com wrote: Hi Jason, I've experienced similar things in the past on 9.8. Since then we've moved to the latest 9.9, but don't think this is at all version specific (that said, you could obviously try upgrading). I don't have an exact solution for you, but some ideas of things to check and personal experiences which might help you. Are the servers in question VM or bare metal? Several years back we made a big push to virtualize everything, and after migrating recursive DNS it worked great for awhile...as sites grew we hit a tipping point where VM-based resolvers seemed to introduce additional query latency. These servers were running far below BIND's capabilities, not taxing virtual resources, optimized per all available BIND/OS/virtualization knobs, and using enterprise (read: not just the latest free bits slapped together and expected to work) network, server and hypervisor tech. I spent several months trying to improve the situation and find a real root cause, but on a whim I setup an identical cluster on bare metal...no more problems. I didn't have time to dig further, so we avoid virtualization on busy resolvers (for now at least). As your client count has grown...is there any bottlenecks on your network that might be unaccounted for? Beyond bandwidth I'm thinking of things like resource constrained firewalls (are the resolvers in a DMZ?) which could cause queries to be dropped/timed out/retried, etc? I've seen issues where overworked NetOps teams got behind in capacity planning/upgrades and as clients/#DMZs grew firewalls couldn't keep up and created all sorts of issues not related to BIND itself. When the recursive client count backs up, you know more queries than usual are taking longer than expected to get answers...if this is not related to BIND itself, your servers, or the network...a bit of spelunking is in order. Capture some packets with tcpdump, and take a look at rndc recursing output. Take a look at the queries causing delays, dig them manually from various locations, and try to find a common theme. If there is no common theme to the query destinations, then look even closer at your network. :-) hth -Original Message- From: Jason Brandt jbra...@fsmail.bradley.edu Date: Tuesday, March 25, 2014 at 10:31 AM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: High recursive client counts We recently migrated to BIND for our internal resolvers, and since the migration, we are experiencing periods of high recursive client counts, which will at times cause the BIND server to quit responding. As a workaround, I've been able to point the BIND server to a forwarder, bypassing the root hints, to restore stability, but this morning even with the forwarder, our count spiked. We are using Ubuntu 12.04 LTS, BIND version 9.8.1-P1. The server is configured strictly as a resolver, and is not authoritative for any domains. We have approximately 15-20k client devices on campus. Our average recursive client count is between 10 and 50. When the spikes occur, counts will get upwards of 3-4k (this morning: recursive clients: 2358/9900/1). What are possible causes of high recursive client count? What can be done to prevent this or tune around it? Obviously raising the max clients doesn't solve the problem, and the forwarder seemed to help, but apparently is still susceptible to the issue. Any suggestions would be greatly appreciated. -- Jason K. Brandt Systems Administrator -- Jason K. Brandt Systems Administrator ___ 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
Bind 9.9.1 forward zone local
Hello. I have a problem with forwarding zone local to ISP resolvers.
My config is:
options {
directory /tmp;
disable-empty-zone .;
};
zone . {
type slave;
masters { 192.0.32.132; 193.0.14.129;};
masterfile-format text;
file /etc/bind/db.root;
allow-query { any; };
};
zone local. IN {
type forward;
forwarders {DNS_IP_ISP;};
forward only;
};
zone opendns.com IN {
type forward;
forwarders {208.67.222.222; 208.67.222.220; 208.67.220.220;
208.67.220.222;};
forward only;
};
Forwarding to opendns works, dig +short myip.opendns.com returns ip address
correctly.
Forwarding to local doesnt works, dig return nxdomain.
Commenting zone . leads to correct work of zone local
___
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
Re: High recursive client counts
Cathy, Thank you for your comments. I will continue to investigate, it helps to have avenues to look down though. As far as build version, we are aware that we aren't at current stable release. However we've tried to stick to the distro release as much as possible, to help streamline patching. But if this continues to be an issue, it's something we will definitely consider. The thing that's strange to me, is that we can mostly alleviate the symptoms, by using a forwarder. Currently I'm using an internal Windows 2003 server in the same subnet, on the same switch, to forward through, however I was previously using 8.8.8.8, and it was behaving well too. It seems to happen worst when simply using the root hints. Rndc recursing doesn't seem to be much help. The queries are all over, including google, adobe, amazon, microsoft, etc, as a combination of A//PTR/TXT records, from a variety of different clients on different subnets and in different firewall zones. At a glance, I don't see any correlation. Again, I'll keep investigating, and appreciate all the input! Jason On Tue, Mar 25, 2014 at 12:34 PM, Cathy Almond cat...@isc.org wrote: Packet tracing and/or looking at rndc recursing is good - then you'll see which client queries are waiting for answers from authoritative servers. Depending on what you've upgraded from, this might be a problem with whether or not your infrastructure can handle EDNS0 and large packet sizes. Newer version of BIND set the DO bit by default on the iterative queries, so perhaps some servers are sending back larger response than you were receiving before. It's worth checking that your network infrastructure can handle both EDNS0 and large UDP packet sizes (and DNS queries via TCP of course too). See https://www.dns-oarc.net/oarc/services/replysizetest I should also comment that the distro BIND 9.8 that you're using isn't the current ISC version, so you're missing-out on recent fixes - you might be better off with a self-build of 9.8.7-W1 or 9.8.5-W1: http://www.isc.org/downloads/ These also might be helpful: https://kb.isc.org/article/AA-00771/46/Which-version-of-BIND-do-I-want-to-download-and-install.html https://kb.isc.org/article/AA-00768/46/Getting-started-with-BIND-how-to-build-and-run-named-with-a-basic-recursive-configuration.html HTH Cathy ___ 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 -- Jason K. Brandt Systems Administrator ___ 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
Re: Bind 9.9.1 forward zone local
I would imagine your issue is a lack of an NS delegation in the root zone
you are slaving. If you load a parent and then try to forward a child of
that parent you must have a delegation in the parent. The delegation
doesn't have to match the forwarders but it must exist.
On Mar 25, 2014 1:57 PM, Андрей Ветров proukorn...@gmail.com wrote:
Hello. I have a problem with forwarding zone local to ISP resolvers.
My config is:
options {
directory /tmp;
disable-empty-zone .;
};
zone . {
type slave;
masters { 192.0.32.132; 193.0.14.129;};
masterfile-format text;
file /etc/bind/db.root;
allow-query { any; };
};
zone local. IN {
type forward;
forwarders {DNS_IP_ISP;};
forward only;
};
zone opendns.com IN {
type forward;
forwarders {208.67.222.222; 208.67.222.220; 208.67.220.220;
208.67.220.222;};
forward only;
};
Forwarding to opendns works, dig +short myip.opendns.com returns ip
address correctly.
Forwarding to local doesnt works, dig return nxdomain.
Commenting zone . leads to correct work of zone local
___
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
___
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
Re: High recursive client counts
Mark, That's a very good question, and something we had thought of as a possibility as well. I hadn't seen any good information in relation to entropy, so I'll check into your link. We had noticed that on other things as well, due to the virtual environment, but nothing that caused performance issues. I'm not sure how bind uses randoms, but I know it is a requirement. Perhaps someone else knows? From what I saw it seemed to be used primarily for signing zones. For now, I've disabled DNS inspection on our firewall, as it is an ancient Cisco firewall services module, and that seems to have stabilized things, but it's only been 30 minutes or so. Until I get a few days in, I'll keep researching. Again, thanks all. Your input and help is greatly appreciated. On Tue, Mar 25, 2014 at 1:31 PM, Mark Elkins m...@posix.co.za wrote: This might be a dumb answer but as the machine is part of a virtual server, perhaps you have simply run out of entropy? I know its a Resolver... but isn't perhaps BIND using Entropy to randomly talk on different ports to get answers? What about installing the 'haveged' package, www.irisa.fr/caps/projects/hipsor I don't see this doing any harm. I've personally found that not doing this on Virtual machines just makes them 'choke up'. -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 -- Jason K. Brandt Systems Administrator ___ 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
Re: Bind 9.9.1 forward zone local
What happens if you remove the . after local?
On 03/25/14 12:57, Андрей Ветров wrote:
Hello. I have a problem with forwarding zone local to ISP resolvers.
My config is:
options {
directory /tmp;
disable-empty-zone .;
};
zone . {
type slave;
masters { 192.0.32.132; 193.0.14.129;};
masterfile-format text;
file /etc/bind/db.root;
allow-query { any; };
};
zone local. IN {
type forward;
forwarders {DNS_IP_ISP;};
forward only;
};
zone opendns.com http://opendns.com IN {
type forward;
forwarders {208.67.222.222; 208.67.222.220; 208.67.220.220;
208.67.220.222;};
forward only;
};
Forwarding to opendns works, dig +short myip.opendns.com
http://myip.opendns.com returns ip address correctly.
Forwarding to local doesnt works, dig return nxdomain.
Commenting zone . leads to correct work of zone local
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- SafeZone Ally
___
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
Re: Bind 9.9.1 forward zone local
nothing, its correct name
2014-03-26 1:01 GMT+04:00 Lawrence K. Chen, P.Eng. lkc...@ksu.edu:
What happens if you remove the . after local?
On 03/25/14 12:57, Андрей Ветров wrote:
Hello. I have a problem with forwarding zone local to ISP resolvers.
My config is:
options {
directory /tmp;
disable-empty-zone .;
};
zone . {
type slave;
masters { 192.0.32.132; 193.0.14.129;};
masterfile-format text;
file /etc/bind/db.root;
allow-query { any; };
};
zone local. IN {
type forward;
forwarders {DNS_IP_ISP;};
forward only;
};
zone opendns.com http://opendns.com IN {
type forward;
forwarders {208.67.222.222; 208.67.222.220; 208.67.220.220;
208.67.220.222;};
forward only;
};
Forwarding to opendns works, dig +short myip.opendns.com
http://myip.opendns.com returns ip address correctly.
Forwarding to local doesnt works, dig return nxdomain.
Commenting zone . leads to correct work of zone local
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- SafeZone Ally
___
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
___
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
Re: Bind 9.9.1 forward zone local
.local is reserved for mDNS. I would say stop trying to use .local in the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: Bind 9.9.1 forward zone local
On 2014-03-25 16:16, Mark Andrews wrote: .local is reserved for mDNS. I would say stop trying to use .local in the DNS. While true, I don't think it will help this particular issue. As I understand it, BIND knows, by knowledge of being a root server, that local. can't possibly exist, and so that knowledge overrides the configuration of the forwarder. I ran into similar setting up a fake/virtual TLD for wrbldnsd, which I was able to resolve by moving it downstream to dnsbl.hireahit.net. instead of just dnsbl. Nearly. Until I hit one broken application that wouldn't work with this configuration. Switching BIND to use hints instead of acting as a root seems to work around this (broken) local configuration. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ 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
