Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On 3/17/19 6:31 PM, Alan Clegg wrote: The change was an unintended consequence ending up in what was thought to have been the correct behavior all along, so.. Yes. How many zones are you authoritative for? I think most people on this list have forgotten how to count as low as the number of zones that I am authoritative for. Would it be a major difficulty to (once) change the existing zones and then modify your provisioning to add the "allow-update" option in the zone stanza? "difficult", no. "annoying", maybe. So what. I make the change and move on. Ford Pinto Automobiles weren't meant to burst into flames when hit from the rear either, but ... yeah, not really to the same level, but again, I'm interested in how many people (and how big their zone lists are) would have an issue with a one-time change. When you say VERY CLEARLY communicated, to what level would you raise this communication? Would you consider having it in the release notes good enough? Arguably, release notes SHOULD be good enough. (Should as in RFC sense.) Very clearly is more an easy to find official documentation location. I think release notes qualify. I remember when the "allow-recursion" default ACL was changed from "any" to "localhost; localnets;" and a few people (big networks) didn't read the release notes... yeah, even if you have things well documented, somebody is going to get roasted because they don't read the release notes. Agreed. In some ways "(very) clearly" is in the eyes of the beholder that is recovering from not doing things correctly. Will they accept release notes as sufficient. I can't speak for others. I can say that even if I didn't read it before hand, and I did after the fact, I'd grump, but know that I was the one in error, fix said error, and move on with life. And when 9.14.0 is released, you'll definitely know what it is, but I'm hoping to have something to tell you before then. ;-) :-) If we (ISC) base our changes on what we've gotten in response to the surveys, we will make changes based on the fact that nearly all of the somewhere around 20 people that use BIND are using Solaris. Well, I'm the 21st then, and I'm using Linux. :-D Not enough people actually respond to our surveys to base any real changes on the results. :-( Please, to EVERYONE on the list, when you see a survey from us, help us to make the experience that you are having with BIND better by filling out the survey. :-) If anyone can tell me why we have such low response rates to our surveys, please let me know that as well... WE NEED YOUR INPUT. No, the misfortune here is that if we DON'T put it in now, we will have to wait for 9.16.0. I'm guessing that if it goes into 9.14.0, it won't be coming back out - there will be the "moment of pain" when people change to the new option structure and then "voila", it's all over. Agreed. To change the current "we don't allow allow-updates in global options" at this point will require a code change. We are in code-freeze, so to revert to the other behavior will delay the release of BIND 9.14.0. Sounds like the ship has already sailed then. I agree that it has worked that way in the past, however, I do not consider it to be non-trivial from the operations perspective. Fair. I was saying non-trivial in the sense that the change could have a sizeable impact. Especially if BIND failed to start because of a long standing config stanza. It may be that a low level SA is applying OS updates, including BIND, to systems and all of the sudden (when people didn't do their homework) BIND will no longer start. So now said SA needs to escalate to the DNS SME to resolve the problem. A simple "awk" script should be able to make the required change across the board in a few seconds. Maybe. Depending on what the configuration file(s) look like. Yes, see above comment about surveys. ACK If you read the release notes prior to installing 9.14.0, you will know that you need to change the location of the allow-updates option. If, after breaking things because the default behavior changed and you hadn't read the release notes, you can then read the release notes, and you will know why it broke. Agreed. The error generated by named-checkconf is: /etc/namedb/named.conf:19: 'allow-update' can only be set per-zone, not in 'options' I think that's pretty clear even if you don't read the release notes. BIND creates this log message when "rndc reconfig" is run: 18-Mar-2019 00:15:29.081 general: info: received control channel command 'reconfig' 18-Mar-2019 00:15:29.081 general: info: loading configuration from '/etc/namedb/named.conf' 18-Mar-2019 00:15:29.082 config: error: /etc/namedb/named.conf:19: 'allow-update' can only be set per-zone, not in 'options' 18-Mar-2019 00:15:29.082 general: error: reloading configuration failed: failure again, quite clear on the cause for the failure. If starting (as will b
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On 3/17/19 5:52 PM, Grant Taylor via bind-users wrote: > On 3/17/19 2:37 PM, Alan Clegg wrote: >> It turns out that this series of changes, taken as a whole, removed >> allow-update as a global option. > > That sounds like either an unintended consequence -or- a change in > anticipated ~> expected behavior by some people. The change was an unintended consequence ending up in what was thought to have been the correct behavior all along, so.. Yes. >> The question now becomes: Is there a need for the ability to apply >> allow-update across all zones in your configuration? > > I use allow-update at the global options level. How many zones are you authoritative for? Would it be a major difficulty to (once) change the existing zones and then modify your provisioning to add the "allow-update" option in the zone stanza? >> Smaller operators should be able to add the allow-update per zone very >> easily, and large operators should (probably) be doing things at a >> much more granular level. > > Can I add allow-update per zone? Yes. > > Will I be annoyed at needing to add the allow-update to each zone? Yes. > > Even if the allow-update wasn't intended to function at the global > options level, the point remains that it has done so and the current > expected behavior is that it will continue to do so. Ford Pinto Automobiles weren't meant to burst into flames when hit from the rear either, but ... yeah, not really to the same level, but again, I'm interested in how many people (and how big their zone lists are) would have an issue with a one-time change. > So, if there is an official change to the contrary of the unofficial > behavior, I think that it needs to be VERY CLEARLY communicated. When you say VERY CLEARLY communicated, to what level would you raise this communication? Would you consider having it in the release notes good enough? I remember when the "allow-recursion" default ACL was changed from "any" to "localhost; localnets;" and a few people (big networks) didn't read the release notes... yeah, even if you have things well documented, somebody is going to get roasted because they don't read the release notes. >> I'm sure that there will be internal discussion here at ISC regarding >> this topic over the next week. > > Good. > > I look forward to hearing what the general consensus is. And when 9.14.0 is released, you'll definitely know what it is, but I'm hoping to have something to tell you before then. ;-) > If the consensus is that the new behavior is desired, I would hope ~> > expect for a survey of the BIND user community like I've seen in the > past about removing / significantly altering functionality. If we (ISC) base our changes on what we've gotten in response to the surveys, we will make changes based on the fact that nearly all of the somewhere around 20 people that use BIND are using Solaris. Not enough people actually respond to our surveys to base any real changes on the results. Please, to EVERYONE on the list, when you see a survey from us, help us to make the experience that you are having with BIND better by filling out the survey. If anyone can tell me why we have such low response rates to our surveys, please let me know that as well... WE NEED YOUR INPUT. >> We are hoping to release 9.14.0 soon and this would be an "allowed" >> change (at a .0 release). If we don't make this change in 9.14.0, it >> won't be allowed in an official production release until 9.16.0 due to >> the "no changes to the configuration file except at .0 releases" rule. > > Hum. I'd hate to think that do to misfortune of timing, we'd be stuck > with this unexpected / inconsistent with prior version behavior until > 9.16.0 came out. No, the misfortune here is that if we DON'T put it in now, we will have to wait for 9.16.0. I'm guessing that if it goes into 9.14.0, it won't be coming back out - there will be the "moment of pain" when people change to the new option structure and then "voila", it's all over. To change the current "we don't allow allow-updates in global options" at this point will require a code change. We are in code-freeze, so to revert to the other behavior will delay the release of BIND 9.14.0. >> At this moment, I (personally) believe that the change is fixing a >> bug, as "allow-update" was not planned and is not a good idea at the >> global option level. I believe that it should be allowed only in zone >> stanzas. > > Opinions aside, the fact is that it has worked as a global option > historically and this is a non-trivial change in behavior. I agree that it has worked that way in the past, however, I do not consider it to be non-trivial from the operations perspective. A simple "awk" script should be able to make the required change across the board in a few seconds. > I might not like such a change. But I'm okay accepting such a change if > they are properly communicated. (See above comment about survey.) Yes, see above comment about surveys. > I k
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On 3/17/19 5:48 PM, @lbutlr wrote: I disagree. I'd prefer the best decision be made by consensus of the contributors rather than the community at large. I agree that the decision should be made by the contributors / maintainers. I'm saying that I think they should have data / information / opinions from the community while making their independent decision. There is no guarantee that the decision will, or even should, match what the community thinks. The community includes a lot of people with a barely functioning understanding of DNS and no basis in knowledge for making a qualified decision as to if this is a good thing or not. Fair. But they can still provide opinions / information / data that the contributors can use when they make their decision. I know this, because this describes me (and everyone I've met in person who has to deal with DNS) pretty accurately. I suspect you should give yourself more credit. You know that you don't know everything. I have dealt with too many people that don't even know that. So you've got a leg up on them. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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-update in global options (was Re: bind and certbot with dns-challenge)
On 17 Mar 2019, at 15:52, Grant Taylor via bind-users wrote: > If the consensus is that the new behavior is desired, I would hope ~> expect > for a survey of the BIND user community like I've seen in the past about > removing / significantly altering functionality. I disagree. I'd prefer the best decision be made by consensus of the contributors rather than the community at large. The community includes a lot of people with a barely functioning understanding of DNS and no basis in knowledge for making a qualified decision as to if this is a good thing or not. I know this, because this describes me (and everyone I've met in person who has to deal with DNS) pretty accurately. -- "I program Windows - of course it isn't safe." - Meski ___ 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-update in global options (was Re: bind and certbot with dns-challenge)
Data points: I saw another report of this issue on gitlab - #913 just after my previous note. It indicated that a distributions initial configuration breaks with the change. I see that it has been updated by Alan since. I checked my configuration files. I use allow-update-forwarding at the options level. I use update-policy at the zone level. I don't currently use either at the view level. So my configurations would break. (I haven't had the cycles to run 9.13, unfortunately for you - apparently, fortunately for me :-) I don't see the serious harm in allowing these options to be inherited - there are certainly other options that, if incorrectly/accidentally inherited, could be dangerous. Allow-transfer; allow-query, deny-answer-* I could go on alphabetically, but I'm pretty sure a case could be made for the majority of options causing mischief if inadvertently inherited. I'm curious about why these particular options were singled out -- yes, they update persistent zone data. But denial of service, information leaks, and using the wrong directories can also be serious. In any case, where a change is made that invalidates existing configurations, I strongly prefer a deprecation warning at least one (non-development) release prior. With documentation. Given that these prerequisites didn't happen in this case, I believe that regardless of the merits, the previous behavior should be reinstated. If there is a determination that the benefits of the change outweigh the costs, then add a deprecation warning a stable release prior (perhaps now?) and update the documentation -- including the ARM & release notes. Also, the same arguments should be applied to all the other inheritable options -- if there is justification for other changes, it's much better to force operators to make a bundled set of changes than to dribble them out piecemeal. FWIW: In general, I choose to place configuration statements at the level resulting in the shortest configuration. (Not for performance, but for clarity/ease of maintenance.) So that's sometimes "global enable, exception disable", and sometimes the inverse. (This can be frustrated when there's no obvious inverse to a directive, but that's for another day.) Finally, I looked at the 9.13 ARM for a list of which options are allowed in the view statement. The view Statement Grammar lists [view_option; ...] - 'view_option' appears nowhere else in the ARM. The definition and usage section (in chapter 5) says only: "Many of the options given in the *options* statement can also be used within a *view* statement,". To find an explicit list, one has to go to the VIEW section of chapter 8 (the man page for named.conf) - which isn't tagged with 'view_option'. This frustrates searchers and people unfamiliar with the ARM structure. Note that allow-update and allow-update-forwarding both appear as valid in the view syntax there, although in chapter 5 the descriptions on p.97 says "only zone, not options or view". My 3.5¢ (USD, but your local currency will do :-) Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 17-Mar-19 16:37, Alan Clegg wrote: > On 3/17/19 2:51 PM, Alan Clegg wrote: >> On 3/17/19 7:13 AM, Stephan von Krawczynski wrote: >>> Hello all, >>> >>> I am using "BIND 9.13.7 (Development Release) " on arch linux. >>> Up >>> to few days ago everything was fine using "certbot renew". I had >>> "allow-update" in nameds' global section, everything worked well. Updating >>> to >>> the above version threw a config error that "allow-update" has no global >>> scope >>> and is to be used in every single zone definition. >> And you may have found a bug. I'm checking internally at this time. > So, after a discussion with one of the BIND engineers this afternoon, > this turned out to be quite an interesting and deep-rooted issue. > > During a cleanup of other code (specifically named-checkconf), code was > changed that enforced what was believed to have been the default > previously: specifically, allow-update was only allowed in zone stanzas. > The chain of changes follows: > > 5136. [cleanup] Check in named-checkconf that allow-update and > allow-update-forwarding are not set at the > view/options level; fix documentation. [GL #512] > > This, if the change remains, will be updated to [func] and additional > documentation will be added to the release notes. > > The other changes down this long and twisting passage are: > > 4836. [bug] Zones created using "rndc addzone" could > temporarily fail to inherit an "allow-transfer" > ACL that had been configured in the options > statement. [RT #46603] > > and > > 2373. [bug] Default values of zone ACLs were re-parsed each >tim
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On 3/17/19 2:37 PM, Alan Clegg wrote: It turns out that this series of changes, taken as a whole, removed allow-update as a global option. That sounds like either an unintended consequence -or- a change in anticipated ~> expected behavior by some people. The question now becomes: Is there a need for the ability to apply allow-update across all zones in your configuration? I use allow-update at the global options level. Smaller operators should be able to add the allow-update per zone very easily, and large operators should (probably) be doing things at a much more granular level. Can I add allow-update per zone? Yes. Will I be annoyed at needing to add the allow-update to each zone? Yes. Even if the allow-update wasn't intended to function at the global options level, the point remains that it has done so and the current expected behavior is that it will continue to do so. So, if there is an official change to the contrary of the unofficial behavior, I think that it needs to be VERY CLEARLY communicated. I'm sure that there will be internal discussion here at ISC regarding this topic over the next week. Good. I look forward to hearing what the general consensus is. If the consensus is that the new behavior is desired, I would hope ~> expect for a survey of the BIND user community like I've seen in the past about removing / significantly altering functionality. We are hoping to release 9.14.0 soon and this would be an "allowed" change (at a .0 release). If we don't make this change in 9.14.0, it won't be allowed in an official production release until 9.16.0 due to the "no changes to the configuration file except at .0 releases" rule. Hum. I'd hate to think that do to misfortune of timing, we'd be stuck with this unexpected / inconsistent with prior version behavior until 9.16.0 came out. At this moment, I (personally) believe that the change is fixing a bug, as "allow-update" was not planned and is not a good idea at the global option level. I believe that it should be allowed only in zone stanzas. Opinions aside, the fact is that it has worked as a global option historically and this is a non-trivial change in behavior. I might not like such a change. But I'm okay accepting such a change if they are properly communicated. (See above comment about survey.) If you have thoughts/opinions, please let us know! See inline above. I know that my few small BIND instances are a pitance compared to many. But I would be quite annoyed to learn that my long stable config suddenly no longer worked after updating BIND. Especially if I didn't know why my config no longer worked or what I needed to do to fix it. This could be even worse if the failure is not detected quickly and instead lingers for a few days / weeks before the lack of an update ended up breaking DNS resolution in a production environment. I share this as a joke and don't mean to ruffle any feathers. https://memegenerator.net/img/instances/84240115/bug-fixed-ops-problem-now.jpg -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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-update in global options (was Re: bind and certbot with dns-challenge)
On 3/17/19 2:51 PM, Alan Clegg wrote: > On 3/17/19 7:13 AM, Stephan von Krawczynski wrote: >> Hello all, >> >> I am using "BIND 9.13.7 (Development Release) " on arch linux. Up >> to few days ago everything was fine using "certbot renew". I had >> "allow-update" in nameds' global section, everything worked well. Updating to >> the above version threw a config error that "allow-update" has no global >> scope >> and is to be used in every single zone definition. > > And you may have found a bug. I'm checking internally at this time. So, after a discussion with one of the BIND engineers this afternoon, this turned out to be quite an interesting and deep-rooted issue. During a cleanup of other code (specifically named-checkconf), code was changed that enforced what was believed to have been the default previously: specifically, allow-update was only allowed in zone stanzas. The chain of changes follows: 5136. [cleanup] Check in named-checkconf that allow-update and allow-update-forwarding are not set at the view/options level; fix documentation. [GL #512] This, if the change remains, will be updated to [func] and additional documentation will be added to the release notes. The other changes down this long and twisting passage are: 4836. [bug] Zones created using "rndc addzone" could temporarily fail to inherit an "allow-transfer" ACL that had been configured in the options statement. [RT #46603] and 2373. [bug] Default values of zone ACLs were re-parsed each time a new zone was configured, causing an overconsumption of memory. [RT #18092] It turns out that this series of changes, taken as a whole, removed allow-update as a global option. The question now becomes: Is there a need for the ability to apply allow-update across all zones in your configuration? Smaller operators should be able to add the allow-update per zone very easily, and large operators should (probably) be doing things at a much more granular level. I'm sure that there will be internal discussion here at ISC regarding this topic over the next week. We are hoping to release 9.14.0 soon and this would be an "allowed" change (at a .0 release). If we don't make this change in 9.14.0, it won't be allowed in an official production release until 9.16.0 due to the "no changes to the configuration file except at .0 releases" rule. At this moment, I (personally) believe that the change is fixing a bug, as "allow-update" was not planned and is not a good idea at the global option level. I believe that it should be allowed only in zone stanzas. If you have thoughts/opinions, please let us know! Alan Clegg, ISC ___ 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 and certbot with dns-challenge
On 3/17/19 7:13 AM, Stephan von Krawczynski wrote: > Hello all, > > I am using "BIND 9.13.7 (Development Release) " on arch linux. Up > to few days ago everything was fine using "certbot renew". I had > "allow-update" in nameds' global section, everything worked well. Updating to > the above version threw a config error that "allow-update" has no global scope > and is to be used in every single zone definition. And you may have found a bug. I'm checking internally at this time. > And this brought me here with one question: why is it that bind/named does not > evolve to a really useable nameserver for the most use-cases _today_, but > instead gets more unusable with every new release? Please provide input. BIND is open source and is available for requests etc. via gitlab. We don't INTENTIONALLY make it "more unusable with each release, but without your input we may be doing things that seem good from the implementation side, but not from the operations side. Provide input! You'll help shape the world! > I mean, sure you can use it perfectly, only not good if hosting hundreds or > thousands domains - only this small change I just described lets your config > file grow massively -, only not good if you want to implement something like > blacklists, not good for an adblocker and so on. I'm not sure how this relates. Please feel free to follow up here (on in Gitlab) with a bit more including "this configuration worked great and is operationally what we need, but you broke it. We do take constructive criticism (and we also have thick skins, having been at it as long as we have). > But all that would be dead easy to do, iff really wanted. > So why is it, that there is no global way of defining default zone > definitions which are only overriden by the actual zone definition? Some options just don't make sense at the global level. Those are only available at the view or zone level. > Why is there no way to define a hosts-type-of-file with an URL-to-IP list? Because DNS data only deals with DNS data and not URLs? Again, give an example of what you want, it will be considered and may actually appear as a feature in future releases. (this one, I doubt, however). > Do you really want people to define 50.000 zones to perform adblocking? > Configs have to be reloaded every now and then, is there really no idea how to > shorten things a bit? RPZ works at a global level. Again, not sure what this question means. > Don't get me wrong, bind is great (ok, collapsing during runtime since last 2 > updates, but ...). Did you report these "collapses"? This is the type of thing that tends to happen when your distribution runs "Development Release" code. > Nevertheless there are some things that can be enhanced quite a bit. Tell us! Help us! Together we can be stronger! Alan Clegg, ISC ___ 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 and certbot with dns-challenge
Named has options at the global, view and zone levels. The 9.11 ARM shows allow-update in the options and zone statements. If it's broken in 9.13 - note that it is a "Developement Release". So bugs are expected, and you should raise an issue on bind9-bugs or on gitlab (https://gitlab.isc.org/isc-projects/bind9/issues). You can work around your issue by using 'include "my-common-stuff.conf";' to simplify your configuration. This is a useful strategy for things that don't fit the three-level model. If you have large zones, you can speed up load time with masterfile-format raw or map; see the "tuning" section of the ARM for more information. Parsing configuration data is unlikely to be the dominant factor in startup, but I'm sure that the developers would welcome a reproducible test case that shows otherwise. You should consider update-policy instead of allow-update; it provides much better control and better security. > It is really very obvious that this is only done by > ideologists, not technical oriented people. Actually, I've found that the contributors to named are very technical, practical people. Sometimes they introduce bugs, or ideas that work in one context but not another. They're responsive to criticism & contributions. But name-calling is generally not an effective way to get anyone to help you. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 17-Mar-19 10:35, Stephan von Krawczynski wrote: > On Sun, 17 Mar 2019 12:40:35 +0100 > Reindl Harald wrote: > >> Am 17.03.19 um 12:13 schrieb Stephan von Krawczynski: >>> So why is it, that there is no global way of defining default zone >>> definitions which are only overriden by the actual zone definition? >> maybe because it brings a ton of troubles and whoever deals with more >> than 5 zones has automatic config management in place anyways? > If you don't want to follow the positive way (how about a nice additional > feature), then please accept the negative way: someone broke the config > semantics by implementing a zone based-only "allow update". This option worked > globally before (too), so we can assume it is in fact broken now. > Can someone please point me to the discussion about this incompatible change? > >>> Why is there no way to define a hosts-type-of-file with an URL-to-IP list? >>> Do you really want people to define 50.000 zones to perform adblocking? >> no, just use the right tool for the task, this don't fit into the domain >> concept of named and hence you have dnsmasq and rbldnsd to step into >> that niche > In todays' internet this is no niche any more. And the right tool means mostly > "yet-another-host" because you then need at least a cascade of two, one for > dnsmasq and one for bind/named. A lot of overhead for quite a simple task... > >>> Configs have to be reloaded every now and then, is there really no idea >>> how to shorten things a bit? >> ?? > Shorter config = shorter load time. The semantic change of "allow update" > alone > leaves every setup with 1000 domains in a situation where 999 config statments > more have to be read, interpreted and configured - just to end up in the same > runtime setup. It is really very obvious that this is only done by > ideologists, not technical oriented people. > signature.asc Description: OpenPGP digital signature ___ 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 and certbot with dns-challenge
On 3/17/19 8:35 AM, Stephan von Krawczynski wrote: In todays' internet this is no niche any more. Oh, there most certainly are niches today. I think there are more today than there were before. And the right tool means mostly "yet-another-host" because you then need at least a cascade of two, one for dnsmasq and one for bind/named. A lot of overhead for quite a simple task... No, you don't need another host. · You can do things on different ports and / or IPs on the same host. · You can use different BIND features to do exactly what you want in a single daemon. (See my previous email about RPZ / RPS / DLZ.) Shorter config = shorter load time. The semantic change of "allow update" alone leaves every setup with 1000 domains in a situation where 999 config statments more have to be read, interpreted and configured - just to end up in the same runtime setup. See my previous email about load time. TL;DR: The config isn't the problem. The zones are the problem. It is really very obvious that this is only done by ideologists, not technical oriented people. I disagree. I've seen similar breaking changes in other products for (usually) well published / documented reasons. Often times it's related to blocking new more important features and / or problems maintaining legacy code and / or security implications. None of that is ideology. That's program maintenance. That being said, I don't know what is the case in the (broken) global allow-updates issue that you're talking about. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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 and certbot with dns-challenge
On 3/17/19 5:13 AM, Stephan von Krawczynski wrote: Hello all, Hi, I am using "BIND 9.13.7 (Development Release) " on arch linux. Up to few days ago everything was fine using "certbot renew". I had "allow-update" in nameds' global section, everything worked well. Updating to the above version threw a config error that "allow-update" has no global scope and is to be used in every single zone definition. That sounds like a bug to me. If it's not a bug, and is to be expected, I would expect the change in behavior to be documented somewhere. And this brought me here with one question: why is it that bind/named does not evolve to a really useable nameserver for the most use-cases _today_, but instead gets more unusable with every new release? I can't say as I've experienced what you're referring to. I still find BIND to be extremely flexible and feature rich for all of my DNS needs. There are occasionally some off the typical DNS path things that I want to do that do require some pontification and careful implementation. But I've almost always been able to get BIND to do what I want. Maybe once or twice I couldn't in the last ~20 years. I mean, sure you can use it perfectly, only not good if hosting hundreds or thousands domains Why can't you use BIND to host hundreds or thousands of domains? only this small change I just described lets your config file grow massively Config file size is independent of BIND's capability. IMHO, this seems more like a dislike than an actual problem. only not good if you want to implement something like blacklists, not good for an adblocker and so on. Why is it not good? What can you not do with BIND 9.13.7 that you could do with a previous version? Also, /seriously/ take a good look into Response Policy Zones (RPZ). They make implementing blacklists a LOT easier. I expect that Response Policy Service (RPS) to also make a similar, if not bigger, difference. - Granted, there is a documentation / OSS implementation gap that I'd like to see filled. I also think that Dynamically Loadable Zones (DLZ) can also help here. That's three different options that can be used with BIND. I think all three can make it such that you don't need to define zones for each of the names that you want to filter. But all that would be dead easy to do, iff really wanted. I'm not sure what "all that" actually is. As such, I'll respond to the multiple things that I think it could be. "global allow-update…" - This sounds like a bug or an unknown design change. "host hundreds or thousands of domains" - I see no reason why BIND can't do that. "config file growth" - So. Look into "include" and / or "DLZ". Restructure your config such that it's easier to manage and don't use a flat file. "blacklists" - I'm doing this with multiple DLZs and am extremely happy with it. IMHO it works wonderfully. I'm even taking a web page (listing bad hosts) that someone is serving (for public consumption) scraping it (with their consent) and turning it into an RPZ on one server. Then I'm using standard zone transfers to have multiple recursive resolvers filter based on the contents of the Response Policy Zone. IMHO it works great. So why is it, that there is no global way of defining default zone definitions which are only overriden by the actual zone definition? I think that's a fair question. Perhaps it's worth a feature request. I've not looked, but I wonder if some of this can be defined via views. Why is there no way to define a hosts-type-of-file with an URL-to-IP list? I think that RPZ, RPS, and likely DLZ are much closer to doing that than you realize. I counter with this. Q: Why can't Firefox on Linux read a Microsoft Word (.doc) file? A: Because it's not designed to do so. A: Nor is doing so even remotely in the scope of what it's designed to do. Do you really want people to define 50.000 zones to perform adblocking? You don't need to do that. Again, /seriously/ take a good look into Response Policy Zones (RPZ). They make implementing blacklists a LOT easier. Configs have to be reloaded every now and then, is there really no idea how to shorten things a bit? It's my understanding that parsing the config file(s) is not the problem / delay. It's my understanding that the delay in loading many zones is converting the text zone files to binary in memory representations. It's also my understanding that there are options to speed this up based on master zone file format. Specifically binary vs text. Don't get me wrong, bind is great (ok, collapsing during runtime since last 2 updates, but ...). It sounds like you're trying to administer BIND the say way that you would have 10 ~ 20 years ago. Take a look at some of the more modern options. Especially if you are wanting to do more modern things like blacklisting. Nevertheless there are some things that can be enhanced quite a bit. I f
Re: bind and certbot with dns-challenge
On Sun, 17 Mar 2019 12:40:35 +0100 Reindl Harald wrote: > Am 17.03.19 um 12:13 schrieb Stephan von Krawczynski: > > So why is it, that there is no global way of defining default zone > > definitions which are only overriden by the actual zone definition? > > maybe because it brings a ton of troubles and whoever deals with more > than 5 zones has automatic config management in place anyways? If you don't want to follow the positive way (how about a nice additional feature), then please accept the negative way: someone broke the config semantics by implementing a zone based-only "allow update". This option worked globally before (too), so we can assume it is in fact broken now. Can someone please point me to the discussion about this incompatible change? > > Why is there no way to define a hosts-type-of-file with an URL-to-IP list? > > Do you really want people to define 50.000 zones to perform adblocking? > > no, just use the right tool for the task, this don't fit into the domain > concept of named and hence you have dnsmasq and rbldnsd to step into > that niche In todays' internet this is no niche any more. And the right tool means mostly "yet-another-host" because you then need at least a cascade of two, one for dnsmasq and one for bind/named. A lot of overhead for quite a simple task... > > Configs have to be reloaded every now and then, is there really no idea > > how to shorten things a bit? > > ?? Shorter config = shorter load time. The semantic change of "allow update" alone leaves every setup with 1000 domains in a situation where 999 config statments more have to be read, interpreted and configured - just to end up in the same runtime setup. It is really very obvious that this is only done by ideologists, not technical oriented people. -- Regards, Stephan von Krawczynski ___ 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 and certbot with dns-challenge
Hello all, I am using "BIND 9.13.7 (Development Release) " on arch linux. Up to few days ago everything was fine using "certbot renew". I had "allow-update" in nameds' global section, everything worked well. Updating to the above version threw a config error that "allow-update" has no global scope and is to be used in every single zone definition. And this brought me here with one question: why is it that bind/named does not evolve to a really useable nameserver for the most use-cases _today_, but instead gets more unusable with every new release? I mean, sure you can use it perfectly, only not good if hosting hundreds or thousands domains - only this small change I just described lets your config file grow massively -, only not good if you want to implement something like blacklists, not good for an adblocker and so on. But all that would be dead easy to do, iff really wanted. So why is it, that there is no global way of defining default zone definitions which are only overriden by the actual zone definition? Why is there no way to define a hosts-type-of-file with an URL-to-IP list? Do you really want people to define 50.000 zones to perform adblocking? Configs have to be reloaded every now and then, is there really no idea how to shorten things a bit? Don't get me wrong, bind is great (ok, collapsing during runtime since last 2 updates, but ...). Nevertheless there are some things that can be enhanced quite a bit. -- Regards, Stephan von Krawczynski ___ 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
