bind and certbot with dns-challenge

[Grant Taylor]

On 3/17/19 5:13 AM, Stephan von Krawczynski wrote:
> Hello all,

Hi,

> I am using "BIND 9.13.7 (Development Release) <id:6491691>" 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 feel like there are some simple things that you can do to enhance your 
BIND administration quite a bit.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190317/a9ac2d71/attachment.bin>