[sf-lug] done*: SF-LUG & MX records ... @lists.sf-lug.org ...

[Michael Paoli]

done*:
$ dig -t MX lists.sf-lug.org. +short
100 linuxmafia.com.
$ dig -t A lists.sf-lug.org. +short
198.144.195.186
$
*Note that this may not yet be fully propagated through all slaves and  
throughout
all Internet DNS.
Also note, no AAAA records yet for linuxmafia.com. and thus likewise  
not present for
lists.sf-lug.org.

Rick - also, if you want/prefer me to delegate linuxmafia.com.
(or ns1.linuxmafia.com) as NS for lists.sf-lug.org. (and can also set  
up sf-lug.org.
as slave of same), just let us know, and I/we can set it up that way.

Details, details - quite commented implementation, for those that wish  
to learn and/or
follow along:

below, some empty lines added, and my comments preceded with //

//IP addresses for sf-lug.org. and www.sf-lug.org.:
$ dig +short sf-lug.org. A sf-lug.org. AAAA
198.144.194.238
2001:470:1f04:19e::2
$ dig +short www.sf-lug.org. A www.sf-lug.org. AAAA
198.144.194.238
2001:470:1f04:19e::2
$

$ dig +short balug-sf-lug-v2.balug.org. AAAA balug-sf-lug-v2.balug.org. A
2001:470:1f04:19e::2
198.144.194.238
// And again, same IP addresses ... at present, the SF-LUG web site
// stuff (except for the lists), and master DNS, is hosted on the BALUG
// host (that host itself a virtual machine (VM), which is
// balug-sf-lug-v2.balug.org (that slightly odd name being a bit having
// to do with how it came into being and evolved historically, and is
// preserved for reasonable logical consistency).  Again, note that it's
// a BALUG VM, not an SF-LUG VM ... but that it happens to presently be
// serving several SF-LUG services. This has been the case since quite
// shortly after the physical box that had been hosting those same
// SF-LUG services, was permanently disconnected from The Internet at
// the colo where it had been located for many years - the free hosting
// deal for SF-LUG got phased out in fairly quick order after the colo
// was bought out yet again by yet another hosting company.  It was
// wonderful that SF-LUG was provided that hosting for free for years,
// ... but that deal ended.

//We probably don't yet have IP addresses for lists.sf-lug.org.,
//but let's check to be sure:
$ dig lists.sf-lug.org. A lists.sf-lug.org. AAAA | fgrep NX
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1490
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27711
//Likewise, let's check for any existing MX records:
$ dig lists.sf-lug.org. MX | fgrep NX
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38658
//The NXDOMAIN in our response is "No such domain" - there is no
// Resource Record (RR) for the requested domain information, i.e. we
// don't have the A, AAAA, and MX records we queried for.
// AAAA records are IPv6 address records.

$ ssh-add -l | wc -l
2
// I have some ssh keys active - and happens to include at least one I
// want to use presently.  It's generally more secure to authenticate
// using ssh keys, rather than passwords.  By authenticating via ssh
// key, neither password nor ssh private key are ever sent to the
// server, but rather server sends us a challenge encrypted to our
// public key, since we have that corresponding private key, we can
// decrypt the challenge, and thus use that to authenticate ourselves.
// Also, by having strong passphrase on the key, and use of
// ssh-agent(1), we also avoid storing the private key in non-volatile
// (persistent) storage in the clear - the private key is only in the
// clear in Random Access Memory (RAM), and just on the client, never
// given to the server.  By taking such security precautions, if the
// server were to be compromised, that avoids password or private key
// being discovered on server and potentially used to break into
// additional hosts with that information.

$ ssh balug-sf-lug-v2.balug.org. hostname
balug-sf-lug-v2.balug.org
// as we can see above, balug-sf-lug-v2.balug.org is the hostname.

// I then proceed on that host:
$ ssh -ax balug-sf-lug-v2.balug.org.

