Re: possible noob question - @ CNAME?
You can not have a CNAME at the domain level. It is against RFC to have a CNAME and any other data at the same level of a given domain tree. i.e. the following is illegal wwwin CNAME www.blah.com wwwin MX 10 mail.blah.com This will cause BIND to throw the zone and not load it because it is illegal. If you put a CNAME at the domain level you are causing the CNAME to collide with an SOA records, and 1 or more NS records at the very minimum. -- -Ben Croswell On Thu, Feb 5, 2009 at 12:36 PM, RJValenta rjvale...@gmail.com wrote: forever ago, i set myself up with a solid bandwidth and static IPs and started to host websites for my friends their small businesses. basically, they covered the cost of my internet access. so for 10 years i've been hosting my own name, mail, and web servers allowing me to '@ A xxx.xxx.xxx.xxx' and then to make life easy i would 'www IN CNAME mywebserver.mydomain.com.' i say easy, because that way in the event that i changed ISPs and got new IP addresses, there was less chance of my screwing up a www and MX record if i made sure to change the two primary machines' A records properly. however, the '@ IN xxx.xxx.xxx.xxx' would always need to be changed manually. Is there a way around this? is it possible in some fashion to '@ IN CNAME my.server.com' ? I ask because I'm trying to trim back here, and move my NS hosting to NetSol and subsequently trim back on what i have to manage. at this stage in the game i'd rather have more time to not worry about my friend's personal website about their kids, and still be confident that their wife's home business website will still stay up. any ideas on how i can CNAME their @ record so their http://whatever.com will still work, but in the end, i'm only managing one domain's IP records? thanks, richard ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How many nameservers?
I have never heard of there being any downside to a large number of NS records for a domain. I know internally to my company we have large numbers of NS records for the internal domains. -- -Ben Croswell On Sun, Feb 1, 2009 at 7:51 PM, shulkae shul...@gmail.com wrote: How may NS entries typically is allowed per zone? Is there a bind limit or does it cause any side effects if the slaves are geographically distributed ? We would like to setup one zone for my new group who have offices all over the world ? We are planning to use BIND 9 over FreeBSD. There may be few SUN/Solaris hosts as well. We would like to start with around 16 Slaves per master per zone. Is this too much? My tests did not reveal any side effect fortunately. Anyone with experience of setting up DNS slaves all around the globe please advise.. Warm regards Shal ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about Records not authoritative for
This is exactly what we have done in the past to mitigate malware. Just load somebaddomain.com with no A records or with a wildcard pointing to 127.0.0.1. -- -Ben Croswell On Thu, Dec 11, 2008 at 11:29 AM, Baird, Josh jba...@follett.com wrote: You could just create an authoritative zone for the domain on your internal view to override recursion. You can then create a wildcard 'A' record or such to resolve to 127.0.0.1, etc. Josh *From:* bind-users-boun...@lists.isc.org [mailto: bind-users-boun...@lists.isc.org] *On Behalf Of *Casartello, Thomas *Sent:* Thursday, December 11, 2008 10:25 AM *To:* 'bind-us...@isc.org' *Cc:* Childs, Aaron *Subject:* Question about Records not authoritative for I was wondering if Bind allows you to override certain records for zones we are not authoritative for. Essentially we have a virus that some users have been infected with, and we want to temporarily blockout the domain name of the server that this virus connects to to send its information out. (Basically by having this domain name point to 127.0.0.1) I know it is a protocol violation, but I was just wondering if it is possible to do this and what would be the best way of going about it. We essentially have two servers with two views. One view serves our DNS zones to the outside world (With recursion disabled) and the other performs recursive queries for our on campus users. Obviously we would only be doing this on our internal view. Thomas E. Casartello, Jr. Staff Assistant - Wireless Technician/Linux Administrator Information Technology Wilson 105A Westfield State College (413) 572-8245 Red Hat Certified Technician (RHCT) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion for reverse/in-addr.arpa zones
Are there NS records and/or zone forwarding for the 10.131.10.0? If there is the servers will look to the most specfic domain. -- -Ben Croswell On Thu, Dec 11, 2008 at 4:38 PM, Todd Snyder tsny...@rim.com wrote: Good day, We are working on an odd issue. I can provide more detail as necessary, but don't want to fill this email with snips of useless stuff. All IP's/names provided are made up, as they don't matter in this problem as far as I can tell. This is more a functional question than a specific operating question. We have 2 servers acting as a slave for the zone 10.in-addr.arpa. The master(s) for this server are 2 Windows AD servers. Our servers (all bind9.4 of some variety) are doing zone transfers fine, and we're getting whatever is in the zone. We've run in to a couple IP's that when we dig them on these slaves, they are timing out. They are in a specific location, which we have determined are firewalled differently. For example, we are doing a dig for 10.131.10.1 against these 2 different locations. In one location, we get an answer quickly. In the other, it times out. The problem in our case is that in one location, the slave we're querying can't reach anything but the masters. What we've figured out is that the 10.in-addr.arpa zone doesn't contain EVERY 10. address we thought, but is missing some. In this case, our slaved zone doesn't have 10.131.10.1. But, instead of the slave server (which should be authortative) returning an I don't know error, it appears to be doing a recusive query. Against what, we're not 100% sure of yet. Well, we know which server, because DIG tells us, but we aren't sure why that one. When I look at the 10.in-addr.arpa zone, there are approximately 20 NS records for other AD servers. My speculation is that the slave we're querying is recusively looking to one of the servers returned in the additional section? This behaviour seems odd to us, and therein lies my question. Does doing a reverse lookup (dig -x) cause the queried server to behave differently than a forward lookup? My slave server is technically authoritative for the 10.in-addr.arpa zone, but it is still recusively going to another server to find an answer. Why? Is this because we have defined the zone as 10.in-addr.arpa instead of creating/slaving more specific zones (ie: 10.131.10.in-addr.arpa)? How can we control this behaviour? Thank you for any light you can shed on this - we're confident we know what is going on, but we can't figure out why the server behaves differently for reverse zones than it would for forward zones. Cheers, Todd. -- Todd Snyder Data Networks Tools bb.226.338.2617 Always On, Always Connected. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
