> On Nov 28, 2021, at 04:58 , Masataka Ohta <mo...@necom830.hpcl.titech.ac.jp>
> wrote:
>
> Mark Tinka wrote:
>
>>> Here in nanog, we are talking about network operations, considerable
>>> part of which can not rely on DNS.
>> And yet Facebook were unable to access their kit to fix their recent outage
>> because of it (or, lack of it).
>
> Exactly.
>
> That facebook poorly managed their DNS to cause the recent disaster
> is an important evidence to support my point that DNS, so often, may
> not be helpful for network operations against disastrous failures,
> including, but not limited to, DNS failures.
I’d argue that the true failure was failure to document the system adequately
to provide for prompt
resolution of the DNS problems in the absence of DNS and failure to properly
distribute that knowledge
to those that would need it in such a circumstance.
>> There was a time when knowing the IP(v4) address of every interface of every
>> router in your network was cool.
>
> I surely acknowledge your point that it is impossible to do so with
> MAC address based IPv6 addresses, which is why IPv6 opex is so high.
Hardly anyone uses MAC address based IPv6 addresses for anything, so your claim
here is specious.
Statically or manually configured IPv6 addresses are no more difficult than the
equivalent in IPv4, just
slightly longer.
Consider, for example, 192.159.10.7 vs. 2620:0:930::400:7
The 400 could have been omitted leaving 2620:0:930::7, but I chose to have
additional flexibility that
is available from IPv6 in classifying addresses for particular purposes and
decided to use the next
order quartet for that purpose.
> But, with manually configured IP addresses, it is trivially easy
> to have a rule to assign lower part of IP addresses within a subnet
> for hosts and upper part for routers, which is enough to troubleshoot
> most network failures.
It’s equally easy to do that in IPv6 as well (while I prefer to use the reverse
strategy, using low order
addresses for routers and higher numbers for non-forwarding hosts).
>> I have never had to care about that in close to 15 years. Right up there
>> with losing interest in making software modems work in Linux, when it was a
>> thing :-).
>
> So, you are saying you haven't faced real operational problems
> to loss DNS information for these 15 years.
>
> Congratulations for your luck!
In reality, DNS properly implemented is extraordinarily reliable these days.
It’s not completely failure-proof,
as Facebook recently demonstrated so thoroughly, but consider how extraordinary
that failure was in order
to garner so much attention. Gone are the days when DNS failures were a part of
daily operational life
that we simply accepted.
>> If you want to remain stuck in the past, we don't have to join you.
>
> Surely, the recent disaster of facebook happened in the recent
> past.
Yes, but if you really look at it, that was a failure of preparedness much more
than a failure of DNS.
> So what?
So, the world has moved on and modern networks are built using tools you appear
to prefer not to
depend on… I remember when an RS-232 port was the gold standard of being able
to recover your
router. Today, we accept at least USB and in most cases even Ethernet as a
viable alternative.
Things get better, but that comes with higher-level dependencies on underlying
infrastructure. Fortunately,
the underlying infrastructure gets better as well, making that possible and
even reasonable. The fact
that you prefer not to recognize this is a sign that you are failing to adapt
to the present in favor of
living in the past as Mark stated.
Owen
