[moving this to BALUG-Talk - as at least my mostly general responses
aren't really all that highly BALUG (admin) specific]
Thanks for the excellent review! :-)
Some comments, etc, in-line below:
> From: "Rick Moen" <rick(a)linuxmafia.com>
> Subject: [BALUG-Admin] balug.org DNS review
> Date: Wed, 27 Sep 2017 09:25:12 -0700
> Just checking on things, in the wake of the departure from Dreamhost.
Yea departing DreamHost.com!!! (A.k.a. nightmare host <sigh>).
> 1. We have three nameservers. This is in the recommended range,
> barely: RFC2182 section 5 recommends at least 3. RFC1912 section 2.8
> recommends no more than 7.
>
> If we have one or two more friends running auth nameservers, adding them
> would be gravy.
Or, ... even not bother a friend and ...
There are some free/complementary DNS slave services out there for the
taking by any and/or all ... most of 'em suck (perhaps some exceptions?)
However, probably of note and worthy of consideration ...
balug.org has registrar gandi ... gandi offers complimentary
DNS slave services. Now, I wouldn't want to be (too) dependent
upon any given registrar, but, as far as I'm aware and what I've
seen thus far, gandi's DNS complimentary slave service is basically
rock solid and good - only minor thing I've noticed is updates - it
either ignores them, or takes some modest bit of time to process them.
But it does fully respect the TTLs and relevant SOA times, so as far
as I'm aware all is fully within required specifications. I do have
at least one (other) domain that uses gandi slave DNS for *one* (and
only one) of its slave DNS servers ... so again - not too much in the
way of dependencies, and sufficiently easy to break free should there
ever be need/reason.
Another possible freebie worthy of considering - he.net - with account
(which BALUG has, and uses for its IPv6 tunnel), complimentary DNS slave
services are also offered. They seem to mostly/basically be quite "good",
but come with a few caveats of note. They support *most* - but not *all* -
RR types. So ... that's potentially an issue. As for updates, same
kind of deal as gandi - except I think he.net explicitly ignores update
notifications; but again, works fine regarding TTLs and SOA timing
values. But a few more caveats for he.net free DNS. The setup is a
bit funky - no way to introduce it without some DNS gotchas when being
implemented. Notably (at last I futzed with it), one has to put
the delegation in place *first* - so there will be some non-zero time
when one has lame NS server(s) - basically after they're delegated,
but before they pull and serve the zone data - and they won't pull and
serve the zone data until their DNS data checks show that they're
delegated - kind'a a Catch-22. Also, don't know that one can
feasibly do less than *all* of he.net's DNS servers - they give you
a set, they expect you to delegate to them. If they find you're not
delegated to them, they drop the service. And ... is that an all
or nothing? Doesn't seem to be specified in their documentation,
so ... results of delegating less than the full set may be unspecified.
*Other* than those few significant caveats, as far as I'm aware, their
DNS slave service works perfectly fine - I had (maybe still have?) it on
some domain(s) I dealt with. May have dropped it due to the particular
limitations and such, though. Oh, and one other possible caveat ... been
a while since I read their documents ... there *may* be some traffic
limit/caveat? ... or maybe not - I don't recall, I'd have to look over
their documentation again.
Anyway, yes, those (gandi complimentary and he.net free) DNS slave services,
have some potential issues/limitations to consider ... but to give 'em
credit too, also have some advantages. Notably they are pretty darn high
availability. So that's more than many can offer strung at home on
the end of a DSL or cable line or such, or even some host - even if it's
in a colo or cloud or the like - if it doesn't have a high availability
partner. Then again, for the infrastructure much of such DNS supports,
particularly high availability on the DNS can be overkill - when all
the services themselves may not be that high in reliability/availability.
But still - dang important to have good solid DNS ... as when *that*
is down solid - clients on The Internet can't in general even find out
that what they're trying to get to is up or down or what the status is,
and this also tends to cause or further complicate issues with various
services (e.g. SMTP, among others).
So ... yes, ... adding a reasonably good reliable (needn't be super high on
the reliability) DNS server would be a good thing, ... or more than one,
up to total count of about 7 (precise maximum that's still optimal also
depends upon the length of the domain name and some other DNS data factors
... e.g. optimal maximum for root (.) is a number larger than 7 ...
but root domain (.) also has the shortest possible domain name. For
domain names that are highly long, optimal maximum may be somewhat lower
than 7 ... but 7 is optimal maximum for *most* typical domain names.
> 2. No glue records for one nameserver (ns1.linuxmafia.com), because it
> is out-of-bailiwick for the .org TLD nameservers. This means queries to
> it are just a little slower than to the other two for which glue
> information gets supplied.
>
> If you want to fix that, assign my nameserver IP (198.144.195.186) the
> name NS2.BALUG.ORG in the domain record, removing the entry for
> NS1.LINUXMAFIA.COM. That fixes the glue records at the parent (.org) zone.
> And then don't forget to make the same switch in the in-zone records
> served at master nameserver NS1.BALUG.ORG.
Yes, thanks, noted ... will probably get around to that (time, priorities,
that one is modest work for only slight/teensy gain ... so ... will likely
take longer to get to it).
> 3. Information leakage. NS1.BALUG.ORG / 198.144.194.238 answers
> (correctly) CHAOS class queries about its version.
>
> :r! dig version.bind txt chaos @NS1.BALUG.ORG +short
> "9.9.5-9+deb8u14-Debian"
>
> It'd be a good idea to turn this off. I like to return amusing lies,
> myself. My stanza in /etc/bind/named.conf.options :
>
> options {
> directory "/var/cache/bind";
> version "Shirley, you're joking";
> hostname "ns1.linuxmafia.com";
> //server-id is essentially redundant to hostname, default is none
> //server-id none;
> auth-nxdomain no; # conform to RFC1035
> allow-recursion {
> [redacted]
> };
> allow-query {
> [redacted]
> };
> dnssec-validation yes;
> };
Ah yes. :-) "Of course", there's almost always tradeoffs regarding
security. E.g. convenience/speed vs. ... well, security and some information
not being so convenient/available.
As for DNS server identifying its software/version ... what
[il]legitimate uses for that? Well, there's negligible legitimate use,
so general best practice is to disable that - or put in some bogus
or intentionally misleading string.
Legitimate uses of it being there? Mostly negligible ... but there are
some slight ones. E.g. for local or secured environments/networks,
can be useful/convenient. E.g. not much harm/risk exposing it on
127.0.0.1 and ::1. But ... open to The Internet ... makes it easier
for bots/attackers to know the specific target software ... and thus
more likely to be able to successfully attack. However, even if the
information isn't made available, software can be probed/"fingerprinted",
so even if the version information is disabled or altered, attackers may
still figure out - if not precisely the target version - at least often
approximately the target software and approximate version or some
version range. So ... it's bit of tradeoff ... make the information
(much) less accessible (or not) - and make attacker's challenge some fair
bit more difficult (but not hugely more difficult). Oh, I did say
some negligible legitimate uses ... even on The Internet - software
surveys - those *can* be used for legitimate purposes. Can also be
abused - particularly if the data isn't quickly rolled up into
the aggregate, but hangs around (or leaks) with specific IPs and
corresponding software information, etc. ... and especially if that
is leaked or exposed in bulk.
I'm also curious - and don't recall - been long time since I read about
it ... txt chaos ... that mechanism was put in BIND many many moons
ago. Is it entirely (or mostly) unique to BIND? ... in which case
even serving up a "dummy" answer would identify it as some flavor of
BIND server. Or ... has other DNS server software adopted that
same mechanism for reporting version (most notably if it's in as
a default - I think most DNS software can do class CHAOS, though
probably almost nobody explicitly implements such). Anyway, depending
on the various DNS server software behavior - it may be better to,
if feasible, disable that response rather than just put in some dummy
response. Anyway, ... I'm curious what current best practice is in
that regard for DNS servers - and BIND DNS servers. And I don't think
I've any issues with, e.g. disabling it. I think thus so far in my
life I've used it one to perhaps a few times. It's a "feature"
(offering up its software and version information via DNS query) which
is of very close to zero legitimate usefulness.
As mentioned earlier on the BALUG-Admin list
https://lists.balug.org/pipermail/balug-admin/2017-September/000910.html
we're anticipating a scheduled sites outage tomorrow,
sometime between 9:00 AM and approximately 3:00 PM. PDT.
details/references:
outage window: >=2017-09-26T09:00:00-0700-->~=2017-09-26T15:00:00-0700
reason: scheduled utility power outage
site(s):
balug.org - everything on/under that domain
sf-lug.{org,com} - everything on/under those domains
(does NOT include SF-LUG lists (hosted on linuxmafia.com))
mitigations/controls:
Don't have operational UPS presently (even if I did, it probably
wouldn't suffice for potential duration of outage). The impacted sites
mentioned above are on virtual machine. Prior to outage, I'll (live)
migrate that virtual machine onto physical machine that should be able
to restart okay after drop of and restoration of power, and likewise
virtual machine thereupon should automatically be restarted and recover
fine too. With journaling filesystems and such, hopefully this will
limit the outage to not much longer than the utility power outage
itself. Even in "worst case", I expect sometime tomorrow after 3pm,
should some manual intervention be needed, to have the sites up later in
that day - I'll also have fresh image on another machine that won't be
powering up/down with the utility power, so in all cases, the sites
either will come back up, or I'll be able to bring it back up without
too much difficulty.
https://lists.balug.org/pipermail/balug-admin/2017-September/000910.htmlhttp://linuxmafia.com/pipermail/sf-lug/2017q3/012832.html
> From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu>
> To: BALUG-Admin <balug-admin(a)temp.balug.org>
> Subject: scheduled sites outage: [*.]balug.org, [*.]sf-lug.org, ...
> >=2017-09-26T09-0700-->~=2017-09-26T15-0700
> Date: Thu, 14 Sep 2017 19:36:09 -0700
> There's upcoming scheduled sites outage due to some
> scheduled electric utility work.
>
> Scheduled outage window:
>> =2017-09-26T09:00:00-0700-->~=2017-09-26T15:00:00-0700
>
> sites impacted:
> [*.]balug.org (note that it may or may not impact www.balug.org and
> balug.org - depending where they are at that time, but will impact at
> least all other *.balug.org sites/domains)
>
> [*.]sf-lug.{org,com} (note that SF-LUG list isn't impacted)
>
> To the extent feasible, I'll try to minimize the outage time, but
> expect it may minimally be up to fair part of an hour, and
> "worst case" might be 6 hours or more (notably also if I can
> have things automagically recover easily enough unattended upon power
> restoration - or not).
>
> It's also possible this outage may be delayed or rescheduled (notably
> depending what electric utility provider gets up to).
From the 2017-09-19 BALUG.org meeting (references, etc. on some of
what was discussed)
Some references, on some of the bits mentioned ...
BALUG wiki:
https://www.wiki.balug.org/wiki
It does contain more than just BALUG stuff.
Some of the stuff is rather to quite out-of-date, but also, much of
it too, is rather to quite current and maintained/updated pretty well.
As location that's automagically indexed, I typically start here:
https://www.wiki.balug.org/wiki/doku.php?do=index&idx=balugDreamHost.com hosting exodus & email/list migrations, etc.:
https://www.wiki.balug.org/wiki/doku.php?id=balug:dreamhost_exodushttps://www.wiki.balug.org/wiki/doku.php?id=balug:mail_and_lists
Also maintain list of (mostly Linux) ISO images I have:
https://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc
bup: It backs things up
I've not tried it, but at least what I saw of it several years ago,
looked quite promising, and, at quick search/glance, looks to be
reasonably maintained/active/etc.:
https://gitlab.com/SjoenH/buphttps://groups.google.com/forum/#!forum/bup-list
loopback devices
losetup(8) (files are /dev/loop*)
"loopback" can be confusing, as it's used in quite different ways for
very different things in contexts of Linux/Unix.
There's networking loopback device/address.
SunOS/Solaris also has loopback filesystem mounts ... but that's
something quite different - it functions quite like Linux's bind mounts.
All not to be confused with Linux loopback devices.
At quick peek at man page, looks like encryption bit has been
pushed out of loopback devices and losetup, and into dmsetup(8)
One can also automagically (de)allocate loop devices with mounts,
e.g. one wants to mount a (regular) file, but mount(8) requires a block
device. Well, ...
# mount [-t type] -o loop[,...] file mount_point
The loop option to mount will create loop device and mount that, and
will remove the loop device when it's umount(8)ed. It will also show
the mount in slightly more human-friendly form if one uses the mount(8)
command to display such - as opposed to manually creating the loop
device and directly mounting the loop device itself - or likewise cat(1)
of /proc/mounts. (mount(8)/mount(2) tracks that additional information
in /etc/mtab - which isn't exactly intended to be human readable, but
intended to be read/written by mount(8)/mount(2)).
Some of the other bits I wasn't thinking of names of
off-the-top-of-my-head (often more rolls off the fingertips, than
tongue):
dmsetup(8) - some more interesting and complex device mapping,
notably file(s)/device(s) - or portions thereof, possibly including
encryption, RAID, etc. It's lower-level facility used by, e.g.:
cryptsetup(8), lvm(8), partx(8), mdadm(8), etc. Most of the time
one doesn't use dmsetup(8) - at least directly ... but once in a
while one may (e.g. to "repair" something, e.g. a drive with a
fair bunch of at least moderately complex setup (e.g. LVM, or
LUKS encryption, or both) is connected, mounted, in use ...
drive gets powered off or disconnected and then reconnected and
powered on again ... cleaning that state up to a point where one
can continue and have such mounted again in such a scenario
may effectively require some use of dmsetup(8) - and possibly also
some "lazy" unmounts (umount -l)), and maybe a bit of rm(1),
and stuff like:
# echo 1 > /sys/block/sde/device/delete
and maybe some bits of rescanning, e.g.:
# (>>/dev/null 2>&1 ls -d /sys/class/scsi_host/host*/scan && for tmp
in /sys/class/scsi_host/host*/scan; do echo '- - -' > "$tmp"; done)
etc.
partx(8)
Very handy for creating(/removing) partition devices for a partitioned
(block) device, but especially where it's such a device where the kernel
and udev, etc. wouldn't typically automagically create parition devices.
E.g. /dev/sd[a-z]... would generally automagically have device(s) for
partitions, but, if, e.g. one has /dev/loop3 as a block device that
references a file that's a paritioned disk image, and one wants devices
to access those partitions ...
Here's example, setting up a paritioned disk image within a file:
# mkdir /var/tmp/partx && cd /var/tmp/partx
# truncate -s `expr 50 \* 1024 \* 1024` img
# losetup --show -f `pwd -P`/img
/dev/loop0
# fdisk /dev/loop0
Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xab8c7754.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-102399, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-102399, default 102399): 51198
Created a new partition 1 of type 'Linux' and of size 24 MiB.
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p):
Using default response p.
Partition number (2-4, default 2):
First sector (51199-102399, default 51200):
Last sector, +sectors or +size{K,M,G,T,P} (51200-102399, default 102399):
Created a new partition 2 of type 'Linux' and of size 25 MiB.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Invalid argument
The kernel still uses the old table. The new table will be used at the
next reboot or after you run partprobe(8) or kpartx(8).
# ls /dev/loop0*
/dev/loop0
# partx -a /dev/loop0 && ls /dev/loop0?*
/dev/loop0p1 /dev/loop0p2
# mkfs -t ext3 /dev/loop0p1
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
Creating filesystem with 24572 1k blocks and 6144 inodes
Filesystem UUID: fbf8ed36-25d8-4d91-a62d-080b8b4199f0
Superblock backups stored on blocks:
8193
Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
# mkfs -t ext3 /dev/loop0p2
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
Creating filesystem with 25600 1k blocks and 6400 inodes
Filesystem UUID: 9485beff-4240-4214-b919-5ea8c3602b64
Superblock backups stored on blocks:
8193, 24577
Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
# mkdir loop0p1 loop0p2
# mount /dev/loop0p1 loop0p1 && mount /dev/loop0p2 loop0p2
# df -h loop0p*
Filesystem Size Used Avail Use% Mounted on
/dev/loop0p1 23M 209K 21M 1% /var/tmp/partx/loop0p1
/dev/loop0p2 24M 316K 22M 2% /var/tmp/partx/loop0p2
# mount | fgrep loop0p
/dev/loop0p1 on /var/tmp/partx/loop0p1 type ext3 (rw,relatime,data=ordered)
/dev/loop0p2 on /var/tmp/partx/loop0p2 type ext3 (rw,relatime,data=ordered)
# ls -ons img
4116 -rw------- 1 0 52428800 Sep 20 08:07 img
# umount loop0p2 && umount loop0p1 && rmdir loop0p2 loop0p1 &&
> partx -d /dev/loop0 && losetup -d /dev/loop0 && rm img &&
> cd && rmdir /var/tmp/partx
#
Notice also that the file was sparse - 50MiB of logical space, only
about 4.1MiB of physical blocks used.
Anyway, stuff like that can be handy for mucking about with a
"disk image" that resides in a (file of type ordinary) file.
So, for example, one can prepare a disk image within a file,
and then blast (dd(1)) it to a USB or SD flash device, or copy
image from disk to file, then work with the file copy, etc.
https://www.archive.balug.org/2017/2017-09-19/BALUG.org_2017-09-19_meeting.…