Re: Converting between zone file formats
Hi, I think you can achieve the same effect with dig, but it requires some preparations. First, enable zone transfers for your slave zone from 127.0.0.1: add allow-transfer {127.0.0.1;}; to your slave zone definition (or add 127.0.0.1 there if you already have allow-transfer). Then you can do dig from the same server: dig @127.0.0.1 your.zone AXFR Thus you'll get your slave zone in text format. On 30.01.2023 10:33, Havard Eidnes via bind-users wrote: Hi, by default, the files written by BIND when acting as a slave is not in "text" format, but is some binary file format, I beleive what is referred to as "raw" format. Once in a while it's desireable to be able to see the contents of the slave zone file as plain text. To that end I have previously used named-compilezone to do this with named-compilezone \ -q -j -f raw -F text -o - \ $z \ $directory/$z However... This does not appear to work anymore. Earlier I ran BIND 9.16 on this host, but it has been upgraded to 9.18 (built and installed from local source). It seems that a while back (probably in the 9.16 era), named-compilezone was changed to a symlink to named-checkzone, and it also looks like BIND 9.18 no longer installs named-checkzone, so what I have as named-checkzone appears to come from BIND 9.16. Trying to use the procedure as above results in a named-checkzone which hangs in select(), which is a bit strange when it's only supposed to act on local files?!? What should I now use instead of the above to convert the binary zone file to back to the textual master zone file format? Please don't say "that's not possible"... (This might be important to be able to do if an upstream suffers a catastrophe of some sort, as a step along the path to convert this name server to be a master for the zone in question. Being a master implies being able to modify the zone, and doing that with a binary file is ... slightly inconvenient.) Regards, - Håvard -- Константин Стефанов, Лаборатория параллельных информационных технологий НИВЦ МГУ -- 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: Question About Recursion In A Split Horizon Setup
On 17.04.2020 17:56, Tim Daneliuk wrote: On 4/17/20 9:50 AM, Bob Harold wrote: Agree, that's odd, and not what the man page says. Any chance that there is some other DNS helper running, like resolved, nscd, dnsmasq, etc? Nope. This is vanilla FreeBSD with vanilla bind running. Lately vanilla FreeBSD has unbound as caching and recursive DNS server. Did you turn it off? 'dig' should tell you what address it used, at the bottom of the output - what does it say? ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 ;; MSG SIZE rcvd: 83 Does the SERVER line indicate it's trying to get to the local instance via IPV6 or is this just standard notation? (This is an IPV4 only environment). -- Konstantin Stefanov ___ 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: named.conf Default Location?
On 12.01.2016 20:29, Tim Daneliuk wrote: > I have two FreeBSD 10 machines on which I have installed the bind99 port. > > The manpage for named on machine 1 says that it looks for the named.conf > by default in /usr/local/etc/namedb. Machine 2's manpage says it looks > in /etc/namedb. > > Which is correct? Is the /etc/namedb symlink even needed anymore? Are they freshly installed FreeBSD 10 or were update to ver 10 from 9 or earlier? In FreeBSD 9 there was in-base named which had config at /et/namedb. Maybe the manpage on one of the machines is from earlier versions? Try man -a named.conf and see if there are other vresions of man page. By default bind99 port uses /usr/local/etc/namedb, but it used to have REPLACE_BASE option, which instructed it to use /etc/namedb, so you may check it. -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Identify source of rndc reconfig command?
Hi, Robert. As I understand, something is calling rndc on your localhost. So you may try (untested by me): Find rndc binary, mv rndc rndc.ORIG Replace rndc with script which will execute something like ps fax /tmp/rndc.log then exec rndc.ORIG with the same arguments. Then you will see who invoked your rndc. Don't forget to use full path to rndc.ORIG, as you will never know which current directory will be when your rndc replacement will be executed and what the value of PATH will be. On 25.08.2015 0:01, Robert Senger wrote: Hi all, after upgrading from Debian Wheezy to Jessie, bind9 receives rndc reconfig commands every 30 minutes. I've never seen this before. Some of my own scripts run rndc restart/reload after fiddling with network interfaces, but none of these is the source of the observed 30 minutes interval. There are also no cron jobs. In the bind9 logs I see this: 24-Aug-2015 22:53:43.431 general: info: received control channel command 'reconfig' 24-Aug-2015 22:53:43.458 general: info: loading configuration from '/etc/bind/named.conf' ... [more than 350 lines reconfig log] Running tcpdump on the lo interface gives me this: root@prokyon:/etc/bind# tcpdump -i lo port 953 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes 21:23:35.071602 IP localhost.48466 localhost.953: Flags [S], seq 3862717043, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5], length 0 21:23:35.071699 IP localhost.953 localhost.48466: Flags [S.], seq 2391140312, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 196635776,nop,wscale 5], length 0 21:23:35.071821 IP localhost.48466 localhost.953: Flags [.], ack 1, win 1366, options [nop,nop,TS val 196635776 ecr 196635776], length 0 21:23:35.075355 IP localhost.48466 localhost.953: Flags [P.], seq 1:148, ack 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147 21:23:35.075435 IP localhost.953 localhost.48466: Flags [.], ack 148, win 1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0 21:23:35.115513 IP localhost.953 localhost.48466: Flags [P.], seq 1:180, ack 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 179 21:23:35.115583 IP localhost.48466 localhost.953: Flags [.], ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0 21:23:35.116084 IP localhost.48466 localhost.953: Flags [P.], seq 148:320, ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 172 21:23:35.116130 IP localhost.953 localhost.48466: Flags [.], ack 320, win 1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0 21:23:37.092444 IP localhost.953 localhost.48466: Flags [P.], seq 180:363, ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 183 21:23:37.094097 IP localhost.48466 localhost.953: Flags [F.], seq 320, ack 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0 21:23:37.130367 IP localhost.953 localhost.48466: Flags [.], ack 321, win 1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0 21:23:37.829134 IP localhost.953 localhost.48466: Flags [F.], seq 363, ack 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0 21:23:37.829288 IP localhost.48466 localhost.953: Flags [.], ack 364, win 1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0 Is there a way to identify the source of these reconfig commands? It's really annoying as it messes up the log with 350 useless lines every 30 minutes. Thanks! Robert -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 20:10, /dev/rob0 wrote: On Wed, Mar 18, 2015 at 06:11:56PM +0300, Konstantin Stefanov wrote: On 18.03.2015 17:41, /dev/rob0 wrote: On Wed, Mar 18, 2015 at 11:48:40AM +0300, Constantin Stefanov wrote: I see why it may lead to problems. But in fact the configuration with only one writable file referenced several times is suported now. If I write: view view1 { zone aaa.exampe.org { masters {IP;}; file slave/aaa.exmaple.org; }; }; view view2 { zone aaa.exampe.org { in-view view1; }; }; then both views will refernce ther same writable file, won't they? No. Or am I missing something about in-view directive? Perhaps. The view2 reads zone data from view1, which in turn reads data from the file (and its journal.) Notifies from the master are directed to view1, which does the IXFR or AXFR and writes the And what if notify will arrive from host which is in view2? I just wonder, I don't think there is really a bug. view2 directs it to view1. It's handled as if it came in view1. journal. There is no shared access to a journal. So in fact they both read from the same writable file. Read-only access is not a problem, but in fact only view1 reads the files; view2 asks view1, analogous to a query. View1 already has the entire zone in memory. Zone data changes are written to memory and to the journal at the same time. Only view1 has to worry about the journal, and that only for writing. So there maybe other option to support sibgle-difinition. One is allow defining zone out of views. Now it creates implicit catch-all view and denies other views. But if this out-of-view zone definitions will be considered as included in all views, something like including all zones from outer scope with in-view directive, that will solve the problem. Another, more general option is to allow including one view into another. Which views are allowed to be included is a quiestion. It may be special views which match now clients, or something like that. And including that view means that all zones from it are included into another view as if they were again written with in-view directive. I think one of these options is more easy to develop as basic thing (in-view) is already there. But of course it's up to developers to decided if ant of these is worth of efforts. And thank you for you support. And if I'm right, the only question is how to simplify the configuration so not to have two definitions in two files for every slave zone which is shared between views. I can think of two possible ways to do what you want, each using multiple, separate files for each zone (one file/journal per view.) I don't believe either way exists right now, but perhaps one of these ideas would make a reasonable feature request. The first way would be if a view could have its own directory option set. Then the relative paths in your example above would point to different directories. The ARM is not explicit as to whether or not this is possible, but some simple experimentation would quickly determine the answer. I think ARM is quite explicit that directory is only allowed in 'options' clause. But to be sure I tried to put 'directory' into view and got an error unknown option 'directory' Fair enough. I would have tested, but didn't have time. The second way definitely does NOT exist, and that would be to have some kind of variable in the named.conf syntax to refer to the name of the current view. I thought of the same options, if you look at my message Matus UHLAR (and the second suggestion was in my message which started the thread). Yes, I saw that. But I think that would be a more radical change, thus less likely to make it into the BIND 9.10 tree. But I do not have needed skills to implement it myself. Mark does, and if he thinks either is a good idea, he might. :) -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 13:22, Matus UHLAR - fantomas wrote: On 18.03.15 12:05, Constantin Stefanov wrote: I can't. It stopped working after upgrade to 9.10, but worked before with 9.6. And the question is how to keep the config as simple as it was before upgrade. I mean, the in-view definitions... On 18.03.15 13:10, Konstantin Stefanov wrote: So now I have to have two definitions for every slave zone in different files. Well, it is the thing I did, but I do not like it. Requirement to have 2 synced definitions in 2 different places leads to bugs. and what did you have before? multiple definitions of the same zones with the same filenames, which leads to bugs (although you were lucky not to encounter them) Yes, I was lucky and everything worked for me as I thought it had to be. now you can have: definitions of zones with filename in one general view file with definitions of zones with in-view. multiple inclusions of the file in multiple views. And now I am unlucky as I have to make my cofig more complex, confusing and bug-prone to achieve the same effect. But I'm lucky enough to have three options to choose how to spoil my config. the only other way is stop using views... ... you still can stop using views. And I can still stop using DNS. If I only could stop using views, I would not ask the question. -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 13:02, Matus UHLAR - fantomas wrote: On 18.03.15 11:48, Constantin Stefanov wrote: then both views will refernce ther same writable file, won't they? Or am I missing something about in-view directive? On 18.03.2015 11:56, Matus UHLAR - fantomas wrote: maybe you could put all those zone definitions into one file and include it in each view. On 18.03.15 12:05, Constantin Stefanov wrote: I can't. It stopped working after upgrade to 9.10, but worked before with 9.6. And the question is how to keep the config as simple as it was before upgrade. I mean, the in-view definitions... So now I have to have two definitions for every slave zone in different files. Well, it is the thing I did, but I do not like it. Requirement to have 2 synced definitions in 2 different places leads to bugs. the only other way is stop using views... -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 16:12, Lightner, Jeff wrote: It isn't really that hard to maintain two separate zone files for each domain. We've been doing it for years. It isn't. But maintaining one file is easier. And having to maintain two after five years everything worked fine with one is annoying. It isn't really clear why you're using views if all your zone files are the same as you seem to imply. Here we do views specifically because for some domains the zone files DO need to be different between internal and external views. While others are the same as I noted before it is very easy to simply edit one file then copy it to the other. Not all my zones are identical, but most, and there is quite a bunch of them. The problem is that two files for identical zones can't be the same as they used to be. They must differ in file names for slave zone caches, or have 'in-view' directive. So simply copying does not work, otherwise 'include' would work fine. -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Konstantin Stefanov Sent: Wednesday, March 18, 2015 6:31 AM To: bind-users@lists.isc.org Subject: Re: Single slave zone definition for two view (cache file name problem) On 18.03.2015 13:22, Matus UHLAR - fantomas wrote: On 18.03.15 12:05, Constantin Stefanov wrote: I can't. It stopped working after upgrade to 9.10, but worked before with 9.6. And the question is how to keep the config as simple as it was before upgrade. I mean, the in-view definitions... On 18.03.15 13:10, Konstantin Stefanov wrote: So now I have to have two definitions for every slave zone in different files. Well, it is the thing I did, but I do not like it. Requirement to have 2 synced definitions in 2 different places leads to bugs. and what did you have before? multiple definitions of the same zones with the same filenames, which leads to bugs (although you were lucky not to encounter them) Yes, I was lucky and everything worked for me as I thought it had to be. now you can have: definitions of zones with filename in one general view file with definitions of zones with in-view. multiple inclusions of the file in multiple views. And now I am unlucky as I have to make my cofig more complex, confusing and bug-prone to achieve the same effect. But I'm lucky enough to have three options to choose how to spoil my config. the only other way is stop using views... ... you still can stop using views. And I can still stop using DNS. If I only could stop using views, I would not ask the question. -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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 -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 16:55, Steven Carr wrote: On 18 March 2015 at 13:30, Konstantin Stefanov cs...@parallel.ru wrote: It isn't. But maintaining one file is easier. And having to maintain two after five years everything worked fine with one is annoying. This highlights the need for a test environment, don't apply untested updates to production systems, it'll help you avoid running into issues like this where something in the product has changed and then you're forced to cobble together an ad-hoc solution to just fix it on-the-fly. Did I say it is happening in production? I think I didn't, because it is a copy to test the upgrade, production is still running OK with 9.6. Not all my zones are identical, but most, and there is quite a bunch of them. The problem is that two files for identical zones can't be the same as they used to be. They must differ in file names for slave zone caches, or have 'in-view' directive. So simply copying does not work, otherwise 'include' would work fine. Not sure whether BIND would detect this or not but what about using a hard link? Underlying file would be the same but filenames different (though with the caveat of these should be read-only master zones, no DDNS, not a slave zone) The issue is that named started to detect it since, if I'm not mistaken, 9.7. It happened because such config was leading to bugs, but instead of fixing the bugs, the whole feature was prohibited. Hardlinks is not a solution. I do not care about additional disk space, what I care about is the need to have two configs with different file names (again the case with hardlinks) instead of one as it was with 9.6 -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 17:41, /dev/rob0 wrote: On Wed, Mar 18, 2015 at 11:48:40AM +0300, Constantin Stefanov wrote: I see why it may lead to problems. But in fact the configuration with only one writable file referenced several times is suported now. If I write: view view1 { zone aaa.exampe.org { masters {IP;}; file slave/aaa.exmaple.org; }; }; view view2 { zone aaa.exampe.org { in-view view1; }; }; then both views will refernce ther same writable file, won't they? No. Or am I missing something about in-view directive? Perhaps. The view2 reads zone data from view1, which in turn reads data from the file (and its journal.) Notifies from the master are directed to view1, which does the IXFR or AXFR and writes the And what if notify will arrive from host which is in view2? I just wonder, I don't think there is really a bug. journal. There is no shared access to a journal. So in fact they both read from the same writable file. Yes, technically only one write reference for the file is there, others are just reading, but the result is the same: one writable file is used for one zone in several views. Of course it is a much more simpler design for developers, than to allow concurrent writes. And if I'm right, the only question is how to simplify the configuration so not to have two definitions in two files for every slave zone which is shared between views. I can think of two possible ways to do what you want, each using multiple, separate files for each zone (one file/journal per view.) I don't believe either way exists right now, but perhaps one of these ideas would make a reasonable feature request. The first way would be if a view could have its own directory option set. Then the relative paths in your example above would point to different directories. The ARM is not explicit as to whether or not this is possible, but some simple experimentation would quickly determine the answer. I think ARM is quite explicit that directory is only allowed in 'options' clause. But to be sure I tried to put 'directory' into view and got an error unknown option 'directory' The second way definitely does NOT exist, and that would be to have some kind of variable in the named.conf syntax to refer to the name of the current view. I thought of the same options, if you look at my message Matus UHLAR (and the second suggestion was in my message which started the thread). But I do not have needed skills to implement it myself. -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 17:18, Matus UHLAR - fantomas wrote: rOn 18.03.15 17:10, Konstantin Stefanov wrote: The issue is that named started to detect it since, if I'm not mistaken, 9.7. It happened because such config was leading to bugs, but instead of fixing the bugs, the whole feature was prohibited. those bugs _were_ fixed: the in-view statement and prevention from using the same file multiple times (I remember discussion about issues coming from those here on the list). you are complaining about your broken configuration worked. Sorry, I gave up arguing with you. Indeed, my configuration worked although broken. And now I can't make the configuration as simple. Yes, the new 'in-view' makes the config possible, but allowing simple configuration is a valuable feature in my view. Look at masters lists. You may write any config without it, simply by repeating the same IPs where needed. But is masters lists a feature? Ceratinly it is, it makes configuration easier and more maintainable. The same is with my broken config. I am now able to have correct config by repeating slave zones descrition twice. But the feature 'ability to have only one description of common slave zones' is now lost. And 'in-view' is not a substitution, as it again requires two different description for one zone. I'm trying to convey that in my view the feature here is not what 'in-view' solves. For me the feature that is lost allowed me to have neat config. A substitute could be, for example, some variable with view name to use in file directive. If I could write somesthing like zone aaa { type slave; file aaa.$viewname; }; that would allow me to write simple config again. Other variants are possible, for example allowing different 'directory' option setting for different views, as it again making possible to point to different files with the same line. I see developers' point and understand why reference to a zone (in-view) is easier to program and debug than finding when referencing two writable files is correct and when it is not, and programming checks. And disabling referencing two writable files seems to be clever way, especially since there is new 'in-view' feature. For me as an user 'in-view' make sense with three or more views (than I would have two descriptions, one full and one with in-view) for any number of view. But in case of two views (my case) in-view feature gives almost nothing. I still have to have two files, and waht difference: two with different filenames or one with filename and one with in-view. The script for the first case is even simpler. So again, for me the feature that worked is lost without any equal substitute. If you think that feature is of no real worth - OK, I don't know if having exactly two views with a load of identical zones is a frequent case. But the only thing I want to say - that there was a feature that is now lost. Maybe that feature existed only by an oversight, but I used it for five years, and it worked (for me, again). And thanks for spending your time. -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 18:37, Reindl Harald wrote: Am 18.03.2015 um 16:31 schrieb Konstantin Stefanov: I wrote earlier and may repeat again. The feature for me is not using the same file, the feature is having a clear and maitainable config. In this case it means to have only one description for a zone. did you ever consider provisioning your configs template based? shouldn't be too hard to implement with a small sql database and a nice webinterface, we do that to automatically add no-mail SPF, null-MX, honeypot-backup-mx and what not for years with great success It's a definite overkill for me. I was quite happy with manually editing text configs several times a year. Now I'll write a script and will be a little less happy, but SQLs, webinterfaces, honeypots... No and no, I do not need it at all. ___ 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 -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ 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