[sf-lug] SFLUG.org ...

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] SFLUG.org
> Date: Fri, 12 Apr 2019 14:27:58 -0700

> Quoting Al (awsflug at sunnyside.com):
>
>> Rick, Michael, et al,
>> Ok, I'm back in town.  I think there was an email with a concise
>> list of the name servers but I've lost track of it,
> [...]
>> It would help me to get the short summary of name servers.
>
> You're thinking of this list:
>
> $ whois sf-lug.org | grep 'Name Server'
> Name Server: NS1.LINUXMAFIA.COM
> Name Server: NS.PRIMATE.NET
> Name Server: NS1.SVLUG.ORG
> Name Server: NS1.SF-LUG.ORG
> $
>
>> so let me know the list of IPs and names for root registered name
>> servers and I'll put them in as well.
>
> I tried to do something clever with piping that through awk '{print $3}'
> to get _just_ the hostnames and then piping  that through xargs to run
> 'host' or 'dig' on them (in order to _also_ report the IPs), but can't
> seem to find a way to get the latter commands to validly process stdin.

We can be clever:
$ (for d in $(whois sf-lug.org | sed -ne '/^Name Server: /!d;s/^Name  
Server: *//;s/.*/\L&/;s/[^\.]$/&./;p'); do echo "$d" $(dig +short "$d"  
A "$d" AAAA); done)
ns1.linuxmafia.com. 198.144.195.186
ns.primate.net. 198.144.194.12 2001:470:1f04:51a::2
ns1.svlug.org. 64.62.190.98 2600:3c01::f03c:91ff:fe96:e78e
ns1.sf-lug.org. 198.144.194.238 2001:470:1f04:19e::2
$

>> and I think Jim was pushing for something slightly different.
>
> Yeah, sorry about the lack of clarity, even though it's perhaps
> unavoidable with too many cooks and no coordination worth mentioning.

Or ... handful of cooks, some cook manager(s) (more-or-less), and plenty
of suggestions from the soup consumers of what they do/don't want in
their soup and exactly how they want it prepared ... and of course they
don't all match up - unsurprisingly.

> I of course don't speak in any way for Jim, and can best serve this
> situation by trying re-find what he said.  Maybe you mean this post:
> http://linuxmafia.com/pipermail/sf-lug/2019q2/013999.html
> To be honest, I'm not sure how to restate that in summary form.
>
>> Also, I see someone wanted ns1.sflug.org to exist (or was it ns.?),
>
> Michael cited that as a fine point to attend to _eventually_.  Quoting:
>
>   We should tweak things further later
>   (e.g. ns1.sf-lug.org. --> ns1.sflug.org.)
>   but "good enough" for the moment.
>
> http://linuxmafia.com/pipermail/sf-lug/2019q2/013983.html

Yeah, we can come around to that later - it's a finer point.
It helps slightly with efficiency of DNS lookup ... and makes a few
other bits slightly more intuitive, straight-forward, and fewer
"surprises".  Not a biggie.

> (I'll be totally frank:  Although Michael and I chat enough that I can
> in good conscience summarise what he's said wtihout fear of getting it
> wrong, we often have a difference in style:  Michael will want to delay
> more than I do in order to attend to many small details, in situations
> where I'm of the Church of Get It Done Now, and Fix the Small Things
> Later.  And I'm far from claiming that either of those general appraches
> is better than the other.)

It would be really boring if Rick and I always wanted to take the exact
same approaches at the exact same time.  ;-)

>> I keep offering to be a name server as well (I'm triple homed) but I
>> don't need to be.
We can do that.  :-)  See my other post:
http://linuxmafia.com/pipermail/sf-lug/2019q2/014009.html

> I think it'd be a good idea, but it's up to Michael/Jim/Grant as people
> running the master nameserver.  (I think Michael just recently said
> I now have sudo access to administer that nameserver, but I haven't
> investigated that, yet.)

I'm fine with more (reasonably reliable) slaves.
Minimum "required" nameservers (per RFC) is 3, max recommended is ...
I think (typically) 7 - though it also depends slightly on length of some
of the bits of DNS data (e.g. root (.) is a very special case - absolute
shortest of names, so there's more room for NS data in a single 512 byte
UDP packet).  Too many / too big is bad, as then the efficiency goes *way*
down, as client resolver gets UDP response indicating the data was
necessarily truncated - then it needs redo the query with TCP to get the
full data - and that's lots more overhead (and time, and packets, and
latency).  EDNS changes that a bit, but lacking that - 512 byte
limit in UDP replies, and not all clients/servers do EDNS, nor does all
transport support larger UDP packets.