DDNS - limitation and excluding updates from certain networks

MAYER Hans Hans.Mayer at iiasa.ac.at
Mon Dec 25 17:23:17 UTC 2017


Hi Grant, 

Many thanks for the detailed information. 
"update-policy” is new for me and maybe the solution. 
I have to dig deeper into the documentation. 

> 		update-policy { grant *.fx.movie.edu. self fx.movie.edu. A; };

What does it say ? 
So far I have seen the client is only allowed to update his own record. That means if the client has a new IP it can update the IP address. 
Does it mean the client is only allowed to update within the same network range ? 
It seems I am missing some important information. Maybe I am blind,  but how is the client name verified ? 
What happens if a client has for example the name “www” ? 
( Assume we have already a record with name “www” and IP but in a different network than the client ) 


Kind regards 
Hans




> On 20.12.2017, at 18:50, Grant Taylor via bind-users <bind-users at lists.isc.org> wrote:
> 
> On 12/20/2017 10:40 AM, Grant Taylor via bind-users wrote:
>> I don't remember the specifics, but there is a way built into BIND to do what you are wanting.
> 
> Well, my GoogleFu seems to working today:
> 
> Link - DNS Dynamic Update (DNS and BIND, 4th Edition)
> - https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_02.htm
> 
>> I think there's an ACL configuration where you can configure that DDNS clients are only able to update the records that they own.  -  I think ownership is related to the connecting IP.
> 
> "update-policy" seems to be what you want.
> 
>> I do remember that when I tested this, it was trivial to set up and one configuration entry seemed to apply multiple DDNS clients.
> 
> Per the linked page, something like the following allows all machines in the fx.movie.edu zone to update their own records.
> 
> 	zone "fx.movie.edu" {
> 		type master;
> 		file "db.fx.movie.edu";
> 		update-policy { grant *.fx.movie.edu. self fx.movie.edu. A; };
> 	};
> 
> Short of this, the other hack that I had considered was to use a CNAME to a child zone that the client was allowed to update.  I.e. example.fx.movie.edu. CNAME example.ddns.fx.movie.edu, which example had full control over.  -  But this scheme proved to be unnecessary with the "update-policy { grant … self … };" technique above.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



More information about the bind-users mailing list