rndc reconfig vs. rndc reload
I've read carefully through the BIND ARM and am still not sure of the answer to this, so I figured I'd ask on here. rndc reconfig causes BIND to re-load its config file, but unlike rndc reload, BIND will not scan the zone files it's mastering to see if there have been any updates. This is very useful in our situation because most of our name servers have tens of thousands of zones. We have an antiquated push process that copies files into the zonefile directory and then tells BIND rndc reload. For various reasons, rndc reload takes about 120 seconds to complete. BIND is not answering queries for a very large part of that time. I recently started experimenting with a different process: instead of rndc reload after updaing some of the zone files, I loop through the list of updated zone files and run rndc reload zone for each one. This is a vast improvement, because BIND doesn't appear to ever stop answering queries. However, I'm curious what I should do when an update contains both a new config file and new zone files. Normally a rndc reload would rescan the config and then scan all zone files (including the new ones), loading the new ones into memory and starting to serve them. But obviously we want to avoid rndc reload at all costs. I was considering doing rndc reconfig, followed by a rndc reload zone for each of the new zones. Would this work? ___ 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: rndc reconfig vs. rndc reload
On 16/03/2012 09:10, Mark Pettit wrote: Hi Mark, However, I'm curious what I should do when an update contains both a new config file and new zone files. If you have *new* zones, rndc reconfig will also load them. You don't need to run rndc reload for them when they are first added to the configuration. Regards, Anand Buddhdev RIPE NCC ___ 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: rndc reconfig vs. rndc reload
On 3/16/2012 4:10 AM, Mark Pettit wrote: I've read carefully through the BIND ARM and am still not sure of the answer to this, so I figured I'd ask on here. rndc reconfig causes BIND to re-load its config file, but unlike rndc reload, BIND will not scan the zone files it's mastering to see if there have been any updates. This is very useful in our situation because most of our name servers have tens of thousands of zones. We have an antiquated push process that copies files into the zonefile directory and then tells BIND rndc reload. For various reasons, rndc reload takes about 120 seconds to complete. BIND is not answering queries for a very large part of that time. I recently started experimenting with a different process: instead of rndc reload after updaing some of the zone files, I loop through the list of updated zone files and run rndc reloadzone for each one. This is a vast improvement, because BIND doesn't appear to ever stop answering queries. However, I'm curious what I should do when an update contains both a new config file and new zone files. Normally a rndc reload would rescan the config and then scan all zone files (including the new ones), loading the new ones into memory and starting to serve them. But obviously we want to avoid rndc reload at all costs. I was considering doing rndc reconfig, followed by a rndc reloadzone for each of the new zones. Would this work? ___ 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 an rndc reload is usually for an individual zone file. If you update a zone (and change the serial number) a reload will implement the new changes. a reconfig will check the BIND config file (named.conf) where you would configure the software to add new zones like include /var/namedb/com/yourdomain/db.yourdomain.com or something to that effect. ___ 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: rndc reconfig vs. rndc reload
On 3/16/2012 4:10 AM, Mark Pettit wrote: We have an antiquated push process that copies files into the zonefile directory and then tells BIND rndc reload. For various reasons, rndc reload takes about 120 seconds to complete. BIND is not answering queries for a very large part of that time. I recently started experimenting with a different process: instead of rndc reload after updaing some of the zone files, I loop through the list of updated zone files and run rndc reloadzone for each one. could the push process be changed to reload each individual zone after it's changed? This is a vast improvement, because BIND doesn't appear to ever stop answering queries. However, I'm curious what I should do when an update contains both a new config file and new zone files. as others have already mentioned, 'rndc reconfig' will rescan config file and load new zones. You must still reload those updated. Normally a rndc reload would rescan the config and then scan all zone files (including the new ones), loading the new ones into memory and starting to serve them. But obviously we want to avoid rndc reload at all costs. iiuc, reload forcifullly reloads all zones from disk, without checking for files' timestamps (just for cases where timestamp didn't change but files did). That would explain the delays. loading zones is very slow, BIND 9.9 should make it faster. I was considering doing rndc reconfig, followed by a rndc reloadzone for each of the new zones. Would this work? yes, this should work. On 16.03.12 05:49, Jonathan Vomacka wrote: an rndc reload is usually for an individual zone file. If you update a zone (and change the serial number) a reload will implement the new changes. Well, iirc the OP's problem is that when rndc reload is NOT for individual zone file, it takes very long. The question is, if/how can it be made to run faster. -- 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. I just got lost in thought. It was unfamiliar territory. ___ 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: nslookup fails if missing PTR record for IPv6 DNS server.
Hi there, On Fri, 16 Mar 2012, Matus UHLAR - fantomas wrote: the main problem is nslookup itself, and this is just one of reasons nslookup is not recommended for use. You didn't tell the OP what to use instead of nslookup! It's 'dig'. -- 73, Ged. ___ 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: nslookup fails if missing PTR record for IPv6 DNS server.
If PTR is present then it works pretty well. My concern is without PTR record. Ya I can use dig instead to nslookup but I need to fix it in nslookup as well. If anybody has any clue or can tell how it be fixed then it will really help me and it be highly appreciated. -Ashok On Fri, Mar 16, 2012 at 5:03 PM, G.W. Haywood b...@jubileegroup.co.ukwrote: Hi there, On Fri, 16 Mar 2012, Matus UHLAR - fantomas wrote: the main problem is nslookup itself, and this is just one of reasons nslookup is not recommended for use. You didn't tell the OP what to use instead of nslookup! It's 'dig'. -- 73, Ged. __**_ Please visit https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/**listinfo/bind-usershttps://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: external view recursion issue
If you are authoritative for a cname that points to an A elsewhere, your server will resolve the cname and leave it to the client dns server to go get the A from the server that hosts it. On Mar 16, 2012 10:14 AM, Samantha Steers sam.fait...@gmail.com wrote: Hi, I am getting prepped to migrate dns from one service to in-house servers. While going through the zone file to ensure I got everything, I found that we have CNAME in our domain pointing to a CNAME in another domain that is pointing to the A record in the other domain: host record.ourdomain.com record.ourdomain.com is an alias for record.client.otherdomain.com. record.client.otherdomain.com is an alias for otherhost.otherdomain.com. otherhost.otherdomain.com has address x.x.x.x To duplicate this exactly on our servers, it appears that I have to enable recursion but the provider said that they are not doing that. I get the feeling that I am not going to get the information from them on how they are accomplishing this without recursion. Right now I have replaced the CNAME with an A record pointing to the IP directly and am getting the proper results, but feel that this leaves me having to watch for changes that the otherdomain.com administrator might make. Am I missing something else that I can do to replicate? A separate external view? Thanks. ___ 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: rndc reconfig vs. rndc reload
I was considering doing rndc reconfig, followed by a rndc reload zone for each of the new zones. Would this work? 'reconfig' reloads the configuration without reloading all of the zones, but if it sees that you've added or removed any zones in the config file, it will load or unload those. So, when you say new zones above, if you meant actually *new*, then it's not necessary to do a subsequent reload. But if you meant existing zones that have been updated, then I believe your approach would work. BIND 9.9.0 has improved reconfig time somewhat, you might try it if you have a chance. Used to be, reconfig would pause the system, then parse the config file and apply the necessary changes, then resume. In 9.9.0, it parses the config file *first*, and *then* pauses the system to apply the changes. If you have a really big config file due to a large number of zones, that can save a noticeable amount of downtime. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: Test
I would NOT open the payload on this, just in case it gets through anyones filters etc (fished this one out of my ClamAV redirect directory) On Fri, 16 Mar 2012 23:30:08 +0800 r...@mars.org wrote: Cheers Ian Manners http://www.os2site.com/ ___ 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: nslookup fails if missing PTR record for IPv6 DNS server.
On Fri, Mar 16, 2012 at 5:03 PM, G.W. Haywood b...@jubileegroup.co.ukwrote: You didn't tell the OP what to use instead of nslookup! sorry :-) On 16.03.12 19:33, Ashok Agarwal wrote: If PTR is present then it works pretty well. My concern is without PTR record. Ya I can use dig instead to nslookup you can also use host, as it simpler and usually gives you what you need, unless you need to debug DNS itself. On Fri, 16 Mar 2012, Matus UHLAR - fantomas wrote: the main problem is nslookup itself, and this is just one of reasons nslookup is not recommended for use. [...] but I need to fix it in nslookup as well. If anybody has any clue or can tell how it be fixed then it will really help me and it be highly appreciated. I have it already explained: It's a problem of nslookup. Either you will have the PTR, or you will have the error. No other way. There are too many different versions of nslookup program within different systems, made by different perogrammers. It's just useless to fix nslookup, because that is how nslookup works and that's why we advise you to use host or dig. -- 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. 99 percent of lawyers give the rest a bad name. ___ 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: external view recursion issue
Who will be using this in-house DNS server? Your local users? If yes, then you will need to enable recursion so they can look up outside resources (google.com, etc.) If this server will strictly be an authoritative server for your domain, then it won't need recursion but queries that return a CNAME will cause the recursive server to look up anything in otherdomain.com, CNAME or A. Samantha wrote on 03/16/2012 10:13:30 AM: I am getting prepped to migrate dns from one service to in-house servers. While going through the zone file to ensure I got everything, I found that we have CNAME in our domain pointing to a CNAME in another domain that is pointing to the A record in the other domain: host record.ourdomain.com record.ourdomain.com is an alias for record.client.otherdomain.com. record.client.otherdomain.com is an alias for otherhost.otherdomain.com. otherhost.otherdomain.com has address x.x.x.x To duplicate this exactly on our servers, it appears that I have to enable recursion but the provider said that they are not doing that. I get the feeling that I am not going to get the information from them on how they are accomplishing this without recursion. Right now I have replaced the CNAME with an A record pointing to the IP directly and am getting the proper results, but feel that this leaves me having to watch for changes that the otherdomain.com administrator might make. Am I missing something else that I can do to replicate? A separate external view? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: external view recursion issue
Put record.ourdomain.com as a CNAME in both your internal and external views. Internal user will query internal view and get CNAME record to record.client.otherdomain.com. Your recursive name server will look up record.client.otherdomain.com and get the CNAME record to otherhost.otherdomain.com. It will look up that name and get the A record. Address is returned to the DNS client. External user queries your authoritative serve for record.ourdomain.com and get CNAME to record.client.otherdomain.com. Their recursive name server will look up record.client.otherdomain.com and get the CNAME record to otherhost.otherdomain.com. It will look up that name and get the A record. Address is returned to the external DNS client. -- William Brown Messaging and Core Hosted Application Technical Teams Technology Services, WNYRIC, Erie 1 BOCES (716) 821-7285 Samantha Steers sam.fait...@gmail.com wrote on 03/16/2012 03:09:52 PM: From: Samantha Steers sam.fait...@gmail.com To: wbr...@e1b.org, Date: 03/16/2012 03:09 PM Subject: Re: external view recursion issue Thank you for getting back to me. We have a set up with internal and external views. The internal is handling all the internal/recursive queries and the external is supposed to be authoritative without recursion. I am trying to reverse engineer the existing setup so I can match it. I guess the long and short of it is, if there are CNAMES looking for otherdomain.com then recursion has to = yes on the existing server, correct? The existing server is giving the result mentioned previously (below) while the new server is giving REFUSED. host record.ourdomain.com record.ourdomain.com is an alias for record.client.otherdomain.com. record.client.otherdomain.com is an alias for otherhost.otherdomain.com. otherhost.otherdomain.com has address x.x.x.x My thought is that it is either one way or the other, recursive or not, and that the record are going to have to be changed when they are migrated to the new servers to be A records pointing to the IP of the related, existing CNAMES. On Fri, Mar 16, 2012 at 1:47 PM, wbr...@e1b.org wrote: Who will be using this in-house DNS server? Your local users? If yes, then you will need to enable recursion so they can look up outside resources (google.com, etc.) If this server will strictly be an authoritative server for your domain, then it won't need recursion but queries that return a CNAME will cause the recursive server to look up anything in otherdomain.com, CNAME or A. Samantha wrote on 03/16/2012 10:13:30 AM: I am getting prepped to migrate dns from one service to in-house servers. While going through the zone file to ensure I got everything, I found that we have CNAME in our domain pointing to a CNAME in another domain that is pointing to the A record in the other domain: host record.ourdomain.com record.ourdomain.com is an alias for record.client.otherdomain.com. record.client.otherdomain.com is an alias for otherhost.otherdomain.com. otherhost.otherdomain.com has address x.x.x.x To duplicate this exactly on our servers, it appears that I have to enable recursion but the provider said that they are not doing that. I get the feeling that I am not going to get the information from them on how they are accomplishing this without recursion. Right now I have replaced the CNAME with an A record pointing to the IP directly and am getting the proper results, but feel that this leaves me having to watch for changes that the otherdomain.com administrator might make. Am I missing something else that I can do to replicate? A separate external view? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: nslookup fails if missing PTR record for IPv6 DNS server.
Or one can use nslookup from BIND 9 which doesn't have that restriction. nslookups with this restriction are at least 10 years old now and there have been new types added. DNSSEC has been completely overhauled in that time. 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.0 assertion failure
Is this something I should add to the FreeBSD port?
On 03/14/2012 17:58, Mark Andrews wrote:
We believe this patch will fix this issue. It has been committed to be
released as part of BIND 9.9.1.
Mark
diff --git a/bin/named/client.c b/bin/named/client.c
index 2f4130c..ae13795 100644
--- a/bin/named/client.c
+++ b/bin/named/client.c
@@ -240,7 +240,7 @@ ns_client_recursing(ns_client_t *client) {
REQUIRE(client-state == NS_CLIENTSTATE_WORKING);
LOCK(client-manager-reclock);
- client-state = NS_CLIENTSTATE_RECURSING;
+ client-newstate = client-state = NS_CLIENTSTATE_RECURSING;
ISC_LIST_APPEND(client-manager-recursing, client, rlink);
UNLOCK(client-manager-reclock);
}
--
If you're never wrong, you're not trying hard enough
___
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
