On 03/15/2013 07:23 AM, Michael Richardson wrote:
Michael> Mark, I am still confused as to whether there is anything
Michael> new/unimplemented here too. If my CER, say, is the master,
probably not, but not every piece of code out there supports the
particular characteristic. I've seen lots of web-based DNS interfaces
that did not let you enter arbitrary NS records, lest you make a
mistake.
I meant protocol-wise. I don't think there's any protocols that need
to be defined/tweaked.
So, homenet wants a particular configuration, and we need to write it
down. We also need to provide for signaling from the ISP as to what
they expect.
I think that there are four situations, and ideally, I'd like eliminate
at least two:
Can we not use "ISP"? There's no reason why it needs to be. Maybe
DNS Service Provider (DSP) or something more neutral?
1) home user has no FQDN, and ISP provides none.
There is no forward zone, and there are no "remote" updates.
It doesn't matter where the listed dns server is.
The home user can turn off CER as they like.
2) HOME user has own FQDN and uses it.
I think that the ISP may offer secondary service for the zone,
or not, it would be nice to signal this in DHCPv6 somehow, but
if we fail, that's okay.
Listed server likely should be CER, but generally user might be
sophisticated and override it.
(note that this also might apply to marksandrews-home.isc.org,
or dawsonavenue.sandelman.ca zones, where the (virtual) corporation
has decided to extend their zone into the SOHO, so it might not be
just ultra-geeks.
Home user can not turn off CER if they want roaming updates.
3) ISP provides blah-blah-blah.isp.example.net for home user,
and user has no travel cares.
I think that in this situation the CER should be a stealth
primary. The ISP's DNS servers shoud be listed.
Home user can turn off CER, because they have no cares
about forward names.
I put the authoritative server at CER because it makes it
easier and I think more reliable, to update names.
The downside here is if my CER dies or is replaced. But that may not
be enough of a downside. Perhaps we could even finagle this because
assuming that the DSP doesn't simultaneously die, we could
always do a zone transfer from it to repopulate the master's zone. I'm
not sure whether a slave would allow a master to do a zone transfer, but
that seems more like configuration than protocol?
4) ISP provides premium-premium-premium.isp.example.net for
home user, and user has travel desires.
In this case, it might make sense for the authoritative
server to be at the ISP, and for the CER to update it
only using DNS-updates.
Home user can turn off CER.
I'd venture to say that the requirement ought to be that my homenet
devices MUST be able to automatically (= no human intervention) be able
to add/change RR's in my domain within some policies. I find it a little
more plausible that there is a single point of contact between my repository
(eg, the CER) and the DSP from an auth/authz standpoint.
That is:
[mike's-toothbrush]------ixfr----->[mike's cer]--------[i]xfr------>[dns
service provider]
seems more tractable than:
[mike's-toothbrush]-----ixfr------>[dns provider]-----[i]xfr------->[mike's cer]
As far as the difference between #3 & #4, it seems to be whether you plan
to travel or not? I think we should always expect that CER might be down
for some protracted amount of time, if nothing else due to connectivity
problems. I'm not sure why you label #4 as "premium"? It seems to be the
same service as #3.
In Mark's parlance if I've got it right, CER would be an unlisted authoritative
server which is a master to DSP's listed authoritative servers who
are slaves to CER for my domain. I think #2 folds into this too, because even
your own vanity domain needs a secondary NS record, so the DSP could
pretty easily perform both of those roles; it's up to the DSP whether they want
to do that from a biz perspective tho.
So maybe 2, 3, and 4 can really be combined assuming we tease out the
nuances? (maybe from a doc standpoint it would be better to enumerate
them so it's more obvious).
Mike
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
