DynDB - handling arbitrary zones

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

DynDB - handling arbitrary zones

Klaus Malorny


Hi all,

first of all, if this is not the right list for such questions, please redirect me.

I am exploring the DynDB API of BIND whether it could help us to solve our
needs. As I have played around with DLZ quite a few years ago, I was pleased to
see a new interface seemingly resolving the problems of the first (mostly the
lack of DNSSEC support). However, one thing I am missing, and looking at the
demo driver, I did not get a real answer on that. That's why I am asking here.

The DLZ driver had to provide a function to find a zone. This allowed it to
generate responses for any zone that happened to be in the driver's repository
(database or else). There was no need keep a list of known zones and easily
scales up to thousands of zones. I did not find a corresponding function in the
DynDB API. The whole dbmethods interface seems to handle only a single, specific
zone with dns_db_t as an abstract handle to it. I expected somewhere a
customizable function that gets a query name and returns the respective (driver
specific) zone instance (or an indication if it is not available). Instead, it
looks like that one has to enumerate all zones that shall be handled by the
driver and register them at a provided "view" instance beforehand. Is this
perception correct or do I misunderstand something completely? Thanks in advance
for any hints.

Regards,

Klaus
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DynDB - handling arbitrary zones

Petr Mensik
Hi Klaus,

I would recommend taking a look at bind-dyndb-ldap documentation [1], as
I think it still is the only one plugin in active use. Unfortunately not
under active development, but should be able to answer many of your
questions. Some questions could be asked in FreeIPA mailing list, but it
depends on what you intend to do. No new features are planned for it,
but it is still maintained.

1.  https://pagure.io/docs/bind-dyndb-ldap/

On 3/12/19 6:16 PM, Klaus Malorny wrote:

>
>
> Hi all,
>
> first of all, if this is not the right list for such questions, please
> redirect me.
>
> I am exploring the DynDB API of BIND whether it could help us to solve
> our needs. As I have played around with DLZ quite a few years ago, I was
> pleased to see a new interface seemingly resolving the problems of the
> first (mostly the lack of DNSSEC support). However, one thing I am
> missing, and looking at the demo driver, I did not get a real answer on
> that. That's why I am asking here.
>
> The DLZ driver had to provide a function to find a zone. This allowed it
> to generate responses for any zone that happened to be in the driver's
> repository (database or else). There was no need keep a list of known
> zones and easily scales up to thousands of zones. I did not find a
> corresponding function in the DynDB API. The whole dbmethods interface
> seems to handle only a single, specific zone with dns_db_t as an
> abstract handle to it. I expected somewhere a customizable function that
> gets a query name and returns the respective (driver specific) zone
> instance (or an indication if it is not available). Instead, it looks
> like that one has to enumerate all zones that shall be handled by the
> driver and register them at a provided "view" instance beforehand. Is
> this perception correct or do I misunderstand something completely?
> Thanks in advance for any hints.

I have no deep knowledge of bind-dyndb-ldap, but I think you understand
it correctly. DynDB API is more or less replacement for built-in
database parsing and zone file reading, but has to register each handled
zone in similar manner to static configured zones. I am sure they can be
fetched by plugin somehow, because that is what bind-dyndb-ldap plugin
does. But I doubt there is one single function that you can pass a list
of zones to handle. Or that you can make some sort of wildcard for any
zone in pure dynamic way. I admit I never tried similar thing ever.

Because there is not ongoing development of any other plugin I know
about, I think it may miss user-friendly API to work with it. That could
be definitely improved, if there is demand and specific use-cases to solve.
>
> Regards,
>
> Klaus

Regards,
Petr

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: [hidden email]  PGP: 65C6C973
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DynDB - handling arbitrary zones

Klaus Malorny
On 01.04.19 11:18, Petr Mensik wrote:
> Hi Klaus,
>
> [...]
>


Thanks for the response. I have seen the LDAP implementation, but haven't looked
deeper into it. Maybe I will.

The main problem is that I don't know which zones I will have to serve
beforehand, and they may be many and may change over time, i.e. simply the
typical pattern of an ISP. I want to avoid to dynamically create the
configuration file and trigger the reloading process. One idea I will examine
further is whether it would be possible to register the root domain (".") and so
to become responsible for any possible name. However, there might be some
assumptions on the side of BIND that might spoil the idea.

Regards,

Klaus
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DynDB - handling arbitrary zones

Petr Mensik
Sounds like something RPZ might able to do on the first glance.
Note there is also rndc addzone method, which may allow runtime
reconfiguration of some sort without generation of config files. May or
may be not what you need. Might be handy for simple empty zones.

Expect some assumptions, dyndb is new enough and not used in similar cases.

On 4/1/19 12:17 PM, Klaus Malorny wrote:

> On 01.04.19 11:18, Petr Mensik wrote:
>> Hi Klaus,
>>
>> [...]
>>
>
>
> Thanks for the response. I have seen the LDAP implementation, but
> haven't looked deeper into it. Maybe I will.
>
> The main problem is that I don't know which zones I will have to serve
> beforehand, and they may be many and may change over time, i.e. simply
> the typical pattern of an ISP. I want to avoid to dynamically create the
> configuration file and trigger the reloading process. One idea I will
> examine further is whether it would be possible to register the root
> domain (".") and so to become responsible for any possible name.
> However, there might be some assumptions on the side of BIND that might
> spoil the idea.
>
> Regards,
>
> Klaus

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: [hidden email]  PGP: 65C6C973
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DynDB - handling arbitrary zones

Tony Finch
In reply to this post by Klaus Malorny
Klaus Malorny <[hidden email]> wrote:
>
> The main problem is that I don't know which zones I will have to serve
> beforehand, and they may be many and may change over time, i.e. simply the
> typical pattern of an ISP. I want to avoid to dynamically create the
> configuration file and trigger the reloading process.

Have you looked at `rndc addzone` (on the primary server) and catalog
zones (for secondaries)? Have you looked at PowerDNS?

> One idea I will examine further is whether it would be possible to
> register the root domain (".") and so to become responsible for any
> possible name.

That will cause problems because negative answers will be incorrect: the
SOA in the authority section will not be what resolvers expect, so they
will treat your server as broken.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Irish Sea: South veering northwest, 5 or 6. Slight or moderate. Rain then
showers. Good, occasionally moderate.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users