FQDNs in masters-list (was: Help: Secondary for...)

[Kevin Darcy]

Brad Knowles wrote:

> At 6:07 PM -0500 3/8/01, Kevin Darcy wrote:
>
> >  I'm approaching this as a general solution for slave auto-configuration,
> >  not just a solution for the "roving master" situation, which, as you
> >  point out, is relatively rare today, and perhaps not even legitimate.
>
>         I'm confused.  Can you give me more details on how you think that
> this will help with slave auto-configuration?

1. New master zone is defined on master server2. Master server sends out NOTIFYs
to registered slaves
3. Registered slave receives NOTIFY, but is not yet configured as slave for the
zone
4. Because the NOTIFY is *signed*, however, it can trust that it came from the
real master.
5. Therefore, it can confidently auto-configure itself as a slave for the zone.

Without the capability to sign the NOTIFY, the trust element is missing and
therefore there would be too much danger that someone could spoof you into slaving
their *malicious* copy of the zone.

> >  The fact that this form of slave auto-configuration *also* accommodates
> >  "roving master"s is just an additional capability; one which can be
> >  viewed as either a benefit or a drawback, depending on one's opinion of
> >  the whole "roving master" concept.
>
>         I don't see this helping to solve the "roving master" problem at
> all.

You don't? You get the signed NOTIFY, see what the source address is, and
auto-(re)configure yourself to do zone transfers (presumably *authenticated* zone
transfers) from that address, instead of whatever you were using before. Seems
rather straightforward to me.

Again, the ability to sign the NOTIFY adds a level of trust, so that you know this
is the *real* master residing on a new address, rather than Joe Random User trying
to trick you into accepting their copy of the zone.


- Kevin

P.S. Why are you sending these messages to me personally, as well as to the list?