Update Security

[Bob McDonald]

I agree that TSIG or SIG(0) signed updates are certainly a more desirable
approach than allowing updates via address.  My DHCP server is setup to
sign all of it's updates this way.  However, I have AD domain controllers
in the environment that don't currently use signed updates.  Is there a
fairly painless way to convert all the AD machines to signed updates?

TIA,

Bob



On Fri, Mar 14, 2014 at 12:41 PM, Mark Andrews <marka at isc.org> wrote:

>
> If you are going to forward updates use TSIG or SIG(0) to sign the
> update and stop worrying about addresses.  TSIG and SIG(0) are
> billions and billions of times stronger authenticators than a IP
> address.
>
> "allow-update-forwarding { any; };" says forward all updates
> regardless of the address they were sent from.
>
> As for you question.  Addresses are not preserved so A doesn't know
> it came from E unless the messages are signed.
>
> Mark
>
> In message <CAM-YptcevrqfJN0371Zk43gyDt5TiEKusf4EW6=XPvzpwP=
> HgQ at mail.gmail.com>
> , Bob McDonald writes:
> >
> > I want to confirm my understanding of security of DDNS updates.
> >
> > I have a stealth master "A" feeding slave "B" and "C".
> >
> > I have allow-update-forwarding { any; } specified on "B" and "C".
> >
> > If a client "D" presents an update to "B" or "C" it will automatically be
> > forwarded to "A".
> >
> > If "B" or "C" are in the allow-updates ACL on "A" all updates will be
> > applied.
> >
> > If "D" is in the allow-udates ACL on "A" (and not "B" or "C") the updates
> > from "D" will be applied.  However an update from "E" presented to "B" or
> > "C" will be forwarded but not processed.
> >
> > Is this correct?
>
> No.
>
> > Bob
> >
> > --001a11337302fad9ea04f49380b0
> > Content-Type: text/html; charset=ISO-8859-1
> > Content-Transfer-Encoding: quoted-printable
> >
> > <div dir=3D"ltr"><div><div><div><div><div><div><div>I want to confirm my
> un=
> > derstanding of security of DDNS updates.<br><br></div>I have a stealth
> mast=
> > er "A" feeding slave "B" and
> "C".<br><br></di=
> > v>
> > I have allow-update-forwarding { any; } specified on "B" and
> &quo=
> > t;C".<br><br></div>If a client "D" presents an update to
> &qu=
> > ot;B" or "C" it will automatically be forwarded to
> "A&q=
> > uot;.<br>
> > <br></div>If "B" or "C" are in the allow-updates ACL
> on=
> >  "A" all updates will be applied.<br><br></div>If
> "D" i=
> > s in the allow-udates ACL on "A" (and not "B" or
> "=
> > C") the updates from "D" will be applied.=A0 However an
> upda=
> > te from "E" presented to "B" or "C" will
> be f=
> > orwarded but not processed.<br>
> > <br></div>Is this correct?<br><br></div>Bob<br><br></div>
> >
> > --001a11337302fad9ea04f49380b0--
> >
> > --===============4542560060445475228==
> > Content-Type: text/plain; charset="us-ascii"
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > _______________________________________________
> > 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
> > --===============4542560060445475228==--
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140314/65c86cd1/attachment-0001.html>