RE: allow-update in global options (was Re: bind and certbot with dns-challenge)
Time and time again, it has been shown that there is huge value in diversity. If you were to invest a million dollars in Africa, it most places you would get a million dollars' worth of grass huts. If you invest a million dollars in computer-programmer-designed software, most of what you will get is a million dollars of incremental changes that fit easily into the existing system. Most people on this list denigrate Microsoft Server with its built-in DNS, but the facts are that if you spin up a new Microsoft Server installation, in about an hour you have a completely configured, ready-to-go domain name server, and few if any problems thereafter. Great success and huge amounts of money have come to people who adopted a new perspective on, and solved problems in, a particular industry. For example, In the late 1800s, Rockefeller et al. made a lot of money by creating the Standard Oil Company, Inc. in the United States by combining a large number of smaller oil drillers and refiners. Although Standard Oil was eventually broken up because of antitrust sentiment, at the time it was created it had the support of the American people because many of the displaced operators were in fact just creating venues for horrific industrial accidents. For a time, General Motors made a great deal of money manufacturing railroad locomotives using production line techniques rather than as a job shop. Baldwin Locomotive went to its grave after designing and building some of the finest and most efficient steam machines that ever existed, but despite strenuous efforts it never could get over its job shop mentality. After the Second World War American railroads were running worn-out equipment on beat up rails due to the inability to purchase new equipment and spare parts during the war. Despite the railroads' monumental contribution to the war effort there was no enthusiasm within the government for refurbishing the industry due to the railroads' perceived lousy safety record, Eisenhower's and others' desires to re-create the German autobahn system in the United States, and the anticipated expansion of the airlines. Traditionally, locomotives were sold to railroads based on the railroads' Chief Engineers' knowledge of what motive power his railroad needed. General Electric recognized that the railroads were essentially broke and sent out its executives to play golf with the railroads' financial executives and thus sold a huge number of diesel electric locomotives on terms that the railroads could afford. In its original conception, Sam Walton created Wal-Mart stores as an integration of modern IT with retailing. "As of January 31, 2019, Walmart has 11,348 stores and clubs in 27 countries " (Wikipedia) What would happen if a marketing survey were sent to executives who saw and paid the bills for domain name service on the Internet? What would happen if an expert, academic or otherwise, were engaged to design a user interface for an ideal domain name system? Day in and day out the vast majority of messages that appear on this bind list server are about configuration issues. Isn't it time to get a new perspective on solving these problems? Charles Elliott -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of @lbutlr Sent: Sunday, March 17, 2019 7:48 PM To: bind-users@lists.isc.org Subject: 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-u sers to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-u sers ___ 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 Sun, Mar 17, 2019 at 4:38 PM 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 >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 > Thanks for the explanation, and for asking for input. And thanks for maintaining BIND, we depend on it. My group manages about 3000 zones. In my opinion, 'everything' should be inherited, to make the configuration as simple as possible. And it should be possible to override any setting at a lower level, for the exceptions. It would be even better if I could 'group' zones and set configurations on the group. Repeating the same configuration thousands of times seems like a waste. I would even set "masters" and 'type' at the top level if I could, since 90% of my zones come from the same hidden master. And if the file name could have a default or a pattern, that could be set at the top also, leaving only a list of zones names for most zones. If you make the change, I can live with it, but it is not my preference, and does not seem like an improvement. -- Bob Harold ___ 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 3/18/19 7:57 AM, Alan Clegg wrote: Let me say that I didn't mean to disparage or discount small operators. I didn't take anything you said as disparaging or as if it was trying to discount small operators. You asked what seemed to me as legitimate questions. I tried to provide what I thought were legitimate responses. I also tried to provide qualification. -- 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 Mon, 2019-03-18 at 09:57 -0400, Alan Clegg wrote: > Having said that, my $DAYJOB revolves (just a bit) around doing > BIND/DHCP stuff all day long, so I may have a leg up on being able to > twiddle with my configurations a bit more. ;-) Put that leg down, young man, and stop twiddling with your configurations! You'll go BIND... -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 ___ 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 Mon, 18 Mar 2019 12:06:57 -0400 Bob Harold wrote: >>[...] > Thanks for the explanation, and for asking for input. > And thanks for maintaining BIND, we depend on it. > > My group manages about 3000 zones. > In my opinion, 'everything' should be inherited, to make the configuration > as simple as possible. And it should be possible to override any setting > at a lower level, for the exceptions. It would be even better if I could > 'group' zones and set configurations on the group. Repeating the same > configuration thousands of times seems like a waste. I would even set > "masters" and 'type' at the top level if I could, since 90% of my zones > come from the same hidden master. And if the file name could have a > default or a pattern, that could be set at the top also, leaving only a > list of zones names for most zones. > > If you make the change, I can live with it, but it is not my preference, > and does not seem like an improvement. > > -- > Bob Harold Thank you very much. It seems I am not alone with my way of using BIND. Exactly such a setup is the cause for my suggestion of a "zone-default" statement in another post. This would allow the grouping that you are looking for. -- 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
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On 3/17/19 10:43 PM, Grant Taylor via bind-users wrote: > 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. Let me say that I didn't mean to disparage or discount small operators. I'm purely gathering data. I personally have 10 zones that I am authoritative for on 2 BIND instances, so I'm fighting the "small operator" fight right along with everyone else. Having said that, my $DAYJOB revolves (just a bit) around doing BIND/DHCP stuff all day long, so I may have a leg up on being able to twiddle with my configurations a bit more. ;-) Thanks for your input and I do agree that there will be people bitten by this - it's now being discussed as to how to deal with this (both short- and long-term). AlanC ___ 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)
Hello again, On Mon, 18 Mar 2019, Alan Clegg wrote: Take the personal attacks elsewhere if you don't mind. My post was not intended to be a personal attack. I did explain that it was sent in more haste than I'd have liked, and perhaps it might have been better if I'd have left it until I got back - but I don't know how much better, as I'm told I'm not always very good at email and judging by some of the responses I get that's probably correct. In any case please do be assured that there's nothing personal going on here, I'm simply trying to remind anyone who might think that it doesn't hurt to be reminded (and I believe there are some) that the ISC should have stability right up near the very top of its list of objectives. Amongst the characteristics of stability one may count the lack of any requirement to make changes to configuration files, especially at a potentially stressful time such as for example when installing any new version of BIND. I'd much prefer it didn't happen at all, but if it's required then in my view the new release should be entirely about the configuration file change(s) and nothing else, so there's more flexibility in scheduling the change because there won't be all those pesky new features to consider. On Mon, 18 Mar 2019, G.W. Haywood wrote: > Apologies for speaking frankly, but that's a lie. I would like an apology for this because I am not a liar. Well the apology was right there in that sentence, but here and now and in public I apologize again. I could take issue with a few other things in your reply, but this is my apology, not some attempt at a refutation or a justification, so here it ends. More or less this entire message is an apology, as you requested, and to anyone reading who has better things to do, I apologize for that also. Please let's get back to BIND now. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
Regarding allow-update: - We do try to avoid ‘breaking existing deployments’ with this sort of change. We do also have to balance maintaining existing deployments with making improvements in security and usability. - When we ‘clarified’ behavior of BIND in 9.13.5 preventing the use of allow-update as an inherited option, apparently it was not entirely clear from code examination what the current behavior was. Therefore, we made a more invasive change than we would normally make on purpose, without a fair amount of public notice, and possibly even some sort of open poll. - We had no idea how common a configuration leveraging the inherited allow-update might be among users that we have no direct support relationship with. We have heard from several of you that this is an important feature for you: I think we were surprised at this. Thank you for the feedback. This is the purpose of having development releases, so that early adopters can try upcoming changes and give us feedback. - We have decided to treat this change as a regression bug, and to fix it in 9.14.1. Alan argued that we should hold 9.14.0 and fix it there: however we have decided to go ahead with 9.14.0 with the change we already made in allow-update, which we will highlight in the release notes as a ‘known issue'. People who rely on a global-allow-update will simply have to wait for 9.14.1 where we will attempt to restore the prior behavior. This is not a ’neat’ resolution, as it violates our normal policy of not changing configuration defaults in the middle of a stable branch, but it should be an adequate solution. - Reasonable people (some of my colleagues at ISC) feel that users may ’self-foot-shoot’ with an inherited allow-update, and that the inherited behavior may not be obvious (similar options such as update-policy are not inherited). At ISC we hear not infrequently from people who have inherited a BIND implementation after the original administrator left, and they are maintaining a configuration they don’t understand. This experience, coupled with a generally increasing concern about DNS security makes a reasonable argument for limiting opportunities to ‘accidentally’ allow updates when adding new zones. We may still implement this or a similar change in the future, but only after more discussion and communication and advance warning. We have noted the suggestions for some sort of zone templating, and for a log of the full zone configuration, reflecting inherited options as well as explicitly configured options. Regards, Vicky Risk Product Manager for BIND ___ 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 Mon, 18 Mar 2019 12:32:56 -0700 Victoria Risk wrote: > Regarding allow-update: > [...] > Regards, > > Vicky Risk > Product Manager for BIND Thank you for this very professional statement and for noting my suggestion regarding "zone templates". Generally I would have voted for Alans' way of fixing in 9.14.0, but for now I am hoping for the best ... -- 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
Re: bind and certbot with dns-challenge
On Sun, 17 Mar 2019 at 13:34, Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > > > 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? > You definitely can. My personal record is 3.7 million zones in a single BIND instance, in production. I did ten million in testing just to prove we had growing space. We did updates, adds, and removes at a rate of about 1500 per minute; BIND could have done more, we think, but our provisioning software hit its limit around there. ___ 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
ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
Hello All.
I have a pair of ISC BIND 9.12.3-P1 servers that are configured as slaves to a
pair of Hidden Master servers. The Hidden Masters are a proprietary product
and unfortunately when used to sign the zones, the SOA records are not
populated as expected. As a result, I was looking into signing the zones
within ISC BIND instead. Reviewed the literature, came up with a plan and the
required configuration changes. However, things are not proceeding as I had
hoped...
If I include required statements within the zone options BIND complained that
update-policy local is not permitted in a zone of type slave (and failed to
start):
key-directory "keys/externals/{{ zone.zonename }}";
inline-signing yes;
auto-dnssec maintain;
update-policy local;
So I switched it out for the allow-update { localhost; };, and BIND complained
that allow-update is not permitted in a zone of type slave (and failed to
start).
So I changed my zone type from slave to master (recall that these BIND
instances are intended to be slaved off of the Hidden Masters), and BIND
complained that masters statements were not permitted in zones of type master
(meaning that updates would not be accepted).
Is there a way for me to sign the zones on the slave servers, even though I
intend to provision content into those same zones on the proprietary Hidden
Masters?
Thanks.
Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
___
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 9.11.5-P4 can't do ipv6 recursion
Hello ALL,
I set up a recursion DNS in our college. It works well in ipv4
request,but can not resolve ipv6 request. The named.conf file is as follows:
acl "trusted"{202.115.253.0/24;202.112.16.0/24;202.112.14.0/23;};
acl "ipv6" {2001:da8:6000::/48;};
options{
directory "/usr/local/named/etc/";
pid-file "/var/run/named/named.pid";
statistics-file "/var/named/data/named_stats.txt";
listen-on-v6 {any;};
recursion yes;
allow-recursion {trusted;ipv6;};
recursive-clients 2;
tcp-clients 500;
allow-query-cache {trusted;ipv6;};
dump-file "/var/named/data/cache_dump.db";
};
I have tried some methods to solve this problem,such as stop the firewall,
chanege "listen-on-v6"option to "listen-on-v6{my ipv6 address;}",it does not
work. i can ping my DNS'ipv6 address,but when using lookup,it shows time out ...
the system log shows :listening on IPv6 interfaces,port 53,but i am sure port
53 does not response the request.
thanks for help
best regards
celia
2019-03-19___
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: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
> On 19 Mar 2019, at 10:59 am, LeBlanc, Daniel James
> wrote:
>
> Thanks Mark for your quick response.
>
> On page 29 of the Bv9-12-3-P1ARM I had seen the following, which is why I
> thought that I "needed" to have one of those statements:
>
>
> " Using the auto-dnssec option requires the zone to be configured to allow
> dynamic updates, by adding an allow-update or update-policy statement to the
> zone configuration. If this has not been done, the configuration will fail.”
Which applies to master zones w/o "inline-signing yes;”. If I’m remembering
history correctly auto-dnssec
existed well before inline-signing and that description wasn’t updated.
> I was looking to do fully automatic signing using auto-dnssec maintain;. If
> that is not possible I could still live with an rndc-based approach if
> required.
Name will maintain the zone. Switching between NSEC and NSEC3 requires rndc as
you
don’t directly manipulate the zone content with dynamic updates. Rolling the
keys
is done with dnssec-settime and dnssec-keygen or dnssec-keymgr.
> I will try this out in the morning.
>
> Thanks again!
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: March-18-19 8:40 PM
> To: LeBlanc, Daniel James
> Cc: bind-users@lists.isc.org
> Subject: Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
>
> You don’t need update-policy local. In inline-signing mode named maintains
> its own copy
> of the zone with the DNSSEC records in addition to the copy from upstream.
> DNSSEC is
> controlled by rndc.
>
>> On 19 Mar 2019, at 10:33 am, LeBlanc, Daniel James
>> wrote:
>>
>> Hello All.
>>
>> I have a pair of ISC BIND 9.12.3-P1 servers that are configured as slaves to
>> a pair of Hidden Master servers. The Hidden Masters are a proprietary
>> product and unfortunately when used to sign the zones, the SOA records are
>> not populated as expected. As a result, I was looking into signing the
>> zones within ISC BIND instead. Reviewed the literature, came up with a plan
>> and the required configuration changes. However, things are not proceeding
>> as I had hoped…
>>
>> If I include required statements within the zone options BIND complained
>> that update-policy local is not permitted in a zone of type slave (and
>> failed to start):
>>
>>key-directory "keys/externals/{{ zone.zonename }}";
>>inline-signing yes;
>>auto-dnssec maintain;
>>update-policy local;
>>
>> So I switched it out for the allow-update { localhost; };, and BIND
>> complained that allow-update is not permitted in a zone of type slave (and
>> failed to start).
>>
>> So I changed my zone type from slave to master (recall that these BIND
>> instances are intended to be slaved off of the Hidden Masters), and BIND
>> complained that masters statements were not permitted in zones of type
>> master (meaning that updates would not be accepted).
>>
>> Is there a way for me to sign the zones on the slave servers, even though I
>> intend to provision content into those same zones on the proprietary Hidden
>> Masters?
>>
>> Thanks.
>>
>> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11.5-P4 can't do ipv6 recursion
On the server run "dig version.bind txt ch @::1”. This should get a response
and
work from there. e.g. "dig version.bind txt ch @other_addresses”, then try from
different machines. Named has had IPv6 support for 2 decades now. The problem
will almost certainly be with the environment not the server.
> On 19 Mar 2019, at 2:33 pm, celia <66183...@qq.com> wrote:
>
> Hello ALL,
> I set up a recursion DNS in our college. It works well in ipv4
> request,but can not resolve ipv6 request. The named.conf file is as follows:
>
> acl "trusted"{202.115.253.0/24;202.112.16.0/24;202.112.14.0/23;};
> acl "ipv6" {2001:da8:6000::/48;};
>
> options{
> directory "/usr/local/named/etc/";
> pid-file "/var/run/named/named.pid";
> statistics-file "/var/named/data/named_stats.txt";
>
> listen-on-v6 {any;};
> recursion yes;
> allow-recursion {trusted;ipv6;};
> recursive-clients 2;
> tcp-clients 500;
> allow-query-cache {trusted;ipv6;};
> dump-file "/var/named/data/cache_dump.db";
> };
> I have tried some methods to solve this problem,such as stop the firewall,
> chanege "listen-on-v6"option to "listen-on-v6{my ipv6 address;}",it does not
> work. i can ping my DNS'ipv6 address,but when using lookup,it shows time out
> ...
> the system log shows :listening on IPv6 interfaces,port 53,but i am sure port
> 53 does not response the request.
>
> thanks for help
> best regards
> celia
> 2019-03-19
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
You don’t need update-policy local. In inline-signing mode named maintains its
own copy
of the zone with the DNSSEC records in addition to the copy from upstream.
DNSSEC is
controlled by rndc.
> On 19 Mar 2019, at 10:33 am, LeBlanc, Daniel James
> wrote:
>
> Hello All.
>
> I have a pair of ISC BIND 9.12.3-P1 servers that are configured as slaves to
> a pair of Hidden Master servers. The Hidden Masters are a proprietary
> product and unfortunately when used to sign the zones, the SOA records are
> not populated as expected. As a result, I was looking into signing the zones
> within ISC BIND instead. Reviewed the literature, came up with a plan and
> the required configuration changes. However, things are not proceeding as I
> had hoped…
>
> If I include required statements within the zone options BIND complained that
> update-policy local is not permitted in a zone of type slave (and failed to
> start):
>
> key-directory "keys/externals/{{ zone.zonename }}";
> inline-signing yes;
> auto-dnssec maintain;
> update-policy local;
>
> So I switched it out for the allow-update { localhost; };, and BIND
> complained that allow-update is not permitted in a zone of type slave (and
> failed to start).
>
> So I changed my zone type from slave to master (recall that these BIND
> instances are intended to be slaved off of the Hidden Masters), and BIND
> complained that masters statements were not permitted in zones of type master
> (meaning that updates would not be accepted).
>
> Is there a way for me to sign the zones on the slave servers, even though I
> intend to provision content into those same zones on the proprietary Hidden
> Masters?
>
> Thanks.
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
Thanks Mark for your quick response.
On page 29 of the Bv9-12-3-P1ARM I had seen the following, which is why I
thought that I "needed" to have one of those statements:
" Using the auto-dnssec option requires the zone to be configured to allow
dynamic updates, by adding an allow-update or update-policy statement to the
zone configuration. If this has not been done, the configuration will fail."
I was looking to do fully automatic signing using auto-dnssec maintain;. If
that is not possible I could still live with an rndc-based approach if required.
I will try this out in the morning.
Thanks again!
Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: March-18-19 8:40 PM
To: LeBlanc, Daniel James
Cc: bind-users@lists.isc.org
Subject: Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
You don’t need update-policy local. In inline-signing mode named maintains its
own copy
of the zone with the DNSSEC records in addition to the copy from upstream.
DNSSEC is
controlled by rndc.
> On 19 Mar 2019, at 10:33 am, LeBlanc, Daniel James
> wrote:
>
> Hello All.
>
> I have a pair of ISC BIND 9.12.3-P1 servers that are configured as slaves to
> a pair of Hidden Master servers. The Hidden Masters are a proprietary
> product and unfortunately when used to sign the zones, the SOA records are
> not populated as expected. As a result, I was looking into signing the zones
> within ISC BIND instead. Reviewed the literature, came up with a plan and
> the required configuration changes. However, things are not proceeding as I
> had hoped…
>
> If I include required statements within the zone options BIND complained that
> update-policy local is not permitted in a zone of type slave (and failed to
> start):
>
> key-directory "keys/externals/{{ zone.zonename }}";
> inline-signing yes;
> auto-dnssec maintain;
> update-policy local;
>
> So I switched it out for the allow-update { localhost; };, and BIND
> complained that allow-update is not permitted in a zone of type slave (and
> failed to start).
>
> So I changed my zone type from slave to master (recall that these BIND
> instances are intended to be slaved off of the Hidden Masters), and BIND
> complained that masters statements were not permitted in zones of type master
> (meaning that updates would not be accepted).
>
> Is there a way for me to sign the zones on the slave servers, even though I
> intend to provision content into those same zones on the proprietary Hidden
> Masters?
>
> Thanks.
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
On 3/18/19 7:33 PM, LeBlanc, Daniel James wrote: > I have a pair of ISC BIND 9.12.3-P1 servers that are configured as > slaves to a pair of Hidden Master servers. The Hidden Masters are a > proprietary product and unfortunately when used to sign the zones, the > SOA records are not populated as expected. As a result, I was looking > into signing the zones within ISC BIND instead. Reviewed the > literature, came up with a plan and the required configuration changes. > However, things are not proceeding as I had hoped… As Mark noted, the "update-policy local" is not going to work as expected, but I'd like to expound a bit.. I would recommend, not knowing how you are currently configured nor what you found on "how to do this", the following: Modify one of your existing slave servers to act as an in-line signer. Have your hidden master ONLY zone transfer to this chosen signer. Configure your zones on the in-line signer as you have already noted. You now have keying material only on the in-line signing system. Protect it as you would anything valuable. Set up any other existing servers as slaves of the in-line signer. In this way, you will have only one server that needs to keep you DNSKEYs safe, have keys updated in only one location, and actually do the "heavy lifting" of signing on that one box. I realize you say you only have two slaves at this point, but when the third (or 12th) comes along, this centralization of signing is going to make your life much easier. You won't have to worry about key distribution, keeping everything in sync as far as key rollover, etc. Caveats: This will create "single points of failure" that now includes both your hidden master and the inline-signer. If the inline-signer falls over, the other slave(s) will continue to serve the zone data until either the in-line signer is fixed, or the expire timer in the SOA comes around and your zones all get deathly ill. Add extra monitoring to the "distribution master" so that you know immediately if it has issues. If you were already doing all of this, carry on! Highly recommended solution! If you are using another method, I'm curious as to your configuration. AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11.5-P4 can't do ipv6 recursion
Local firewall rules on the server? Did you have to make any firewall
changes for IPv4? Did you do the same for IPv6?
On Mon, Mar 18, 2019 at 10:20 PM Mark Andrews wrote:
>
> On the server run "dig version.bind txt ch @::1”. This should get a response
> and
> work from there. e.g. "dig version.bind txt ch @other_addresses”, then try
> from
> different machines. Named has had IPv6 support for 2 decades now. The
> problem
> will almost certainly be with the environment not the server.
>
> > On 19 Mar 2019, at 2:33 pm, celia <66183...@qq.com> wrote:
> >
> > Hello ALL,
> > I set up a recursion DNS in our college. It works well in ipv4
> > request,but can not resolve ipv6 request. The named.conf file is as follows:
> >
> > acl "trusted"{202.115.253.0/24;202.112.16.0/24;202.112.14.0/23;};
> > acl "ipv6" {2001:da8:6000::/48;};
> >
> > options{
> > directory "/usr/local/named/etc/";
> > pid-file "/var/run/named/named.pid";
> > statistics-file "/var/named/data/named_stats.txt";
> >
> > listen-on-v6 {any;};
> > recursion yes;
> > allow-recursion {trusted;ipv6;};
> > recursive-clients 2;
> > tcp-clients 500;
> > allow-query-cache {trusted;ipv6;};
> > dump-file "/var/named/data/cache_dump.db";
> > };
> > I have tried some methods to solve this problem,such as stop the firewall,
> > chanege "listen-on-v6"option to "listen-on-v6{my ipv6 address;}",it does
> > not work. i can ping my DNS'ipv6 address,but when using lookup,it shows
> > time out ...
> > the system log shows :listening on IPv6 interfaces,port 53,but i am sure
> > port 53 does not response the request.
> >
> > thanks for help
> > best regards
> > celia
> > 2019-03-19
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
Ok, first let me thank Alan et al for clearing up the initial topic and making
the problem more visible than me was able to.
Just for the papers, we are hosting some hundred domains, and of course we are
able to handle sed. We can change the config regarding this issue. But to us
it was clearly time to at least present the idea to configure zones based on a
user-defined default zone entry. This would clarify (and shorten) the config
quite a bit. Something like:
zone "default1" { type master; allow-update { 127.0.0.1; }; };
zone "default-slave" { type slave; masters { 10.0.0.1; 10.0.0.2; }; };
zone "mytest.domain" { default1; file "a_zone_file_for_mytest.domain"; };
zone "our-slave.domain" { default-slave; file "just_some_domain.bak"; };
This would allow multiple default entries and still give a trivial overview
inside the config. To me, it looks easy to implement, does not interfere with
what is there and still gives the option of defining something "semi-global".
The "all-but-one" case is trivial with such a definition option.
What do you think?
--
Regards,
Stephan von Krawczynski
--
MfG,
Stephan von Krawczynski
--
ith Kommunikationstechnik GmbH
Lieferanschrift : Reiterstrasse 24, D-94447 Plattling
Telefon : +49 9931 9188 0
Fax : +49 9931 9188 44
Geschaeftsfuehrer: Stephan von Krawczynski
Registergericht : Deggendorf HRB 1625
--
___
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)
Please let me re-phrase the above suggestion to:
zone-default "default1" { type master; allow-update { 127.0.0.1; }; };
zone-default "default-slave" { type slave; masters { 10.0.0.1; 10.0.0.2; }; };
zone "mytest.domain" { default1; file "a_zone_file_for_mytest.domain"; };
zone "our-slave.domain" { default-slave; file "just_some_domain.bak"; };
It seems more accurate to name a new keyword "zone-default" instead of
including the new feature into the "zone" statement. This way it is absolutely
clear that it is no real zone, but a collection of options for some zone yet
to come later on.
--
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
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
Stephan von Krawczynski wrote: > > But to us it was clearly time to at least present the idea to configure > zones based on a user-defined default zone entry. Catalog zones have that kind of structure: there are options at the level of the whole catalog which individual zones can override. Tony. -- f.anthony.n.finchhttp://dotat.at/ Rattray Head to Berwick upon Tweed: Variable 2 or 3, becoming south or southwest 3 or 4, occasionally 5 later. Moderate, occasionally rough at first. Showers at first, occasional drizzle later. Good, occasionally moderate later. ___ 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 Mon, 18 Mar 2019 11:37:50 + Tony Finch wrote: > Stephan von Krawczynski wrote: > > > > But to us it was clearly time to at least present the idea to configure > > zones based on a user-defined default zone entry. > > Catalog zones have that kind of structure: there are options at the level > of the whole catalog which individual zones can override. > > Tony. Yes, they have. But honestly while talking about issues I really don't want any dynamic changes in the basic DNS handling (besides the cert challenge). If your master dies, the setup is probably in trouble. Call me old-fashioned, but a config file is a config file. It's a lot harder to inject something in a setup not using rndc on such a fundamental scale ... -- 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
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
Hi there, I've been reading this exchange with growing frustration, and I hope a forthright response will be excused - especially since I now have to dash out to the hospital so I don't have more time to work on this. On Mon, 18 Mar 2019, or possibly earlier, Alan Clegg wrote: The change was an unintended consequence ... Please try not to let things like that escape into the wild, and please, please, NEVER turn them into deliberate actions purely for your own convenience. If this means that you have to pull a release, then so what? You've put me first. That's fine by me. 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? Please don't even *think* questions like that. Maybe you could code it yourself, and send the script out with the next release, and take the flack when it breaks, and next time, well, not do it. ... roasted because they don't read the release notes. Seems to me that you don't care anything like enough about this. 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. Apologies for speaking frankly, but that's a lie. 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. THE ISC HAS ALREADY HAD MY INPUT. HERE, ON THIS LIST. 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. If you can say that, I can now confidently tell you that even if you are asking questions, you aren't asking the right questions and you aren't listening to the answers anyway. The people you're asking tend to be busy, and the people that are likely to be able to give you useful responses tend to be VERY busy. Try asking: "If the next release of BIND breaks your existing configurations and you either have to start writing sed and awk scripts to fix them or change to a different product, can you tell us 1. what else will be going on in your office that morning, 2. exactly how pleased you will be to have your load increased without warning, and 3. as a result of the next disruption we've planned for you, how much more likely will it be that you will change to a different product?" Right, you say, you already know the answers. Try also: "Are thousands and thousands of surveys from suppliers annoying?" Right, you say, you already know the answer to that one too. (I have a couple of milter rules that reply to email surveys with a specially crafted 550 5.7.1 ...) And please, DON'T EVER say: "WE NEED YOUR INPUT" when you've already had it. If you make a survey, and the result you get back is a big "Yawn", that input tells you what you need to know. In case there's still any doubt, pop along to Vicky's office and have a chat with her (even if it means that you'll have to get on a 'plane, it will be worth it). On the wall in Vicky's office you should find an email from me. I've reproduced it below together with her response to it. Apologies, Vicky, if that's taking a liberty. There are users, and there's everything else, like the infrastructure. The users alone give us enough trouble thank you very much, and *they* usually only give trouble one at a time. It's REALLY annoying when the infrastructure starts to give trouble, because then all the users kick off, all at once, and they tell us it's all our fault. Curiously enough, it is. -- 73, Ged. 8<-- Date: Wed, 26 Feb 2014 12:44:37 + (GMT) From: "G.W. Haywood" To: bind-users@lists.isc.org Subject: Re: BIND 9.10.0b1 has been released. Hi there, On Wed, 26 Feb 2014, Michael McNally wrote: At ISC we are quite excited about the long list of new features and ... I don't want to rain on your parade, and I know that this is likely to be contentious, but I would just like to ask all at ISC (and I know it isn't necessary, but I'll ask anyway) to remember that many of us out here in the Totally Untamed Internet do not like our infrastructure to be exciting. Long lists of new features give me personally the screaming heeby-jeebies. The last thing anyone needs is a zero-day BIND exploit in the wild. Solid and dependable is good. For the most part BIND is just that, and I can't heap enough praise on the people who gave all that to us. But I've noticed in the last few years that I've had to do more work to keep up with bind developments when a few things have escaped that perhaps should not have. I've wanted to say this for at least a year and I'm finally biting the bullet. Please do not
Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On 3/18/19 6:53 AM, G.W. Haywood via bind-users wrote: > I've been reading this exchange with growing frustration, and I hope a > forthright response will be excused - especially since I now have to > dash out to the hospital so I don't have more time to work on this. > > On Mon, 18 Mar 2019, or possibly earlier, Alan Clegg wrote: > >> The change was an unintended consequence ... > > Please try not to let things like that escape into the wild, and > please, please, NEVER turn them into deliberate actions purely for > your own convenience. If this means that you have to pull a release, > then so what? You've put me first. That's fine by me. You misunderstand what I was saying. It was believed that "allow-update" was already disallowed - the code being changed was just to add a message to better explain what was happening. The fact that this (seemingly non-related) change caused it to come to the top was the "unintended consequence". >> 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? > > Please don't even *think* questions like that. Maybe you could code > it yourself, and send the script out with the next release, and take > the flack when it breaks, and next time, well, not do it. Thanks for telling me what not to think or ask. If I don't ask questions, I don't get answers. I am attempting to help. I am attempting to figure out the lay of the land so that we can have good internal conversations at ISC. There are so many different ways that people can write their configuration files (because ISC over the years has tried to accommodate as many user requirements as possible) that the thought of writing a "one-code-fits-all" to cover all of the possible ways this may need to be changed is rather daunting. >> ... roasted because they don't read the release notes. > > Seems to me that you don't care anything like enough about this. You tell me what to think, then you tell me that I don't care. That's crap. As anyone that ever took my classes in the past will tell you, I really DO care about the user experience and about our customers and users. Quite a few changes in BIND were brought forward from the classes that I taught due to my interest in making things better. If I didn't care, why I am putting myself out to the slings and arrows? If I didn't care, I would not have, on a Sunday, asked internal engineers exactly what the thought process was that had lead us to where we were. It surprised me that this was occurring and I decided to take it to the list in a very open and honest way. Take the personal attacks elsewhere if you don't mind. >> 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. > > Apologies for speaking frankly, but that's a lie. I would like an apology for this because I am not a liar. But I won't hold my breath. While I said that we have thick skins due to having done this for a while, I never expected to be called a liar. I do not believe that we have met, and for that I am sorry because you might have a different view of me, but this... wow. I'm ignoring the rest for now. 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
