In message <[email protected]>, Mark Andrews writes: > > In message <[email protected]>, Simon Kelley writes: > > On 14/03/13 21:22, Michael Thomas wrote: > > > On 03/14/2013 02:09 PM, Mark Andrews wrote: > > >> 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, I am still confused as to whether there is anything > > > new/unimplemented > > > here too. If my CER, say, is the master, but my ISP runs the globally > > > visible > > > NS RRset on their servers, so far so good. But if we want my CER to *also* > > > act as an authoritative server within my homenet so that, for example, > > > it still > > > works when my ISP link is dead, is that a problem? Of is this just some > > > configuration > > > voodoo that doesn't actually need standardization? > > > > > > I hadn't really considered it, but your post make me realize that the > > > opposite > > > scenario could happen as well: ie, the master is actually in the cloud > > > somewhere, > > > and my CER is one of its slaves which, again, would play authoritative > > > on my > > > homenet. Both scenarios are interesting. > > > > > > > > > Apologies if I keep dragging the topic from theory towards running code, > > but it's really worth looking at what's in dnsmasq now, since it > > supports all these modes using existing protocols and software. > > > > Think of dnsmasq as holding a repository of local addresses. At the > > moment they are derived from DHCP leases or local configuration > > (/etc/hosts). In the future they may come from mDNS too. > > > > Firstly, dns acts a DNS server for all the machines on the homenet. For > > names "out there" it's just a DNS proxy, but for local names it answers > > DNS queries directly. That allows local names to resolve even on a > > disconnected net. > > > > Secondly, it acts as an authoritative DNS server fielding queries from > > the wider internet for the local names, so that they can be resolved > > anywhere, as long the relevant domain is delegated and the ISP link is up. > > > > Thirdly, it allows slaves "in the cloud" to request zone transfers, so > > supporting the model where the CER is not directly delegated to, either > > because of worries about DoS, or because its global address in > > insufficiently stable. I have this function working, using a standard > > DynDNS.org secondary DNS account. They run BIND, as far as I know. > > You are missing the point. BIND+DHCPD can do all the above too. > It is the senario described as CER hosting above. I've been running > that at home with BIND+DHCPD since before dnsmasq existed. > > What BIND, dnsmasq or any other server can't do is muti-master there > is no specification on how to do it. DNSEXT punted this work over > decade ago.
The reason this is important to homenet and not the general enterpises is because people turn equipement off in homes when they go on holiday yet take their laptops and other equipment using names linked to the homenet with them. With enterprises these servers are always on even when everyone is on holidays and if they do turn the site fully off they are not expecting to update the zone while the site is shutdown. Mark -- 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
