In message <CAA93jw44OXWgRoc5Gvof34muhG7=jkvjbzvm+vvzcwn-x0v...@mail.gmail.com> , Dave Taht writes: > On Thu, Mar 8, 2012 at 1:20 AM, Mark Andrews <[email protected]> wrote: > > > > In message <[email protected]>, Michael Richardson w= > rites: > >> >>>>> "Mark" =3D3D=3D3D Mark Andrews <[email protected]> writes: > >> =A0 =A0 Mark> In message <[email protected]>, Micha= > el Rich=3D > >> ardson writes: > >> =A0 =A0 >> >>>>> "Mark" =3D3D=3D3D Mark Andrews <[email protected]> writes: > >> =A0 =A0 Mark> A significant percentage of home machines will roam and th= > ose > >> =A0 =A0 Mark> machines will need to be able to register their current > >> =A0 =A0 Mark> address in the DNS. =A0I do this today when my Mac roams. = > =A0TSIG > >> =A0 =A0 Mark> is unavoidable and cheap. =A0UPDATE itself is relatively c= > heap. > >> > >> =A0 =A0 >> Are you asking for a link-local/mDNS-across-the-homenet leap-= > of-faith > >> =A0 =A0 >> way to do key establishment so that TSIG can be initialized? > >> > >> =A0 =A0 Mark> For homes a shared key is fine or if you want a small data= > base of > >> =A0 =A0 Mark> keys. > >> > >> You didn't answer my question! =A0I wasn't asking for justification, I w= > as > >> asking for clarification of what you are proposing. > > > > Ok. Lets look at a working model that Microsoft has with AD. =A0You boot > > the machine them a Adminstrator adds the machine to the AD domain using > > the administrators credentials. > > > > One can do essentially the same thing with TKEY and get a TSIG key > > that can be stored. =A0The home owner would register the machine with > > the router using TKEY. =A0The credentials used would allow registration > > on behalf. =A0TKEY support sending additional data in the request we > > only need a standard description on how to do "on behalf of". > > An implementation problem is that the 'publishable' quality is not > representable with things like bind9. Bind9 supports 'views', and in > my case, I have a 'us' (for inside the network) and 'them' view (for > everybody else). Inside the network, machines generally have rfc1918 > addresses and ipv6 addresses, and outside, only ipv6 addresses.
Named already transfers in a zone, strips out any NSEC, DNSKEY, NSEC3, NSEC3PARAM and RRSIG records to get a clean unsigned zone, the signs the zone using a new set of DNSKEY records to perform inline signing. Filtering out RFC 1918 address in addition would not be a major issue, basically you would have to define a acl to determine what is filtered. Zones are transferable between views. UPDATE requests on the outside view can be forwarded to the inside view, processed, the resulting zone is transfered, filtered and signed. This requires the inside view to be a superset of the outside view. If you don't give the inline signing zone a set of DNSKEYs to work with it just serves the filtered version of the zone. > So you need to update both views/databases in order to have a > consistent namespace. You don't want to leak the rfc1918 addresses to > the outside world, but you (probably) want to make your ipv6 addresses > available both inside and outside. > > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > _______________________________________________ > > homenet mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/homenet > > > > --=20 > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net -- 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
