Problems with DDNS
kcd at daimlerchrysler.com
Wed Feb 6 23:00:29 UTC 2002
Paco Orozco wrote:
> Hiya Kevin,
> >> -> Is there any feautre to be able to work this scenario (DDNS)?
> >By default, Dynamic Update clients will use the contents of the SOA
> >record (the MNAME field) and the NS records for a zone, to determine
> >where to send their Dynamic Updates. So as long as you have correct
> >information in those records, the Dynamic Updates for hello.com should go
> >to the master for hello.com, the Dynamic Updates for the
> >dynamic.hello.com zone should go to the master for that zone, and so
> Great. It means that my servers (with DDNS needs) can point to SERVER1
> (who don't allow updates) and DDNS updates will be sent to SERVER2
> (SOA of dynamic.hello.com).
> Is it true??
Correct. The server you point to for name resolution and the server to which
you send a Dynamic Update, don't necessarily have any relation to each other
> >> -> How can i solve problems with inverse resolution (DDNS)?
> >I assume you mean reverse DNS. We'd need to know what problems you're
> >having with it before suggesting solutions to those problems.
> I heve got several Windows 2000 servers, involved in Active Directory.
> It modify via DDNS some DNS records in dynamic.hello.com.
> All server who needs DDNS are part of dynamic.hello.com zone, but all
> of then aren't on the same segment, they aren't on the same
> in-addr.arpa. zone.
> When a server modify a record in dynamic.hello.com, it can't do it in
> its reverse zone (in-addr.arpa.)
> One solution is to allow DDNS on all reverse zones where contains
> servers with DDNS needs, but Is there any solution? Can I limit DDNS
> updates on in-addr.apra zone only to machines in dynamic.hello.com?
Nope. You can only limit updates by the source address of the client or by
signing key, and since Win2K's TSIG isn't compatible with that used by BIND,
signing key isn't an option.
(How would your scheme work anyway? Would you use reverse DNS to associate
the client's source IP address with a domain name? The problem with that
scenario is what happens if a client deletes its PTR record -- then it is
"locked out" of the system because its IP can nevermore be associated with a
> I hope you can understand me, my english isn't good.
You're doing just fine.
More information about the bind-users