---- On Tue, 24 Jul 2018 22:14:30 +0100 Daniel Migault
<daniel.miga...@ericsson.com> wrote ----
> Hi Denis,
>
> Thanks for the feed back! The big read arrow symbolized the synchronization
> between the zone hosted on your HNA and the DNS Public server on the
> outsourcing infrastructure. This could be your ISP or any third party. One
> of the motivation to outsource was to prevent DDoS attack on the HNA, so as
> mention Ted, if your ISP is as reliable as your HNA.... you may use a
> third party to host your zone. However, the HNA hosts the Hidden primary
> and is expected to host the most up-to date content. When you switch from
> one ISP to another, these ISP are hosting secondary servers and your hidden
> primary are expected to be able to synchronize with these secondaries. As a
> result the zone published on the Internet is expected to remain
> synchronized. The problem by switching from one outsourcing infrastructure
> to the other, is that information stored in cache resolver (NS) may not be
> up-to-date for TTL seconds. As mentioned Ted, we expect that the hosting
> infrastructure is able to host rel
atively safely.
Hello Daniel.
The example I provided is a bit exaggerated on one hand (in that this is not
what is typically and continuously going on in, say, 95% of home networks), but
is not exaggerated on the other -- I would guess, at least a third of home
networks face major outages at some point of their deployed life, and you
probably want to design a naming solution that is able to survive it.
There are so many ways for networks to go wrong: software bugs, hardware
faults, lightning strikes, diggers and rodents damaging cables, operators
connecting wrong cables to wrong ports and deploying wrong configuration onto
wrong network devices and so on. When it happens in a managed environment,
there is usually a sufficient amount of competent people around to detect and
handle the failure -- myself having been one of those IT troubleshooters during
one or another couple years. But it is not uncommon that replacing a faulty
piece of non-top-priority hardware can take a month or more. Expectedly, a
$20/month service does not come with the best SLA in the market. So going
offline (or split) for long periods is a part of the problem space.
Then, in a non-managed environment, simply put, you are designing a heating
boiler for users that have no idea how heating works. What you, as an engineer,
effectively have for the user interface is a couple knobs, a couple buttons and
a few LEDs. So your design must not be fragile, must be able to fail safe, and
must somehow communicate the reason or error code of the failure if it cannot
repair or reset itself. Like, for instance, a PC that lights up different
combination of diagnostic LEDs or beeps in a specific way when it cannot make
it through the POST. The appliance communicates a complex problem in a simple
way, so the user can hand it over. And the user does not want any boiler issues
in the first place, because the boiler guy charges for his work.
I am not suggesting how to design this DNS zone setup, but rather how to
evaluate its fitness before the actual deployment. The two points above may be
helpful for that.
> I believe this concern might also be relevant to the dhcp option draft where
> we explicitly had the discussion of an ISP providing the service. In this
> draft the DNS Zone Template is a template that is expected to be provisioned
> by the HNA. In other words, the template is not expected to contain all
> elements. The template is mostly useful when the HNA is booting. As a
> result, it is likely that there are very little changes over time and remain
> the same over the time you switch from one ISP to the other. If not
> up-to-date, the HNA may also update the template.
>
It would be nice if this DNS zone hosting migration would not involve the ISPs.
For them this is an obvious technical pain with questionable returns, and they
will naturally try to avoid it. As it has already been proven with mobile
number portability, the only way to guarantee DNS zone portability would be
through a law or government regulation. Most ISPs are just in a different
business.
--
Denis Ovsienko
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
