Re: allow-update in global options (was Re: bind and certbot with dns-challenge)
On Mon, Mar 18, 2019 at 5:26 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 3/18/19 1:32 PM, Victoria Risk wrote:
> > - 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.
>
> From my naive point of view, this seems perfectly reasonable. I hoist
> my drink to the global community and the ISC community for the the
> efforts and discussions that have ensued over this.
>
> > - 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.
>
> As I was reading this, I found myself wondering if there is (I'll go
> look in a few minutes) an ability to have BIND dump the config it has
> read in. Or conversely dump what it thinks the effective config is.
> The difference being an (inadvertent) global option { allow-update {…};
> }; could be omitted from the global options {…}; section but included in
> each zone {…}; section.
>
> Perhaps something like this would help people identify what the
> effective config is. I think it would help people produce config files
> that match (or approach) the output of such a utility.
>
> I would be tempted to have said utility omit comments, at least by
> default. After all, that's not the config in memory. Perhaps an option
> to pass comments from config file(s) through unmodified and possibly out
> of context would be of value.
>
>
>
> --
> Grant. . . .
> unix || die
>
I use:
named-checkconf -p > named.conf.out
which I think is close enough, except for the comments.
You just need to know that view-level settings are at the end of the view,
not where you might expect.
It makes for a very lot of text to read through, but it is a 'standardized'
format.
--
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
9.14.0 now available
For those of you (like me) that may not be on the -announce list, I would like to make you aware of the following: https://lists.isc.org/pipermail/bind-announce/2019-March/001122.html 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: make bind prefer DoT for recursion
Erich Eckner wrote: > > I am running a recursive resolver for my local network and was wondering > whether it is possible (and if so: how) to make it resolve via DNS-over-TLS if > that's available on the authoritative name servers. BIND doesn't have any TLS support, and (as you said) it really needs to be integrated into the resolver in this situation. You could try the Knot Resolver, which has experimental support https://knot-resolver.readthedocs.io/en/stable/modules.html#experimental-dns-over-tls-auto-discovery Unbound can forward queries over TLS but it isn't clear to me whether it can do opportunistic TLS to authoritative servers. Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth, Biscay, Fitzroy: Variable 3 or 4, becoming northeasterly 5 or 6 later in Plymouth and northwest Fitzroy. Moderate, becoming rough later in northwest Fitzroy. Occasional rain or drizzle in north. Good, occasionally poor. ___ 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
make bind prefer DoT for recursion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I am running a recursive resolver for my local network and was wondering whether it is possible (and if so: how) to make it resolve via DNS-over-TLS if that's available on the authoritative name servers. Setting up stunnel like for stub resolvers seems non-practical, as bind will have to contact many different remote dns servers. cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAlyUnWYACgkQCu7JB1Xa e1pIFBAAuKb2yuK5KvYtrnQ/PI4DRcOHz33Y71vYzBjGUf6RhcZF7N6SmIcyul13 gFWxmyHbha+O+a1D7CEUCnUVJ5Spx1KeNJbCI8XKPvPd6Fg0n35WDQV8iHtWuMhT Z09E7bn0FaDbcUxNYY9fXVNA9JXTjZAYayOaVwX3Sd7wwHhLuyR2PZrUfZ+sIoW9 XqaeAbSvSYvjqnuhjvXA7a5UfO8aEVQAQI5mfASODHQQN3Sb/Zvvrx7MCLEzXpSa P5+0HCWWyVE1IIyKy2yU4Cov8uZ95r6+BcfKBYOfIrpz4WlROnPubKfee7o40YB/ KhrRQZJ0pWrPdJGgPZUfqp3DLadGgCCYd7UFm5efptRtWiUvNcx5Z3pl1VQlHU/F /d3qJtD0KCzV2qlo/5YVilYtHeHBZNRhyfmVPlj2Ousp6euBoDT6s4J3uIFUU6nK v51IE8h2GwwGNtmzqcqPRHdRGngEMH5PBD2uhKZ/EUi4+DYhCeqGY+SkM0/37RMv cWEsXU1nnjuAzpWUob/BxCsR1p7DVWNXMUp+2XuUlee08spksR7QfjQCEk/eCaeK xsv2JtIQGWpR72uysjRAq9M4E6ZohOsqMS1ELYS/yPyT5Ox/cCER8iMR1bw/tS4p 4siaxnp3tvHlX0w8r2kdiPm8pC6Vd/qFslS6XtFiC9NmiqBrnZw= =9oou -END PGP 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
