In message <[email protected]>, Fernando Gont writes: > On 02/26/2013 09:19 AM, Ted Lemon wrote: > > Homenets aren't zeroconf--there has to be a way, at a minimum, to > > communicate a prefix and a DNS server address. This can be done > > with RA, or with RA+stateless DHCPv6, or with stateful DHCPv6. So > > in a homenet we can expect that there _will_ be a mechanism that > > _could_ be made to work for setting up DNS; the questions are: > > > > (1) Which ways do we support, if any? > > Stupid question: > Can we enforce requirements on host implementations as a result of > homenet? (e.g., among all the nice pieces of DDNS, how many of them are > widely implemented? and if not widely implemented, can we push changes > in this area?)
Windows and MacOS both support DDNS. You have to turn the latter on. Thats well over half of homenet boxes. > If we cannot do that, but can spec functionality in, say, home routers, > then something along the lines of what I sketched in my previous email > might make more sense. > > > > (2) How do we resolve the question of who is the local DNS server? > > You mean the authoritative DNS server for nodes in the local network? You make a SOA query for the name you want to add. You remove labels until you get a SOA response (there are optimisations that can be applied to make this quicker). You lookup the NS RRset now that you have the containing zone. If the master server (see the SOA record) is in the NS RRset you send to it otherwise you try all the NS's until you get SUCCESS or REFUSED. If you get NOTIMP you move onto the next server. When you have exhausted all the servers you stop. NOTIMP indicates that update / update forwarding is not supported/enabled. REFUSED means you hit a acl. SUCCESS means you update was accepted. This is bog standard update processing. It works with split namespaces. If you are updating PTR records you look for CNAME records with the initial SOA query in case RFC 2317 delegations are present and you update the owner name of the PTR to match the target of the CNAME. You then restart the process. > > As far as I can tell, this whole notion has been punted in favor of > > multi-subnet mDNS; my concern is that we are going to wind up with a > > new protocol that's a weird amalgam of mDNS and DNS but shares little > > code with existing implementations of either protocol/ > > Since I was not involved in such discussions, just double-checking: I > guess the whole argument for DNS had to do with > * No need for authoritative servers? > * Availability of "local" zones, as opposed to global zones? > * Something (technical :-) ) else? > > I think that it shouldn't be hard to come up with something to make DNS > work with local zones, without relying on multicast (and thus avoiding > the need to do mDNS). If there's interest in exploring this path, I > could give this some thought -- just checking the mDNS thing is not > casted into stone, such that I avoid wasting time unnecessarily... > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: [email protected] || [email protected] > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > 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
