9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Lucio De Re <lucio.dere@gmail.com>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Re: Flakey DNS server
Date: Tue, 27 Oct 2020 09:06:20 +0200	[thread overview]
Message-ID: <CAJQ9t7gAtzozZ63k3P9b66g42MYLYX08wx-Mphp+Yf6fm8xuFg@mail.gmail.com> (raw)
In-Reply-To: <CAG3JMtbV=f9giRb7qat15FD+Mo6-4Ra=O_vYUhvOf9N18OH3hA@mail.gmail.com>

Just to bring the subject back: it seems the DNS server fails when the
connectivity it relies on is restored. At least, that is how I
interpret what happened this morning.

K some point, my attempts to browse the web failed and looked a lot
like a hostname lookup failure, so I applied my now regular
sledge-hammer to kill and restart the server (1). That failed in its
objective so I actually figured the Internet link had failed.
Coincidentally, the mobile data link had run out of credits, so that
failed too - nothing seems simple around here.

A few steps down the line, I managed to use the second Internet link
to provision data for the mobile backup link (2), by which time the
Internet link (would you believe that both Internet services run on a
long distance wi-fi connection?) had been restored. And that is when I
noticed that the Plan 9 DNS server had reached 100, then 200 opened
file handles as reported by the kernel console.

It seems - I'm hoping someone here knows the DNS server code better
than my distant exploration of it - that a fresh instance of the
server is more robust against a network failure than one that has run
for some time. Presumably some kind of cache problem, as that would be
the significant difference. Myself, cache allocation and general
messing about is the type of code I try desperately to avoid having to
write, let alone debug.

(1) Miller informed me that the DNS server responds to a "restart"
command, but I discovered that if the "-s" option is used, the restart
isn't a complete one.

(2) Recently, I rearranged my small network. Out of necessity as I had
managed to mis-configure the core gateway and could not restore it in
a short time. It used to be that one Internet link did all the work,
with a few exceptions to get around ISP-dictated restrictions and
misconfigurations. Routing to the second link was used as the
anti-censorship measure.

When the primary link failed, removing the lower-cost default route
sufficed to bring the more expensive secondary into full operation. I
wasn't really concerned with failures of the secondary link, they
didn't really have much impact. To be honest, even failure of the
primary link didn't have much impact. Short failures, though, that
would otherwise go unnoticed, I now believe tickled the DNS server
into bad behaviour. Not too short, I don't think, but hardly worth
switching to the secondary.

Since I switched to what used to be the secondary link for all my
desktop work and reserved the primary for Netflix and my partner's
obsession with Trump's misdemeanours, the DNS server has shown a
different pattern of failures, all seemingly related to flakey
connectivity.

Lucio.

PS: those who raised the Osmio flag did so, in my opinion,
disingenuously. Wes has long been known to punt a socially-related
issue. Probably something that needs no further attention in this
thread.


