named is creating excessive number of tmp-xxxxx files.
Hello, I am running a named service on the OpenSuSE 15.4 platform. # named -v BIND 9.16.44 (Extended Support Version) and I am getting an excessive number of binary tmp-xx files created in the named chroot directory - /var/lib/named. (xx is just a bunch of random characters.) What are these files and how to I automatically manage the creation and deletion of them? Could I simply add an 'ExecStartPre=+/bin/rm -rf /var/lib/named/tmp-* to the named.service file in order to delete all these tmp-* files whenever the named service is started/restarted or would this be an unsafe practice? I don't know if these files are being used to persist information across restarts of the named service or not... These tmp files contain binary information and as such are unreadable. Much appreciate, and thanks in advance for some advice... Marc C -- *"The Truth is out there" - Spooky* -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed. My public key for sending encrypted email to me can be found at - https://keys.openpgp.org/search?q=m...@domesweetdome.us.com or just ask me for it and I will send it to you as an attachment. If you don't understand, no worries, just ignore it and/or ask me to explain it further./) OpenPGP_0xD23D75B63BF0E8B7.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Localhost view is not working for me SOLVED!
Thanks Bob, while your suggestions didn't help directly they did put me
on a path that eventually lead to the solution. Turns out I had an ill
defined SOA record along with a ill defined NS record (copy/paste error)
that was the problem in my localhost zone. I think I am once again a
happy camper.
Marc..
On 3/30/20 11:42 AM, Bob Harold wrote:
> Try without the "match-destinations". Only use match-clients to
> determine the view. (Or try only match-destinations as a separate test.)
> (I have never used match-destinations.)
> Turn on query logging and see what source and destination your queries
> are using. Make fake queries to unique names just to be sure which
> queries you are looking at.
> That's the best that I can suggest.
>
> --
> Bob Harold
>
>
> On Mon, Mar 30, 2020 at 1:07 PM Marc Chamberlin via bind-users
> mailto:bind-users@lists.isc.org>> wrote:
>
> Hello - I am running the Bind server
>
> > named -v
> BIND 9.11.2
>
> under OpenSuSE Leap 15.0. In order to support other servers
> running on the same system that my Bind server is running on I am
> trying to set up 3 views, one for the localhost, one for my
> internal network to use, and one for the external Internet. (yes
> this is also a gateway system with 2 NIC cards.) What I am having
> troubles with is getting the localhost view to work properly. I
> have tried a number of ways to get this to work and will show the
> apropos segment of my named.conf file below. Commented out
> sections show things I have tried already but rejected because the
> results I get from queries, from other servers on this
> gateway/localhost system, that are not what I want. For example
> if I use the definition in with localhost is defined, rather than
> 127.0.0.1, I will get results that are defined by my internal view
> which is not acceptable. If I use 127.0.0.1 instead, lookup query
> results from/for the other servers running on my gateway/localhost
> fail completely with no results returned. I don't understand why
> 127.0.0.1 fails, it seems like this should be the proper way to
> limit the scope of localhost queries so that they are answered by
> definitions defined in my "localhost_resolver" view. What am I
> missing? How to I set up the "localhost_resolver" view so that it
> will answer queries from localhost without falling through to my
> "internal" view? (The keys are also necessary to restrict
> certain types of queries but I tried not using them and got the
> same inadequate responses to queries from the localhost.)
>
> I have also used dig to show exactly what view was answering
> queries from localhost and it verified that the queries were
> indeed being answered by my internal view when I used localhost in
> the match-clients and match-destinations statements. If necessary
> I can post other files, such as the local_zones.conf or some of
> the domain definition files themselves but will have to edit them
> to remove actual URLs and other sensitive information. I checked
> the log files also, after setting the debug level to 10, and the
> Bind server reports no errors or warnings when it is started up.
> Thanks for any help offered, and below is what I think is the
> relevant part of my named.conf file.
>
> Marc
>
>> view "localhost_resolver"
>> {
>> // match-clients { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>> // match-destinations { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>>
>> match-clients { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };
>> match-destinations { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };
>>
>> // match-clients { 127.0.0.1; };
>> // match-destinations { 127.0.0.1; };
>>
>> recursion yes;
>> zone "." in {
>> type hint;
>> file "root.hint";
>> };
>> zone "localhost" in {
>> type master;
>> file "localhost.zone";
>> allow-update { none; };
>> };
>> zone "0.0.127.in-addr.arpa" in {
>> type master;
>> file "127.0.0.zone";
>>
Localhost view is not working for me
Hello - I am running the Bind server
> named -v
BIND 9.11.2
under OpenSuSE Leap 15.0. In order to support other servers running on
the same system that my Bind server is running on I am trying to set up
3 views, one for the localhost, one for my internal network to use, and
one for the external Internet. (yes this is also a gateway system with
2 NIC cards.) What I am having troubles with is getting the localhost
view to work properly. I have tried a number of ways to get this to work
and will show the apropos segment of my named.conf file below.
Commented out sections show things I have tried already but rejected
because the results I get from queries, from other servers on this
gateway/localhost system, that are not what I want. For example if I
use the definition in with localhost is defined, rather than 127.0.0.1,
I will get results that are defined by my internal view which is not
acceptable. If I use 127.0.0.1 instead, lookup query results from/for
the other servers running on my gateway/localhost fail completely with
no results returned. I don't understand why 127.0.0.1 fails, it seems
like this should be the proper way to limit the scope of localhost
queries so that they are answered by definitions defined in my
"localhost_resolver" view. What am I missing? How to I set up the
"localhost_resolver" view so that it will answer queries from localhost
without falling through to my "internal" view? (The keys are also
necessary to restrict certain types of queries but I tried not using
them and got the same inadequate responses to queries from the localhost.)
I have also used dig to show exactly what view was answering queries
from localhost and it verified that the queries were indeed being
answered by my internal view when I used localhost in the match-clients
and match-destinations statements. If necessary I can post other files,
such as the local_zones.conf or some of the domain definition files
themselves but will have to edit them to remove actual URLs and other
sensitive information. I checked the log files also, after setting the
debug level to 10, and the Bind server reports no errors or warnings
when it is started up. Thanks for any help offered, and below is what I
think is the relevant part of my named.conf file.
Marc
> view "localhost_resolver"
> {
> // match-clients { ! key letsencrypt.; ! key
> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
> // match-destinations { ! key letsencrypt.; ! key
> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.;
> ! key letsencrypt_amcrest.; 127.0.0.1; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.;
> ! key letsencrypt_amcrest.; 127.0.0.1; };
>
> // match-clients { 127.0.0.1; };
> // match-destinations { 127.0.0.1; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> zone "localhost" in {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> allow-update { none; };
> };
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
> in {
> type master;
> file "127.0.0.zone";
> };
> include "/etc/named.d/local/local_zones.conf";
> };
>
> view "internal" { // What the home network will see
> // match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localnets; localhost; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localnets; localhost; };
>
> // match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
>
> // match-clients { 192.168.10.0/24; };
> // match-destinations { 192.168.10.0/24; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> include "/etc/named.d/internal/internal_zones.conf";
> };
> view "external" { // What the Internet will see
> match-clients { any; };
> match-destinations { any; };
> recursion no;
> include "/etc/named.d/external/external_zones.conf";
> };
--
--... ...-- .. ...-.. ..-- .- --... .--. -..- .-- --
.- .-. -.-.
*Computers: the final frontier. These are the voyages of the user Marc.
His mission: to explore strange new
Re: rndc and nsupdate failing to work for me
On 03/14/2019 04:40 AM, Niall O'Reilly wrote: > On 14 Mar 2019, at 5:17, Marc Chamberlin via bind-users wrote: > >> On 03/13/2019 08:33 PM, John W. Blue wrote: >>> As an option, instead of including /etc/rndc.key nothing prevents you >>> from including rndc.conf. That way you are consistent with your useage. > Another option is to include rndc.key from both rndc.conf and > named.conf, which also keeps things consistent. Additionally, it > allows rndc.key to have stricter protection than the .conf files > (in my case, mode bits 0640 rather than 0644). Thanks Niall, I thought I had tried that approach when I was poking around with rndc.conf, but apparently I must have done it wrong. The include statement in rndc.conf does work, however I still do get the warning - "WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)" which seems to be unnecessary but I am not going to worry about it. > > I seem to recall actually needing to do this because of named > objecting to the syntax of some of the configuration statements > I needed to use in rndc.conf. > > I hope this helps. Yes, it does, thanks again... Much cleaner and safer this way... Marc... > > Niall O'Reilly -- *Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! * ___ 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 and nsupdate failing to work for me
On 03/14/2019 12:02 AM, Mark Andrews wrote:
> "rndc showzone" only works if you also have "allow-new-zones yes;” set.
Really??? Wow! Thanks Mark! I would never have guessed that, but yes it
does make rndc much happier!
>
> The last time there was a complaint about UPDATE’s not sticking the
> startup procedure was wiping out the changes.
OH! That does not bod well, means I got to go and bellyache at the
OpenSuSE developers to see if something is going on with "systemctl
restart named.service" and hopefully this won't degenerate into a finger
pointing contest! ;-) I will go poke around and take a look at the
startup scripts
>
> Mark
>
>> On 14 Mar 2019, at 10:01 am, Marc Chamberlin via bind-users
>> wrote:
>>
>> Hello Bind Users,
>>
>> I have been working on upgrading my Bind 9.11.2 server (running on a Linux
>> system, OpenSuSE Leap 15) so that I can accept DNS challenges/verification
>> from/for LetsEncrypt certificates, and I am running into a wall trying to
>> get nsupdate (and rndc which I wanted to use to test the server with) to
>> work with the server. So I hope some kind guru here can lead me into the
>> light cuz I am lost
>>
>> My configuration is really not all that complicated, I am running the server
>> on a firewall computer that supports other services such as web and email
>> services also. I have a SOHO internal network behind the firewall computer.
>> I have configured the Bind (named) server with the 3 standard views -
>> localhost.resolver, internal, and external. Since I support a number of
>> virtual hosts and real hosts I have quit a few zones defined for each view.
>> For regular queries and things like zone transfers the server is performing
>> OK.
>>
>> That said I will show what I think are the relevant definitions from my
>> configuration files, with sensitive info redacted of course, and follow on
>> with questions I have -
>>
>> named.conf -
>> There is a bunch of stuff at the beginning of this file, but I think it is
>> irrelevant to this issue. Correct me if I am wrong and I will be happy to
>> post it...
>>
>>> include "/etc/rndc.key";
>>> controls {
>>>inet * port 953
>>>allow { any; } keys { "rndc-key"; };
>>> };
>>> view "localhost_resolver"
>>> {
>>> match-clients { localhost; };
>>> match-destinations { localhost; };
>> ... more stuff here but I don't think it is relevant
>>> include "/etc/named.d/local/local_zones.conf";
>>> }
>>> view "internal" {
>>> match-clients { 192.168.10.0/24; };
>>>match-destinations { 192.168.10.0/24; };
>>>recursion yes;
>> ... more stuff here but I don't think it is relevant
>>
>>
>>> include "/etc/named.d/internal/internal_zones.conf";
>>> };
>>
>>> view "external" {
>>>match-clients { any; };
>>>match-destinations { any; };
>>>recursion no;
>> ... more stuff here but I don't think it is relevant
>>
>>
>>>include "/etc/named.d/external/external_zones.conf";
>>> };
>> This seems pretty straightforward configuration in named.conf. The
>> configuration of a zone in the external view typically looks like this -
>>
>> zone "mydomain.com" in {
>> file "/etc/named.d/external/master/mydomain.com";
>> type master;
>> allow-transfer { "dnsmadeeasy1"; };
>> also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; };
>> allow-query { any; };
>> allow-update {
>>key "letsencrypt";
>> };
>> };
>>
>> And this is what is in rndc.conf -
>>
>>
>>> key "rndc-key" {
>>> algorithm hmac-md5;
>>> secret "secretkeycodehere";
>>> };
>>> options {
>>> default-key "rndc-key";
>>> default-server localserver;
>>> default-port 953;
>>> };
>>> server localserver {
>>> addresses { 127.0.0.1 port 953; };
>>> key "rndc-key";
>>> };
>>> server intserver {
>>> addresses { 192.168.10.100 port 953; };
>>> key "rndc-key";
>>> };
>>> server extserver {
>>> addresses { xxx.yyy.zzz.aaa
Re: rndc and nsupdate failing to work for me
Hi John, thanks for replying and your thoughts! I will intersperse my
feedback within your comments -
On 03/13/2019 08:33 PM, John W. Blue wrote:
>
> Marc,
>
>
>
> Regarding your rndc problem, I think you might be confusing rndc.
>
>
>
> If rndc is invoked with no options, specifically “k”, then rndc
> assumes the key it needs is in the rndc.conf file. If rndc.conf is
> not present, rndc will use the default rndc.key file. That said,
> since rndc knows there is an /etc/rndc.key file but it choosing to use
> rndc.conf is the secret the same in both places?
>
Yes
>
>
>
> As an option, instead of including /etc/rndc.key nothing prevents you
> from including rndc.conf. That way you are consistent with your useage.
>
I raised an eyebrow at this suggestion thinking oh how cool... but a
quick attempt at including rndc.conf in named.conf lead named to
bellyache about multiple "options" clauses... I will poke at it some
more, as it would be nice to minimize the possibility of getting the two
key definitions out of sync, which is why I tried it from the other
direction using the include statement in rndc.conf...
>
>
>
> I personally do not use nsupdate, but I thought that key file had to
> be created by dnssec-keyen and if you opt to use “k” then the file
> suffix on the command line had to be “.private”.
>
Actually I did use dnssec-keygen to generate the key file! ;-) To be
precise -
> dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST letsencrypt
That generates two files, one is a .key and the other is a .private It
doesn't seem to matter which file I use with nsupdate, it seems happy
with either and both files do contain the private key. In any event, no
matter which I choose the persistence issue remains...
>
>
> Hope that helps and good hunting!
>
At least you confirmed my thinking so far, great minds think alike!
Marc...
>
>
>
> John
>
>
>
> *From:*bind-users [mailto:bind-users-boun...@lists.isc.org] *On Behalf
> Of *Marc Chamberlin via bind-users
> *Sent:* Wednesday, March 13, 2019 6:02 PM
> *To:* bind-users@lists.isc.org
> *Subject:* rndc and nsupdate failing to work for me
>
>
>
> Hello Bind Users,
>
> I have been working on upgrading my Bind 9.11.2 server (running on a
> Linux system, OpenSuSE Leap 15) so that I can accept DNS
> challenges/verification from/for LetsEncrypt certificates, and I am
> running into a wall trying to get nsupdate (and rndc which I wanted to
> use to test the server with) to work with the server. So I hope some
> kind guru here can lead me into the light cuz I am lost
>
> My configuration is really not all that complicated, I am running the
> server on a firewall computer that supports other services such as web
> and email services also. I have a SOHO internal network behind the
> firewall computer. I have configured the Bind (named) server with the
> 3 standard views - localhost.resolver, internal, and external. Since I
> support a number of virtual hosts and real hosts I have quit a few
> zones defined for each view. For regular queries and things like zone
> transfers the server is performing OK.
>
> That said I will show what I think are the relevant definitions from
> my configuration files, with sensitive info redacted of course, and
> follow on with questions I have -
>
> named.conf -
>
> There is a bunch of stuff at the beginning of this file, but I think
> it is irrelevant to this issue. Correct me if I am wrong and I will be
> happy to post it...
>
> include "/etc/rndc.key";
> controls {
> inet * port 953
> allow { any; } keys { "rndc-key"; };
> };
> view "localhost_resolver"
> {
> match-clients { localhost; };
> match-destinations { localhost; };
>
> ... more stuff here but I don't think it is relevant
>
> include "/etc/named.d/local/local_zones.conf";
> }
>
> view "internal" {
> match-clients { 192.168.10.0/24; };
> match-destinations { 192.168.10.0/24; };
> recursion yes;
>
> ... more stuff here but I don't think it is relevant
>
> include "/etc/named.d/internal/internal_zones.conf";
> };
>
> view "external" {
> match-clients { any; };
> match-destinations { any; };
> recursion no;
>
> ... more stuff here but I don't think it is relevant
>
> include "/etc/named.d/external/external_zones.conf";
> };
>
> This seems pretty straightforward configuration in named.conf. The
> configuration of a zone in the external view typicall
rndc and nsupdate failing to work for me
Hello Bind Users,
I have been working on upgrading my Bind 9.11.2 server (running on a
Linux system, OpenSuSE Leap 15) so that I can accept DNS
challenges/verification from/for LetsEncrypt certificates, and I am
running into a wall trying to get nsupdate (and rndc which I wanted to
use to test the server with) to work with the server. So I hope some
kind guru here can lead me into the light cuz I am lost
My configuration is really not all that complicated, I am running the
server on a firewall computer that supports other services such as web
and email services also. I have a SOHO internal network behind the
firewall computer. I have configured the Bind (named) server with the 3
standard views - localhost.resolver, internal, and external. Since I
support a number of virtual hosts and real hosts I have quit a few zones
defined for each view. For regular queries and things like zone
transfers the server is performing OK.
That said I will show what I think are the relevant definitions from my
configuration files, with sensitive info redacted of course, and follow
on with questions I have -
named.conf -
There is a bunch of stuff at the beginning of this file, but I think it
is irrelevant to this issue. Correct me if I am wrong and I will be
happy to post it...
> include "/etc/rndc.key";
> controls {
> inet * port 953
> allow { any; } keys { "rndc-key"; };
> };
> view "localhost_resolver"
> {
> match-clients { localhost; };
> match-destinations { localhost; };
... more stuff here but I don't think it is relevant
> include "/etc/named.d/local/local_zones.conf";
> }
> view "internal" {
> match-clients { 192.168.10.0/24; };
> match-destinations { 192.168.10.0/24; };
> recursion yes;
... more stuff here but I don't think it is relevant
> include "/etc/named.d/internal/internal_zones.conf";
> };
> view "external" {
> match-clients { any; };
> match-destinations { any; };
> recursion no;
... more stuff here but I don't think it is relevant
> include "/etc/named.d/external/external_zones.conf";
> };
This seems pretty straightforward configuration in named.conf. The
configuration of a zone in the external view typically looks like this -
zone "mydomain.com" in {
file "/etc/named.d/external/master/mydomain.com";
type master;
allow-transfer { "dnsmadeeasy1"; };
also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; };
allow-query { any; };
allow-update {
key "letsencrypt";
};
};
And this is what is in rndc.conf -
> key "rndc-key" {
> algorithm hmac-md5;
> secret "secretkeycodehere";
> };
> options {
> default-key "rndc-key";
> default-server localserver;
> default-port 953;
> };
> server localserver {
> addresses { 127.0.0.1 port 953; };
> key "rndc-key";
> };
> server intserver {
> addresses { 192.168.10.100 port 953; };
> key "rndc-key";
> };
> server extserver {
> addresses { xxx.yyy.zzz.aaa port 953; };
> key "rndc-key";
> };
Again, straightforward, and as I said normal queries do work
However when I use rndc to poke at it, this is what happens -
> # rndc showzone mydomain.com in external
> WARNING: key file (/etc/rndc.key) exists, but using default
> configuration file (/etc/rndc.conf)
> rndc: 'showzone' failed: failure
I don't understand why I am getting the warning, seems like a so what
since the keys are identical in both locations. (I couldn't figure out
if it is possible to use an include statement instead of the key
definition in rndc.conf) As for the failure when I asked it to do a
showzone, I don't have a clue as to why this is failing. Log files are
not helpful (and neither is this error message for that matter!)
I am also experiencing problems with nsupdate in that changes I make
with it are not persistent across a restart of the named service. To
demonstrate this I have a file called test.txt -
debug yes
zone mydomain.com.
update add test.mydomain.com. 86400 TXT "bar"
show
send
and if I use it as follows this is what I see -
> # nsupdate -k /etc/letsencrypt/james/Kletsencrypt.+165+56715.key -v
> ./test.txt
I get lots of output and no indication of any problems. Using dig to see
if the update indeed works -
> # dig +short -t txt test.mydomain.com "bar"
> "bar"
it works, but if I restart the named service, no joy -
> # systemctl restart named.service
>
> # dig +short -t txt test.mydomain.com "bar"
>
> #
>
>
the update is not persistent! Any ideas? Thanks in advance for helping
me resolve these issues. Marc...
--
*Computers: the final frontier. These are the voyages of the user Marc.
His mission: to explore strange new hardware. To seek out new software
and new applications.
To boldly go where no Marc has gone before!
*
___
Please visit
