forwarder is ignored when authoritative zone is added
I've recently had an issue that I'm having some issues finding
information on solving.
I have internal DNS resolvers...they act as recursive name servers for
general internet queries, but we have forwarders explicitly defined
for specific internal zones being served by other name servers.
My configuration has one particular zone configured as such:
zone "internal.organization.com" IN { type forward; forward only;
forwarders {172.x.x.x; 172.x.x.x; }; };
I have our main zone, organization.com, hosted in an external area
outside of a firewall with a wildcard record contained in it for
anything that is not explicitly defined. I have some services that I
need to reach using names that are in this external zone internally.
What I'm trying to do is to slave the organization.com zone to my
internal recursive resolver to mitigate any possible network issues.
So I setup the internal resolver as a slave for the "organization.com"
zone and found that queries against "internal.organization.com" were
getting answered with the wildcard for the external "organization.com"
zone. I can't seem to figure out why the forwarders are getting
ignored. Is it an order of precedence, say authoritative zones are
respected over forwarders...or something else??
Thanks for any assistance anyone can provide, or point me to some
documentation I'm missing,
Frank
___
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: forwarder is ignored when authoritative zone is added
On Fri, Oct 26, 2012 at 7:27 AM, Barry Margolin wrote:
> In article ,
> Frank Even wrote:
>
>> I've recently had an issue that I'm having some issues finding
>> information on solving.
>>
>> I have internal DNS resolvers...they act as recursive name servers for
>> general internet queries, but we have forwarders explicitly defined
>> for specific internal zones being served by other name servers.
>>
>> My configuration has one particular zone configured as such:
>>
>> zone "internal.organization.com" IN { type forward; forward only;
>> forwarders {172.x.x.x; 172.x.x.x; }; };
>>
>> I have our main zone, organization.com, hosted in an external area
>> outside of a firewall with a wildcard record contained in it for
>> anything that is not explicitly defined. I have some services that I
>> need to reach using names that are in this external zone internally.
>> What I'm trying to do is to slave the organization.com zone to my
>> internal recursive resolver to mitigate any possible network issues.
>>
>> So I setup the internal resolver as a slave for the "organization.com"
>> zone and found that queries against "internal.organization.com" were
>> getting answered with the wildcard for the external "organization.com"
>> zone. I can't seem to figure out why the forwarders are getting
>> ignored. Is it an order of precedence, say authoritative zones are
>> respected over forwarders...or something else??
>>
>> Thanks for any assistance anyone can provide, or point me to some
>> documentation I'm missing,
>> Frank
>
> Forwarders are only used when the server needs to recurse in the first
> place. They tell it "Instead of following the NS records, ask the
> forwarder(s)." If the server is authoritative for the zone, and there
> are no NS records delegating the subdomain away, it doesn't need to
> recurse and just returns what it has (in this case the record
> synthesized from the wildcard).
>
> Why not configure your resolvers as slaves or stubs for the internal
> subdomain?
Now that you put it that way the behavior makes perfect sense. Thanks!
I'd rather not do that to avoid having any internal records in
external DNS. I'm thinking of maybe running views on the internal box
instead, and putting the authoritative zone in an external view and
the rest of the current config in the internal view and forwarding
lookups to "organization.com" to the "external" view. Seems like the
only real way around it without a delegation of some some sort from
the master zone.
___
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 not loading into memory on first transfer
The subject is about the only way I can think to describe a situation we've run into recently. First here is the system: [root@dns]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@dns]# rpm -q bind bind-9.8.2-0.30.rc1.el6_6.2.x86_64 So, we got bit by a chroot permissions issue (unsure exactly how it got introduced), where the chroot was owned by root, but had named as the group owner. Perms were 750 on the dir (rwxr-x---) Zone files were in place for the necessary domains, but were outdated (assuming one of our updates broke something somewhere, they were all on average 3 months old). We updated some of the boxes, and on restart, named started. It initially started loading the 3 month old zone (one frequently updated I might add). The boxes then did a zone transfer from the master. Failing to be able to write the tmp file to the working directory, it moved on. Here is where the issue is. I've generally found if BIND fails to write the zone, it generally loads it into memory (masking the fact that there is an issue here for an extended period of time). In this particular instance, the masters ended up under maintenance shortly after these boxes rebooted, so they were unable to transfer the zone from them for another 2 hours. These boxes were serving stale data after boot despite being able to accomplish one zone transfer after boot. It seems that failing the first zone transfer did NOT load the zone into memory (but subsequent zone transfers while still failing to write the tmp file DID load the zone into memory). I guess the question really is, is this expected behavior or a bug? Thanks, Frank ___ 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 not loading into memory on first transfer
On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas wrote: > On 26.03.15 11:34, Frank Even wrote: >> >> Zone files were in place for the necessary domains, but were outdated >> (assuming one of our updates broke something somewhere, they were all >> on average 3 months old). > > >> Here is where the issue is. I've generally found if BIND fails to >> write the zone, it generally loads it into memory (masking the fact >> that there is an issue here for an extended period of time). In this >> particular instance, the masters ended up under maintenance shortly >> after these boxes rebooted, so they were unable to transfer the zone >> from them for another 2 hours. These boxes were serving stale data >> after boot despite being able to accomplish one zone transfer after >> boot. It seems that failing the first zone transfer did NOT load the >> zone into memory (but subsequent zone transfers while still failing to >> write the tmp file DID load the zone into memory). >> >> I guess the question really is, is this expected behavior or a bug? > > > What's the SOA? It's possible that the zones were not expired, so they were > provided as saved on disk. Since BIND wasn't able to transfer newer > versions, it continued providing old versions. > Yes, the old versions were provided on disk on initial load. But that was then followed up with a SUCCESSFUL zone transfer minutes later, but the server was unable to save the tmp file in the working directory and served stale content until about 2 hours later when the server was able to get another successful zone transfer from the master and then loaded the new zone in memory (despite being unable to write the tmp file to update the local copy of the zone). ___ 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 not loading into memory on first transfer
On Thu, Mar 26, 2015 at 1:00 PM, Matus UHLAR - fantomas wrote: >> On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas >> wrote: >>> >>> What's the SOA? It's possible that the zones were not expired, so they >>> were >>> provided as saved on disk. Since BIND wasn't able to transfer newer >>> versions, it continued providing old versions. > > > On 26.03.15 12:48, Frank Even wrote: >> >> Yes, the old versions were provided on disk on initial load. But that >> was then followed up with a SUCCESSFUL zone transfer minutes later, >> but the server was unable to save the tmp file in the working >> directory and served stale content until about 2 hours later when the >> server was able to get another successful zone transfer from the >> master and then loaded the new zone in memory (despite being unable to >> write the tmp file to update the local copy of the zone). > > > what didthe logs say? > Looks like the first transfer wasn't really successful (or the zone was > rejected) Logs indicated successful transfer, permission denied writing the tmp-x file that happens prior to writing it out to the zone file itself. ___ 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 not loading into memory on first transfer
On Fri, Mar 27, 2015 at 8:25 AM, Barry Margolin wrote: > In article , > /dev/rob0 wrote: > >> On Thu, Mar 26, 2015 at 11:34:42AM -0700, Frank Even wrote: >> > In this particular instance, the masters ended up under maintenance >> > shortly after these boxes rebooted, so they were unable to transfer >> > the zone from them for another 2 hours. These boxes were serving >> > stale data after boot despite being able to accomplish one zone >> > transfer after boot. It seems that failing the first zone transfer >> > did NOT load the zone into memory (but subsequent zone transfers >> > while still failing to write the tmp file DID load the zone into >> > memory). >> > >> > I guess the question really is, is this expected behavior or a bug? >> >> The bug is a misconfiguration bug, where contrary to documented >> requirements, you have not given named write privilege in its >> directory. >> >> I think you're saying named should fail to load the stale zones, >> which at startup it cannot know are stale. That does not sound >> correct to me. >> >> Perhaps you're suggesting that named should SERVFAIL the zone when >> the first zone transfer has happened, and while this sounds more >> reasonable, I am not sure that the zone transfer actually does take >> place if named is unable to open a temporary file to write. (What >> would be the point in talking to the master when you know you are >> unable to handle the data?) > > He's not suggesting either of these. He's saying that when it > successfully transferred the zone, it should update the in-memory > version, and serve that, even though it wasn't able to save it to disk. > That's what it does on the SECOND transfer, it just doesn't do it on the > FIRST transfer. ^^^ THIS! Exactly! I REALIZE I had a configuration problem that prevented writing the zone file locally that snuck in as it turns out on the bind-chroot package update. That's irrelevant to the issue I noticed after that. It DOES load up in memory and serve it up generally. It's just that what I've seen in this particular instance is that it failed to do this on the first successful zone transfer, then loaded it up in memory on the 2nd try (which sadly in this instance, was 2 hours later due to other issues, which of course caused it to be noticed in this instance where it might not have been in previous instances). 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
Re: rndc flushname not working
On Thu, Apr 9, 2015 at 1:48 PM, Matus UHLAR - fantomas wrote: > On 09.04.15 13:25, Frank Even wrote: >> >> Is there any place I can look to get a definitive answer in what cases >> "flushname" will and will not work? > > > it will work if you have old entries in the cache. > that will NOT help you if any of the servers that are supposed to be > authoritative for a domain will return invalid answers for the domain. > >> I've been digging around in lists >> and docs and can't seem to find any definitive answers. I've been >> having odd troubles clearing a name from a cache and after even >> clearing the name and the name that the name servers was attached to, >> still had to flush the entire cache to get resolution working properly >> on that domain again. > > > this indicates that any of NS records the domain points to returns NXDOMAIN > for the domain. > > hard to tell without more info, but some web DNS checkers are able to trace > this kind of issues... > -- So flushname does not address NXDOMAIN responses? That's the point I'm getting at, there is no good documentation on this that I can find. All the responses in the lists seem to be around "well it depends on your situation, need more data, etc." I'd like to just be able to find documentation on the specific behaviors of these options so I can understand properly what they do to maintain my environment properly without properly understanding what command will do or not do for me. The closest I have found is this - https://kb.isc.org/article/AA-01002/0/How-do-I-flush-or-delete-incorrect-records-from-my-recursive-server-cache.html - but it does not tgo on to tell what is or is not stored in the ADB (or give a link to figure that out) to properly understand what I can and cannot get dumped from cache by executing an "rndc flushname" command. I no longer have the data regardless, a full flush "fixed" the issue. We have some automation around running a "flushname" on the servers though and that addresses a large number of issues with cache weirdness, so when I got pulled in for something where it wasn't working I was curious as to why. It seems this is a recurring question on the lists, but I can't find where there are any definitive answers anywhere. If there is something that I'm missing I would be highly appreciative of being pointed towards that information. Thanks, Frank ___ 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 flushname not working
Is there any place I can look to get a definitive answer in what cases "flushname" will and will not work? I've been digging around in lists and docs and can't seem to find any definitive answers. I've been having odd troubles clearing a name from a cache and after even clearing the name and the name that the name servers was attached to, still had to flush the entire cache to get resolution working properly on that domain again. Thanks, Frank On Tue, Dec 9, 2014 at 8:31 PM, Mark Andrews wrote: > > Nameservers being down does not result in NXDOMAIN responses. I > suspect that some of the auth servers were producing NXDOMAIN > incorrectly. Flushing the name won't help in those cases. > > In message <001001d01429$1c857f70$55907e50$@iname.com>, "Frank Bulk" writes: >> Our ISP operations are running a mixture of 9.7.3 and 9.8.4 on several >> Debian servers and we've noticed that rndc flushname doesn't work many >> times. >> >> This weekend we had a local institution whose own authoritative DNS servers >> [all of them] were offline for 48+ hours and so there were several >> negatively cached entries in our resolvers' caches from customers who were >> querying for their institutions website and MX record. After the >> institution restored connectivity to their DNS servers this afternoon I >> checked all our resolvers and a few returned NXDOMAIN for the www and MX >> record. Issuing rndc flushname and rndc flushname >> didn't clear out the NXDOMAIN. I had to use "rndc flush" to resolve the >> issue. >> >> Is this expected behavior? The next time I see what, what troubleshoot >> steps should I take diagnose the issue? Dump the DB? >> >> Frank >> >> ___ >> 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 > -- > 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 ___ 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 flushname not working
On Sat, Apr 11, 2015 at 6:49 AM, Tony Finch wrote: > There was a bug in 9.9 and earlier that rndc flushtree only flushed the main > cache, not adb or bad cache. This was fixed in 9.10 - see item 3606 in the > CHANGES file. ...and where could I find info on what is stored in ADB and any other particular items that flushname might not deal with? That's where my frustration largely is, that I can't find clear documentation on this point. ___ 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 flushname not working
On Mon, Apr 13, 2015 at 11:10 AM, Evan Hunt wrote: > On Mon, Apr 13, 2015 at 11:05:05AM -0700, Frank Even wrote: >> ...and where could I find info on what is stored in ADB and any other >> particular items that flushname might not deal with? That's where my >> frustration largely is, that I can't find clear documentation on this >> point. > > I believe "rndc dumpdb -all" will give you that. > > Note, "rndc flushname" always took care of the ADB and the bad cache for a > given name. "rndc flushtree" is the one that used to be a problem -- it > would recursively clear all the names below the specified one from the > DNS cache, but it wasn't touching the ADB or the bad cache. Ah...it does appear I was confusing flushtree and flushname in the most specific doc I could find - https://kb.isc.org/article/AA-01002/0/How-do-I-flush-or-delete-incorrect-records-from-my-recursive-server-cache.html I have to apologize for that. I'd still definitely be curious to know what info is stored in the ADB though since according to the docs ADB was never intended to be flushed with a "flushtree" (although that has now apparently been addressed in a new version as stated earlier in the thread). 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
monitoring/graphing/tracking named queries
What does everyone do for monitoring their DNS traffic, if anything? I've come to a place where I need to have a good understanding of general capacity. For example, how much traffic and types of traffic individual servers are handling. I'd also like to get a breakdown of raw # of queries, then types of queries, and in some cases, the top 20 "busiest hosts" and maybe what they are hitting the servers with. dnstop I'm aware provides a lot of this functionality. But I'm wondering if anyone out there is aggregating a lot of this data and how they are going about doing it. Tutorials for this topic out on the internets seem to be pretty sparse. If there is something out there, I'd rather not reinvent the wheel. Thanks in advance for any assistance, Frank ___ 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: monitoring/graphing/tracking named queries
Thanks a lot. This is largely what I've been looking for/wondering
about. Thanks again!
Has anyone gotten much of anything going with graphite?
On Fri, Nov 13, 2015 at 3:50 PM, Warren Kumari wrote:
> See:
> DSC - http://dns.measurement-factory.com/tools/dsc/
> Hedgehog - https://github.com/dns-stats/hedgehog/wiki ("demo":
> http://stats.dns.icann.org/hedgehog/hedgehog.html )
>
> W
>
>
> On Fri, Nov 13, 2015 at 5:45 PM, Frank Even
> wrote:
>> What does everyone do for monitoring their DNS traffic, if anything?
>> I've come to a place where I need to have a good understanding of
>> general capacity. For example, how much traffic and types of traffic
>> individual servers are handling.
>>
>> I'd also like to get a breakdown of raw # of queries, then types of
>> queries, and in some cases, the top 20 "busiest hosts" and maybe what
>> they are hitting the servers with.
>>
>> dnstop I'm aware provides a lot of this functionality. But I'm
>> wondering if anyone out there is aggregating a lot of this data and
>> how they are going about doing it. Tutorials for this topic out on
>> the internets seem to be pretty sparse. If there is something out
>> there, I'd rather not reinvent the wheel.
>>
>> Thanks in advance for any assistance,
>> Frank
>> ___
>> 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
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
___
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
allow-query does not seem to be working
I have a group of servers serving out multiple addresses via anycast. I've
been made aware that an IP outside of our network is hitting the boxes with
queries, and we're returning data to the client.
With allow-query and allow-recursion locked to our subnets, this outside
host is still getting responses, and I'm trying to figure out why.
named.conf snippet:
allow-query { mynets; };
allow-recursion { mynets; };
Yet in response to a host not from one of the subnets allowed, we're
getting requests and returning some kind of response:
# tcpdump -i any -nvv src $myhost and dst 156.154.100.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size
65535 bytes
13:37:30.578020 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto
UDP (17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au]
A? www.sparknewspaper.co.uk. ar: . OPT UDPsize=4096 OK (53)
13:37:30.578025 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto
UDP (17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au]
A? www.sparknewspaper.co.uk. ar: . OPT UDPsize=4096 OK (53)
13:37:30.644502 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto
UDP (17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832
[1au] A? silverstonepaint.co.uk. ar: . OPT UDPsize=4096 OK (51)
13:37:30.644505 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto
UDP (17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832
[1au] A? silverstonepaint.co.uk. ar: . OPT UDPsize=4096 OK (51)
13:37:30.722628 IP (tos 0x0, ttl 64, id 5061, offset 0, flags [none], proto
UDP (17), length 68)
If an IP is not allowed as part of an "allow-query" statement, should the
name server still be returning any responses?
BIND version - BIND 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6
___
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: allow-query does not seem to be working
Thanks for the info. Also I'll have to note that I completely missed that the "offending IP" is one of the .uk root servers so the next logical conclusion is I've probably got a box in one of my environments driving an amplification attack of some sort or something at those IPs that I need to figure out. Sorry for the bother and thanks for the feedback. Much appreciated. On Mon, Aug 8, 2016 at 10:51 AM, Ray Bellis wrote: > On 08/08/2016 18:43, Darcy Kevin (FCA) wrote: > > As already noted, allow-query will cause you to send back a REFUSED > > response. That’s sort of the whole point of the REFUSED RCODE. > > > > > > > > If you want to not send back any response **whatsoever**, then take a > > look at the “blackhole” statement, but, honestly, this kind of “drop” > > function may, depending on network topology, be more efficiently > > performed in your firewall or IDS/IPS. > > > > > > > > Be aware that a client that doesn’t get a response may retry the query, > > so simply “dropping” queries may ultimately prove counter-productive. > > and also see Mark Andrew's Internet Draft on this very topic: > > https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-03 > > Ray > > ___ > 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
adding zone forwards without restart
Is there a way to add forwarders for specific zones without a restart? Everything I've read seems to indicate an "rndc reconfig" or an "rndc reload" should take care of this, but they do not. I add forwarders to "named.conf" and neither will load the new forwarded zone until I do a full daemon restart. Stock named on Cent 7/6/5 if curious is what I'm working with. Testing currently on 7 (which appears to be 9.9.4). Thanks, Frank ___ 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: adding zone forwards without restart
The basics are fine. BIND just doesn't load newly added forwarded zones, period. It also kind of lies in the output: Sep 20 17:57:48 host01 named[26453]: reloading configuration succeeded Sep 20 17:57:48 host01 named[26453]: any newly configured zones are now loaded ...except they're not. Thus far I think the only condition I've actually seen BIND load new zones without a restart after being added to named.conf is if it's not already authoritative for a lower level part of a domain and you're adding an authoritative zone. Even adding another master zone that is higher up in the hierarchy will not load until a full restart I've found (meaning you have "domain.com" configured as a master zone and add "subdomain.domain.com" as a master zone as well). On Tue, Sep 20, 2016 at 5:56 PM, Benny Pedersen wrote: > On 2016-09-21 02:40, Frank Even wrote: > >> Is there a way to add forwarders for specific zones without a restart? >> Everything I've read seems to indicate an "rndc reconfig" or an "rndc >> reload" should take care of this, but they do not. I add forwarders >> to "named.conf" and neither will load the new forwarded zone until I >> do a full daemon restart. >> > > rndc reload > > after edit named.conf > > remember to named-checkconf first > > is your rndc key pair or acl setup ? > > what are logged ? > > rndc reload zone ? > > type rndc to see valid commands > ___ > 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: adding zone forwards without restart
I am running chrooted. I'm relying on the "feature" of BIND "mounting" the standard dirs into a chroot via the standard startup scripts in Cent6/7. My understanding is it's not "copying" the files anywhere, but using those that are there. I am modifying them via puppet on the system. I've even created a "service" to only do an "rndc reconfig" instead of refreshing the service to ensure I can do safe puppet runs. But yeah, no matter what I do, nothing short of a restart of the service (typically "service named restart" on EL6 and "service named-chroot restart" on EL7) works. On Wed, Sep 21, 2016 at 1:53 AM, Tony Finch wrote: > Frank Even wrote: > > > Is there a way to add forwarders for specific zones without a restart? > > Everything I've read seems to indicate an "rndc reconfig" or an "rndc > > reload" should take care of this, but they do not. I add forwarders to > > "named.conf" and neither will load the new forwarded zone until I do a > full > > daemon restart. > > I bet you are running chrooted, and you are editing named.conf outside the > chroot, and the restart script copies it into the chroot. > > You need to find a way to run the copy independently of restarting the > daemon. > > Maybe there is something like `systemctl reload named.service` which does > a graceful reload ... but, looking at the srpm I think you might have to > run `/usr/libexec/setup-named-chroot.sh /var/named/chroot on`. OBVIOUSLY. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > Trafalgar: North or northwest 4 or 5. Moderate or rough. Fair. Good. > ___ 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: adding zone forwards without restart
None of that works. Nothing short of a restart of the daemon notices new forwarders added to the config. That is inclusive of: rndc reconfig rndc reload rndc flushname $nameofforwardersadded rndc flush A restart of the service however, that does work. That is far more disruptive than I like though (making adding a forwarder a bit more labor intensive at this point than I was hoping it would be). On Wed, Sep 21, 2016 at 8:30 AM, Tony Finch wrote: > Benny Pedersen wrote: > > > > why does reload not flush ? > > Often you want to reload zone files without throwing away the cache. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > Bailey: Southeast 6 to gale 8, becoming cyclonic, mainly southwest, gale 8 > to > storm 10, backing south 5 to 7 later. Very rough or high, becoming rough. > Rain > then showers. Moderate or poor, occasionally good. > ___ > 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: adding zone forwards without restart
I'm adding forwarders, not adding an authoritative domain. I'm not working directly with a zone at all. Just intercepting DNS traffic for a specific zone intended to be internal only and forwarding it to another group of resolvers instead of dumping the queries to the Internet. On Wed, Sep 21, 2016 at 5:03 PM, Sten Carlsen wrote: > I assume you did increase the serial, if not this is what I would expect > to happen. > > On 21/09/16 10:53, Tony Finch wrote: > > Frank Even wrote: > > > Is there a way to add forwarders for specific zones without a restart? > Everything I've read seems to indicate an "rndc reconfig" or an "rndc > reload" should take care of this, but they do not. I add forwarders to > "named.conf" and neither will load the new forwarded zone until I do a full > daemon restart. > > I bet you are running chrooted, and you are editing named.conf outside the > chroot, and the restart script copies it into the chroot. > > You need to find a way to run the copy independently of restarting the > daemon. > > Maybe there is something like `systemctl reload named.service` which does > a graceful reload ... but, looking at the srpm I think you might have to > run `/usr/libexec/setup-named-chroot.sh /var/named/chroot on`. OBVIOUSLY. > > Tony. > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > >"MALE BOVINE MANURE!!!" > > > ___ > 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
