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. > Simon. > > > I > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet -- 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
