DDNS - limitation and excluding updates from certain networks

Bob Harold rharolde at umich.edu
Wed Dec 20 15:22:54 UTC 2017


On Wed, Dec 20, 2017 at 8:54 AM, Mukund Sivaraman <muks at isc.org> wrote:

> On Wed, Dec 20, 2017 at 01:27:17PM +0000, MAYER Hans wrote:
> >
> > Dear Mukund,
> >
> > Many thanks for coming back.
> >
> > > You'll have to explain what you mean better for a more specific answer,
> > > but see the manual for the "allow-update" ACL config option
> >
> > In my zone configuration I have an “allow-update” statement.
> > Here I define all networks which are allowed to dynamically update the
> DNS entries.
> >
> > But my zone contains other IP addresses too. Not only those of the PCs.
> > These are static names/addresses which are seldom changed.
> >
> > And of course the complete zone is a dynamic zone.
> >
> > And I don’t wont that this static names can by changed by someone out of
> an IP range, where it is allowed.
> > I didn’t find any hint to block certain IP ranges to be updated within a
> dynamic zone.
> >
> > Hopefully this explains my question a little bit better.
>
> The allow-update ACL applies to the whole zone. The ACL code doesn't
> discriminate using the contents of the update.
>
> You could put the names requiring update into a child zone (but
> obviously it'll add another label) or another zone altogether (but
> obviously it'll have a different name).
>
>                 Mukund


Just guessing here, but I see a TXT record beside each A record, and am
told that Windows clients check the TXT record to see if they "own" the A
record.  The TXT record is hex encoded data, maybe the client identifier.
So if you created a TXT record for each A record, like:
servername  IN  TXT  "do not dynamically update"  (or might need to be
valid hex?)
servername  IN  A   10.11.12.13

That might reduce the chances of a Windows client overwriting it.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20171220/39fc70e5/attachment.html>


More information about the bind-users mailing list