In message <[email protected]>, Michael Richardson writes:
> >>>>> "Mark" =3D=3D Mark Andrews <[email protected]> writes:
>     >> I'm not a namedropper, but that doesn't sound like kosher DNS to
>     >> me...  sort of a weird split horizon.
> 
>     Mark> It is quite common for the stealth masters to exist (not
>     Mark> listed in the NS RRset).  It is also quite common for
>     Mark> recursive servers to have local copies of zones that are in
>     Mark> use locally but not be listed in the NS RRset.  The update
>     Mark> protocol supports forwarding of signed UPDATE requests where
>     Mark> the forwarding server does NOT have the shared secret.
> 
>     Mark> homenet <> CER (master) <> listed authoritative servers <>
>     Mark> rest of the world
> 
>     Mark> Now if you want this to work with the CER turned off while you
>     Mark> are away and update to the zone to work then protocol work is
>     Mark> needed to get multi-master working.
> 
> I think that you are saying that there is software work, not that there is
> standards work?

The DNS model is a single master server.  That server can be the
CER or a master hosted elsewhere (ISP).  Both have advantages and
disadvantages.

CER hosting:
pro: the homenet is not dependent on anything external for local DNS resolution.
con: you need the CER to always be on or else you cannot update the zone when
     you are travelling.

ISP hosting:
pro: The CER can be turned off when traveling.
con: you require the local link and ISP server to be running to make changes
     to the zone.

Now for travelling we could manually switch the server roles around.

Multi-master (if defined) would do this automatically and allow for
updates to the zone when partition whether that was due to a link
failure or powering off of the CER due to travel.

This last part requires standards work as it needs to be cross vendor.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to