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.



Simon.


I
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to