// We see that jstockford and grantbow accounts both have access to edit
// the sf-lug master DNS file, and to reload bind9
// (the running DNS server)'s configuration:
$ sudo sudo -l -U jstockford | fgrep -e sf-lug.org -e reload
     (root) sudoedit /var/lib/named/etc/bind/master/sf-lug.org
     (root) /usr/sbin/service bind9 reload
$ sudo sudo -l -U grantbow | fgrep -e sf-lug.org -e reload
     (root) sudoedit /var/lib/named/etc/bind/master/sf-lug.org
     (root) /usr/sbin/service bind9 reload
$
// And in case one was wondering or we're not sure who those accounts
// belong to:
$ awk -F: '{if(($1=="jstockford")||($1=="grantbow")){print $1,$5;}}'  
/etc/passwd
jstockford Jim Stockford
grantbow Grant Bowman,,,
$

// Let's also get the DNS target IP address(es) we'll want to be adding:
$ dig +short linuxmafia.com. A linuxmafia.com. AAAA
198.144.195.186

// I've also got similar access on there, so I'll make the requested
// changes.  I'll use ed(1), a line-oriented editor, to make capturing
// the input and output much easier to see - were I not saving that from
// the session, I'd just use vi(1), which happens to also be be at least
// my default on the host anyway.
$ SUDO_EDITOR=ed sudoedit /var/lib/named/etc/bind/master/sf-lug.org
1465
// That's the number of characters in the file.

/SERI
                         1451934639      ; SERIAL ; perl -e  
'print(time%(2**32));'
// I search for the line having the zone serial number - relatively easy
// to find as it's well commented.  This zone is using seconds from the
// epoch.  (There are various schemes that can be used, one that's
// recommended and quite commonly used is:
// YYYYMMDDNN, where NN is iteration within that day, starting with 00,
// allowing up to 100 (00 through 99) different serial number versions
// within the day).  However, we're not restricted to that scheme.  We
// can use any proper scheme that works properly with DNS - (e.g. one
// can start with 1, and simply increment the number with each change).
// Anyway, seconds since the epoch - we can also get that more //
// concisely with GNU date(1):
// date +%s
// In any case, we need to update the serial number if we're making
// changes to the data, so let's also update that comment to be more
// concise and handy.  In DNS zone files, comments are semicolon (;)
// through end of the line

// we update our comment, changing the perl through end of line portion
// with our simpler GNU date example.  % might have special meaning in
// the Regular Expression (RE), so we precede it with backslash (\) to
// prevent it from having any special meaning in the RE:
s/perl.*$/date +\%s
                         1451934639      ; SERIAL ; date +%s
// The editor (ed) also shows us what we changed.

// We do a shell escape, again, we backslash (\) escape %, as the %
// otherwise might have special meaning in context of command execution
// within our editor ed:
!date +\%s
1452445360
!

// We update the serial number, again using RE substitution, but this time
// it doesn't show us what we changed (likely because it's yet another
// change on the same line and we've not yet moved off that same line),
// so we give the . command in the editor, which will simply show us our
// current (resultant) line:
s/1451934639/1452445360/
.
                         1452445360      ; SERIAL ; date +%

