[sf-lug] done*: SF-LUG & MX records ... @lists.sf-lug.org ...
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Sun Jan 10 12:32:23 PST 2016
Anyway, as per Daniel Gimpelevich's suggestion, have also set up, at least for
"testing" purposes, MX record for sf-lug.org.
Like earlier, will take a little will to be fully available across all
Internet DNS.
$ (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. +noall +answer| grep
'^[ ]*[^ ;]'); done; done)
ns.primate.net. 198.144.194.12> sf-lug.org. 7200 IN SOA
ns1.sf-lug.org. jim.well.com. 1452456844 10800 3600 1209600 3600
ns.primate.net. 2001:470:1f04:51a::2>
ns1.linuxmafia.com. 198.144.195.186> sf-lug.org. 7200 IN SOA
ns1.sf-lug.org. jim.well.com. 1452456844 10800 3600 1209600 3600
ns1.svlug.org. 64.62.190.98> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452456844 10800 3600 1209600 3600
ns2.he.net. 216.218.131.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
ns2.he.net. 2001:470:200::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
ns3.he.net. 216.218.132.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
ns3.he.net. 2001:470:300::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
ns4.he.net. 216.66.1.2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
ns4.he.net. 2001:470:400::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
ns5.he.net. 216.66.80.18> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
ns5.he.net. 2001:470:500::2> sf-lug.org. 7200 IN SOA ns1.sf-lug.org.
jim.well.com. 1452445360 10800 3600 1209600 3600
$
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: done*: SF-LUG & MX records ... @lists.sf-lug.org ...
> Date: Sun, 10 Jan 2016 11:21:36 -0800
> 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.
>
More information about the sf-lug
mailing list