Re: DynDB - handling arbitrary zones
Klaus Malorny 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.finchhttp://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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DynDB - handling arbitrary zones
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: pemen...@redhat.com PGP: 65C6C973
___
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: DynDB - handling arbitrary zones
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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DynDB - handling arbitrary zones
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: pemen...@redhat.com PGP: 65C6C973 ___ 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