// I check to see if there's anything in the zone file that changes the
// ORIGIN - I find no surprises on that, so the ORIGIN is sf-lug.org.,
// so that being the case, essentially any name we use in the file
// that doesn't end with ., is presumed to have sf-lug.org. appended to
// it (which generally makes things much more clear, concise, and
// generally human-friendly, and can also safe some fair bits of
// filesystem data space).
g/^[^;]*@/p
@       7200    IN      SOA     (
g/ORIGIN/p
g/INCLUDE/p

// I'm just going to add our RR's at the end of the file - having
// glanced over the file earlier, there isn't any other place that
// would logically be significantly better, or perhaps even so much as
// better at all, ... so end is quite fine for this.
$a
lists   IN      MX      100     linuxmafia.com.
         IN      A       198.144.195.186; linuxmafia.com.
.
w
1514
q
$
// The a command is for append - start adding lines after current line;
// by preceding that with $, we do that relative to the last line.  We
// then type our input and then enter a line with only the character .
// on it to terminate our input of added lines.  We then use w to write
// out the file , and it responds by showing us the number of characters
// written, and q to quit ed(1).  Also, in the above, when we
// entered a line starting with spaces and/or tabs, that is a
// continuation of the immediately above RR, so it's implied, as if the
// line instead started with lists, before that whitespace.

// Also, I added both MX and A records.  The (latest)
// request/communication may have been slightly ambiguous on that, but
// rather than do more back-and-forth on that, since in this case it's
// not critical, and can be changed later quite easily if need be, I
// guestimate that both are desired or at least okay, and implement
// that.

// We then tell the nameserver to reload its configuration, so it will
// pick up the changes:
$ sudo /usr/sbin/service bind9 reload
$

// Let's check - do we have the new serial number in the zone's data?:
$ dig @127.0.0.1 -t SOA sf-lug.org. +short
ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
$
// Yes, that's our new serial number, so that looks good.
// Also note, we first checked just against our master DNS server (local
// since we're on the host that is master).  We did that, as there's no
// use or reason to expect it to show up on slaves if it's not yet been
// properly updated on the master.

// Let's check our added RR's:
$ dig @127.0.0.1 -t MX lists.sf-lug.org. +short
100 linuxmafia.com.
$ dig @127.0.0.1 -t A lists.sf-lug.org. +short
198.144.195.186
$
// So far all looking good.  Let's check the advertised NS servers.:
$ dig @8.8.8.8 -t NS sf-lug.org. +short | tr '[A-Z]' '[a-z]' | sort
ns.primate.net.
ns1.linuxmafia.com.
ns1.svlug.org.
ns2.he.net.
ns3.he.net.
ns4.he.net.
ns5.he.net.
$
// Oh, and I did upper case to lowercase conversion for my convenience -
// DNS is case insensitive (excepting, e.g., the data within TXT
// records), but generally case preserving - so I just squashed all to
// lowercase (and sorted) for ease of my use.
// We could have picked other ways to determine those, in this case,
// perhaps just for variety, I used Google's DNS server to do the lookup
// against - I'd expect they ought also have results consistent with
// what we're generally expecting.  I could just as well have not
// included @8.8.8.8 at all, in which case we would've defaulted to
// using what's specified in /etc/resolv.conf, which for this host
// would've used the local nameserver - which is perfectly fine if we
// know or can reasonably presume all is fine and well with that
// nameserver and it is consistent in its world view of DNS (I happen to
// have every reason to believe it's fine, but thought for variety I'd
// pick another to look up against).

// Now let's look up against those nameservers, to see if they have the
// updated serial number yet.  In fact, I'll even go one better than
// that, and check against all the IPs of those nameservers (some of
// them have multiple IPs).

$ (for ns in $(dig @8.8.8.8 -t NS sf-lug.org. +short | tr '[A-Z]'  
'[a-z]' | sort); do for ip in $(dig +short "$ns" A "$ns" AAAA); do  
echo "$ns $ip>"; dig @"$ip" -t SOA sf-lug.org. +short; done; done)
ns.primate.net. 198.144.194.12>
ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
ns.primate.net. 2001:470:1f04:51a::2>

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @2001:470:1f04:51a::2 -t SOA  
sf-lug.org. +
short
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
ns1.linuxmafia.com. 198.144.195.186>
ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
ns1.svlug.org. 64.62.190.98>
ns1.sf-lug.org. jim.well.com. 1452445360 10800 3600 1209600 3600
ns2.he.net. 216.218.131.2>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
ns2.he.net. 2001:470:200::2>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
ns3.he.net. 216.218.132.2>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
ns3.he.net. 2001:470:300::2>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
ns4.he.net. 216.66.1.2>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
ns4.he.net. 2001:470:400::2>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
ns5.he.net. 216.66.80.18>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
ns5.he.net. 2001:470:500::2>
ns1.sf-lug.org. jim.well.com. 1451934639 10800 3600 1209600 3600
$

// And from the above, we notice a couple things going on:
// IPv6 address 2001:470:1f04:51a::2 on ns.primate.net. fails to work
// (a known issue), however the other IP addresses on ns.primate.net.
// work.  We have sufficient redundancy, so we're not going to worry
// particularly about that one (have earlier notified contact of that
// NS of that issue).  We also notice the *.he.net. nameservers still
// have the old zone serial number - so they've not yet picked up the
// updates.  That's actually a nice free DNS service, so can't complain
// too much.  I've noticed they pull the zone down relatively quickly.
// And, perhaps at least in theory, from what's implied on some of
// their web pages, seems their servers should start serving up the
// updated data within about 5 to 10 minutes - but in practice more
// recently, I've noticed it can often take many hours or more ... but
// that's sufficiently okay - it still happens quite fast enough for
// our purposes - we're in no extreme rush, and "worst case", we have
// Time To Live (TTL) expirations to wait through on any DNS that may
// already be cached out there on various DNS servers across The
// Internet - so we can't expect our data to be fully available
// Internet wide in all of DNS everywhere quite yet - and that's also a
// *good* thing, as it makes for efficient DNS and less wasted traffic
// on The Internet - the data is cached for a while to avoid excessive
// DNS traffic.  So we have our pieces in place, we just wait for the
// *.he.net NS servers, and then the rest of The Internet, to catch up
// to our data.  So, sometime in the coming hour(s) or bit longer, it
// will then be all set, and should be good to proceed with testing use
// of that DNS on The Internet.  I'll leave the follow-up on that as an
// exercise to those that are a bit more interested in testing that
// functionality.

Meanwhile back at the ranch ;-) ...
Time for the balug VM (and the BALUG and SF-LUG stuff it hosts), to stay
home, while my laptop and I go out:
http://berkeleylug.com/meetings/
# SSH_AUTH_SOCK=/home/m/michael/.SSH_AUTH_SOCK time virsh migrate  
--live --persistent --copy-storage-all --verbose balug  
qemu+ssh://192.168.55.2/system &&  
SSH_AUTH_SOCK=/home/m/michael/.SSH_AUTH_SOCK ssh -ax -l root  
192.168.55.2 'virsh autostart balug' && virsh autostart --disable balug
Migration: [100 %]
0.16user 0.14system 6:34.09elapsed 0%CPU (0avgtext+0avgdata 9384maxresident)k
3394inputs+0outputs (18major+974minor)pagefaults 0swaps
Domain balug marked as autostarted