On 10/27/20, Thaddeus Woskowiak <tswoskowiak@gmail.com> wrote:
> On Sat, Oct 24, 2020 at 10:11 PM Wes Kussmaul <wes@reliableid.com> wrote:
>>
>> Lucio's concern was about commercial enterprises bending Internet norms
>> to serve their bottom line at the expense of interoperation.
>>
>> Imagine if the physical city where you live allowed building codes to be
>> proprietary, and instead of public professional licensing of architects,
>> contractors, structural engineers and building inspectors you had
>> certification programs of those commercial enterprises.
>>
>> Instead, habitability of physical buildings is determined by building
>> codes and professional licensing that are the product of participatory
>> and duly constituted public authority.
>>
>> That's the role that Osmio sets out to play in non-physical digital
>> indoor spaces.
>>
>>
>> On 10/24/20 6:48 PM, Charles Forsyth wrote:
>> > It's a virtual city in Switzerland, which is famously neutral (hence
>> > Geneva as location for various international organisations, and indeed
>> > as a setting for several TV series)
>> >
>> > On Sat, Oct 24, 2020 at 11:23 PM <cigar562hfsp952fans@icebubble.org
>> > <mailto:cigar562hfsp952fans@icebubble.org>> wrote:
>> >
>> >     Wes Kussmaul <wes@ReliableID.com> writes:
>> >
>> >     > On 10/7/20 12:08 AM, Lucio De Re wrote:
>> >     >> my situation is getting
>> >     >> more difficult as norms on the Internet are being bent by
>> > service
>> >     >> provider that care for their profitability much more than for
>> >     >> interoperation
>> >     >
>> >     > I suggest taking a look at https://www.osmio.ch/
>> >
>> > I don't get it.  That Web site appears to be the municipal
>> > homepage for
>> > a city in Switzerland that uses digital certificates as official
>> > government-recognized ID.  What does that have to do with anything?
>> >
>> > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
>> > <https://9fans.topicbox.com/groups/9fans> + participants
>> > <https://9fans.topicbox.com/groups/9fans/members> + delivery options
>> > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
>> > <https://9fans.topicbox.com/groups/9fans/T4e8db4c94a81d90f-M99ae9635befa9785b4527671>
>> --
>>
>> *Wes Kussmaul*
>>
>> *Reliable Identities, Inc.*
>> an Authenticity Enterprise
>> 738 Main Street
>> Waltham, MA 02451 USA
>> t: +1 781 790 1674
>> m: +1 781 330 1881
>> e: wes@ReliableID.com <mailto:wes@ReliableID.com>
>>
>> Learn About Authenticity <http://authenticityworks.video/>
>>
>> This message is confidential. It may also be privileged or otherwise
>> protected by work product immunity or other legal rules. If you have
>> received it by mistake, please let us know by e-mail reply and delete it
>> from your system; you may not copy this message or disclose its contents
>> to anyone. The integrity and security of this message cannot be assured
>> unless it is digitally signed by the PEN of an identity certificate with
>> an IDQA score that is sufficient for your purposes.
>>
>
> I believe the issue here is that some people have interpreted your
> osmio.ch suggestion as a solution to Lucio's DNS issues.
>
> ------------------------------------------
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/T4e8db4c94a81d90f-Mf0aaea951a7c79996e890424
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 71 471 3694
Cell: +27 83 251 5824

  reply	other threads:[~2020-10-27  7:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07  4:08 Lucio De Re
2020-10-07 13:15 ` [9fans] " Wes Kussmaul
2020-10-07 16:14   ` Kurt H Maier
2020-10-08  0:45     ` Wes Kussmaul
2020-10-08  0:59       ` ori
2020-10-08  3:48         ` Lucio De Re
2020-10-08 10:54           ` Ethan Gardener
2020-10-08 12:48         ` Wes Kussmaul
2020-10-24 22:14   ` cigar562hfsp952fans
2020-10-24 22:48     ` [9fans] " Charles Forsyth
2020-10-24 23:01       ` Calvin Morrison
2020-10-25  2:09       ` Wes Kussmaul
2020-10-25 13:33         ` hiro
2020-10-25 16:43           ` Wes Kussmaul
2020-10-25 18:32             ` hiro
2020-10-25 18:38               ` Wes Kussmaul
2020-10-25 18:54                 ` hiro
2020-10-25 19:00                   ` Wes Kussmaul
2020-10-25 19:28                     ` hiro
2020-10-25 20:19                       ` Wes Kussmaul
2020-10-27  0:39         ` Thaddeus Woskowiak
2020-10-27  7:06           ` Lucio De Re [this message]
2020-10-28  3:18             ` ori
2020-10-27 14:51           ` Wes Kussmaul
2020-10-29  0:24         ` cigar562hfsp952fans
2020-10-08  0:58 ` [9fans] " ori
2020-10-08  3:29   ` Lucio De Re
2020-10-08 12:06     ` kvik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJQ9t7gAtzozZ63k3P9b66g42MYLYX08wx-Mphp+Yf6fm8xuFg@mail.gmail.com \
    --to=lucio.dere@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).