Domain balug unmarked as autostarted

#


> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] SF-LUG & MX records, etc.  
> (sf-lug at lists.sf-lug.org, or ... )
> Date: Sat, 9 Jan 2016 23:25:28 -0800

> Michael Paoli and Jim Stockford:  We're ready to test, if you care to
> point 'lists.svlug.org' at my IP address.
>
>
>
> I wrote:
>
>
>> My upthread comment (that MX reference records shouldn't exist for
>> domains that don't handle SMTP) was before Daniel reminded me of this
>> idea y'all discused earlier.  Obviously, in that case, the domain
>> _would_ be handling SMTP.
>
> Mystery solved.
>
> Upthread, I said 'FWIW, I've grepped through exim4's conffiles, and it
> looks like the MTA doesn't care what it's addressed as.' Specifically, I
> did:
>
> grep -r linuxmafia.com /etc/exim4/
> grep -r lists.linuxgazette.net /etc/exim4
>
> ...and both came up null.  Which lead to my surmise 'it
> looks like the MTA doesn't care what it's addressed as' -- because, if
> it cared, then linuxmafia.com and lists.linuxgazette.net would be
> mentioned in Exim4's conffiles, right?
>
> But, actually, turns out, no.
>
> 'lists.linuxgazette.net' is no longer present because I removed it some
> years ago, and forgot having done so.  Around 2010, the domain owner
> decided to re-host _Linux Gazette's_ mailing lists on his own machine,
> and changed the DNS.  Some time after that, I apparently got around to
> removing the FQDN from Exim4's 'accept mail for these' setting.
>
> 'linuxmafia.com' isn't mentioned inside the /etc/exim4/ tree because
> it gets parsed from /etc/mailname.
>
> So, it turns out Exim4 _does_ care what it's addressed as.  The list of
> FQDNs _other_ than the one in /etc/mailname is in
> /etc/exim4/update-exim4.conf.conf:
>
> ---<begin>---
>
> # /etc/exim4/update-exim4.conf.conf
> #
> # Edit this file and /etc/mailname by hand and execute update-exim4.conf
> # yourself or use 'dpkg-reconfigure exim4-config'
> #
> # Please note that this is _not_ a dpkg-conffile and that automatic changes
> # to this file might happen. The code handling this will honor your local
> # changes, so this is usually fine, but will break local schemes that mess
> # around with multiple versions of the file.
> #
> # update-exim4.conf uses this file to determine variable values to replace
> # the DEBCONFsomethingDEBCONF strings in the configuration template files.
> #
> # Most settings found in here do have corresponding questions in the
> # Debconf configuration, but not all of them.
> #
> # This is a Debian specific file
>
> dc_eximconfig_configtype='internet'
> dc_other_hostnames='unixmercenary.net:substancez.com:mail.substancez.com:sf-lug.org:lists.sf-lug.org:sf-lug.com:lists.sf-lug.com'
> dc_local_interfaces='198.144.195.186:127.0.0.1'
> dc_readhost=''
> dc_relay_domains=''
> dc_minimaldns='false'
> dc_relay_nets='76.191.131.7'
> dc_smarthost=''
> CFILEMODE='644'
> dc_use_split_config='true'
> dc_hide_mailname=''
> dc_mailname_in_oh='true'
> dc_localdelivery='mail_spool'
>
> ---<begin>---
>
> As you will see, I've added these:
>
> sf-lug.org
> lists.sf-lug.org
> sf-lug.com
> lists.sf-lug.com
>
> Daniel Gimpelevich (visiting this evening for the CABAL
> meeting) also owns domain that we added to that list for
> testing purposes (that is now no longer in that list).
>
> I re-ran /usr/sbin/update-exim4.conf, which parses the above information
> from /etc/exim4/update-exim4.conf.conf and (following those
> instructions) constructs Exim4's runtime configuration file,
> /var/lib/exim4/config.autogenerated.  Then, I restarted Exim4, and
> Daniel sent a test message to mailbox 'danielg4@[hisdomain]' --
> and we confirmed that it reaches his danielg4 account on linuxmafia.com.
> Thus, adding the four domains above (as I've done) means my
> server's MTA _will_ now accept mail from any of those FQDNs _if_ those
> FQDNs are pointed to my server's IP in the public DNS.
>
> All _four_ of the FQDNs cited are now accepted so that y'all may
> use any of them.  E.g., at one point, Jim wanted it to be just
> 'sf-lug.org', later discussion suggesting 'lists.sf-lug.org' (which
> sounds better to me).  But you may now use any.
>
>
>
> I have set up temporary mailing list 'test2' on my server.  After your
> DNS change (pointing your chosen FQDN to my IP), Daniel will see if he
> can send mail to test2 at lists.sf-lug.org (or whichever FQDN you elect)
> and have it send him his subscriber copy.
>
> If that works, I'll adjust this mailing list to list
> 'sf-lug at lists.sf-lug.org' (r whichever FQDN you elect) in Mailman as the
> mailing list's 'preferred address'.  FYI, addressing it as
> sf-lug at linuxmafia.com will continue to work, too.
>
> Pleaes let us-all know what you do with the DNS.  Thanks.