Re: [luv-talk] Keeping an old email address going...oops meant to go to luv-talk as well
Andrew McGlashan via luv-talk wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
On 01/10/18 16:38, Rohan McLeod via luv-talk wrote:
Would be grateful for advice at the naive user level for help on how to proceed with following problem rhn@jeack.com.au is a functioning email address; If you can get a transfer of the domain name to yourself BEFORE it expires, then there are forms to fill in and a payment will be required to be aid for the transfer.
There are rules for .com.au domain names, you must fit in with those rules; that generally means that you need a business that can own it in most cases and hat business needs to have the right to own it.
If it's registration expires, then you may or may not be able to scoop it up; it is possible that once it expires, there will be someone else trying to nab it, so you'll have competition. Therefore, if you really want the email address, you will need to go through the transfer process.
Once you own the domain name, if you can get it, then you'll need to think about DNS and appropriate MX records as well as hosting for both.
if there is just one email address that is required and it isn't a high volume one, then I might host it for you on my server, but that would be only after you know that you can legally acquire ownership of the domain name -- that hurdle needs to be overcome first.
Without going through the process of acquiring the domain name, you will likely be on borrowed time, however the current "owner" may continue to renew it forever or a long period of time and it may just keep working as it is now. When they fail to renew the domain name, for whatever reason, then you will lose access to the email as it won't route correctly to a server handling the domain name. Similarly even if they keep the domain name active, they may remove the mx functionality at any time.
Andrew thanks for your practical advice; seems as Nic expressed in less detail : - the odds are not good and - even if possible, it may well be beyond my legal and financial abilities. Also thank you Trent for the aquisition history beyond iPrimus ; ie "..... following that indicate iPrimus was acquired by M2 in 2012, and M2 merged into Vocus in 2016." It seems as though the regulatory situation is that the succesive owners are continuing to keep "rhn@jeack.com.au" ; going, even though they have no actual legal obligation to do so. What I will do now is start to look around for a durable non-web email address ; that is obviously not tied to a particular ISP ...suggestions welcome! "Non-web" because: - I already have one with vfemail.net that is accessible with TOR (unlike gmail... etc) and; - I don't like the the browser interfaces to email for general communication, as they seem slow,clumsy and connection dependent regards Rohan McLeod
Quoting Rohan McLeod (rhn@jeack.com.au):
What I will do now is start to look around for a durable non-web email address ; that is obviously not tied to a particular ISP ...suggestions welcome!
1. Register your own domain. 2. Do your own DNS. 3. Host your own mail. Works for Me.[tm]
Rick Moen via luv-talk wrote: > Quoting Rohan McLeod (rhn@jeack.com.au): > >> What I will do now is start to look around for a durable non-web >> email address ; >> that is obviously not tied to a particular ISP ...suggestions welcome! > 1. Register your own domain. > 2. Do your own DNS. > 3. Host your own mail. > > Works for Me.[tm] Rick I am sure for you this seems a small thing; but for me it would be a fairly steep learning curve; if I am forced to abandon "rhn@jeack.com.au" ; I'm not sure there would be the movation to attempt such a thing; but oddly today I had a brief conversation (phone) with a gentleman from Vocus ; who was going to look into whether I was the sole 'user of the domain' ?; if the domain name became available....I might just consider that path ! regards Rohan McLeod
Hello Rohan, On 10/2/18, Rohan McLeod via luv-talk <luv-talk@luv.asn.au> wrote: > Rick Moen via luv-talk wrote: >> Quoting Rohan McLeod (rhn@jeack.com.au): >> >>> What I will do now is start to look around for a durable non-web >>> email address ; >>> that is obviously not tied to a particular ISP ...suggestions welcome! >> 1. Register your own domain. >> 2. Do your own DNS. >> 3. Host your own mail. >> >> Works for Me.[tm] > > Rick I am sure for you this seems a small thing; but for me it would be > a fairly steep learning curve; > if I am forced to abandon "rhn@jeack.com.au" ; > I'm not sure there would be the movation to attempt such a thing; > but oddly today I had a brief conversation (phone) with a gentleman from > Vocus ; > who was going to look into whether I was the sole 'user of the domain' ?; > if the domain name became available....I might just consider that path ! I am aware of at least one other user in the recent past. jeac.com.au was not that small in the eastern suburbs of Melbourne. As to how many now use, a good question. Noting your comments about web email interfaces, Gmail can be used with desktop Mail User Agents and suitable Mail Transport Agents. That is how I did use, and intend to get back to again at some point. > regards Rohan McLeod Regards, Mark Trickett
Quoting Rohan McLeod (rhn@jeack.com.au):
Rick I am sure for you this seems a small thing; but for me it would be a fairly steep learning curve;
At the time I figured out how to run my own Linux server, I was a tax preparer and staff accountant, with zero IT experience. It took a couple of days to get it right (and, of course, use of a static IP address). The first machine was still my old 486, if memory serves. I actually deferred the problem of domains and DNS until long after setting up my Linux server with SMTP Mail: Fortunately, a friend of mine owned domain 'imat.com', and was glad to make an entry in his DNS for 'hugin.imat.com' pointing to my new Linux server. He kindly keeps that entry valid, which is why I continue to be reachable on my Linux server as 'rick@hugin.imat.com', as I have been since around 1994. ISTR a friend bought for me the 'linuxmafia.com' domain around 1998, which is perforce when I learned domain administration and authoritative DNS.
Rick Moen via luv-talk wrote:
Quoting Rohan McLeod (rhn@jeack.com.au):
Rick I am sure for you this seems a small thing; but for me it would be a fairly steep learning curve; At the time I figured out how to run my own Linux server, I was a tax preparer and staff accountant, with zero IT experience. It took a couple of days to get it right (and, of course, use of a static IP address). The first machine was still my old 486, if memory serves.
I actually deferred the problem of domains and DNS until long after setting up my Linux server with SMTP Mail: Fortunately, a friend of mine owned domain 'imat.com', and was glad to make an entry in his DNS for 'hugin.imat.com' pointing to my new Linux server. He kindly keeps that entry valid, which is why I continue to be reachable on my Linux server as 'rick@hugin.imat.com', as I have been since around 1994.
ISTR a friend bought for me the 'linuxmafia.com' domain around 1998, which is perforce when I learned domain administration and authoritative DNS.
Rick and Trent I see virtue in both your 'approaches' - Rick is suggesting I just start from the beginning and persist -Trent is pointing out the huge number of 'gotcha's', which would be involved in that path It occurs to me after sleeping on it; the problem can be split. - What about if I could just acquire "jeack.com.au" (at the moment that seems analogous to owning a company name); then have the domain hosted by someone else ? Thus postponing hosting it myself ! -Is this hypothetically possible ? --What gotchas might be invovled in acquiring the domain name ? --What gotchas might be involved in then having it 'hosted' (even what that means is unclear !); by some third party ? --- About as far as I have got with understanding 'hosting' is somehow the IP(s ?) which are referenced by the domain name ; must be either changed or referrenced indirectly ? regards Rohan McLeod
Rohan McLeod via luv-talk <luv-talk@luv.asn.au> writes:
- What about if I could just acquire "jeack.com.au" (at the moment that seems analogous to owning a company name); then have the domain hosted by someone else ? Thus postponing hosting it myself !
Yes, this is possible. Note that there are two parts to hosting: 1. Hosting the DNS domain. This is easy. There are providers that will do this for free. e.g. https://dns.he.net, although it looks like this particular one is closed beta. Currently they don't support DNSSEC, which may not actually be an issue here. 2. Hosting the email. This one requires keeping up to date with latest SPAM filtering standards, etc. Not so easy, especially if you are short on time. I believe there are third party services you can use to do the spam filtering for you and still use your own mail server, but I haven't had experience here. I personally use a paid account at https://kolabnow.com, and point my domain there. https://protonmail.com looks very interesting too. Step 1 is the urgent part, needed to ensure you keep the domain. Step 2 is required if you actually want to be able to use the domain for receiving emails. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Brian May via luv-talk wrote:
Rohan McLeod via luv-talk <luv-talk@luv.asn.au> writes:
- What about if I could just acquire "jeack.com.au" (at the moment that seems analogous to owning a company name); then have the domain hosted by someone else ? Thus postponing hosting it myself ! Yes, this is possible.
Note that there are two parts to hosting:
1. Hosting the DNS domain. This is easy. There are providers that will do this for free. e.g. https://dns.he.net, although it looks like this particular one is closed beta. Currently they don't support DNSSEC, which may not actually be an issue here.
2. Hosting the email. This one requires keeping up to date with latest SPAM filtering standards, etc. Not so easy, especially if you are short on time. I believe there are third party services you can use to do the spam filtering for you and still use your own mail server, but I haven't had experience here. I personally use a paid account at https://kolabnow.com, and point my domain there. https://protonmail.com looks very interesting too.
Step 1 is the urgent part, needed to ensure you keep the domain. Step 2 is required if you actually want to be able to use the domain for receiving emails.
Brian thanks for your interest; please go slowly here you are talking to a very naive 'explorer of internet' - I 'think' the situation of " jeack.com.au" is that it is owned by Jeack Pty Ltd. Company acquisitions meant Jeack Pty Ltd was and is owned by Hotkey PtyLtd. It seems likely Hotkey also acquired other domain names in a similar fashion , ie they bought and have continued to own these companies and their respective domain names ? -iPrimus acquired Hotkey and all it's 'subsiduary' companies and associated domain names and they continue to keep these companies alive by paying the registration fees (speculation) -in the great march of history :-) "..... following that indicate iPrimus was acquired by M2 in 2012, and M2 merged into Vocus in 2016." (thanks Trent) and (speculation) because registration costs are not much all these companies continue to exist (my current ISP is iPrimus) - now it seems iPrimus (as a current 'subsiduary' of Vocus) in it's wisdom has decided to cease supporting the it's inherited domains; - now a gentleman from Vocus who seems to have some knowledge of this history has suggested there MAY be some possibilty; that IF I seem to be the only 'user' of the domain they MAY divest themselves of it. -So lots of IFs and MAYs, I think he is just being helpful (it happens !) but if he is looking at a substantial price then it would also not be feasible; all this I think must proceed your first step above; again thanks for advise ! regards Rohan McLeod
Quoting Brian May (brian@linuxpenguins.xyz):
1. Hosting the DNS domain. This is easy.
Yes, indeed it is. I found that the problem decomposes into two subparts, which we'll call (a) and (b): (a) Operate authoritative nameserver software (I recommend NSD) on a fixed IP address. (b) Have a couple of friends who do likewise. You do authoritative slave nameservice for their domains. They do authoritative slave nameservice for yours. :r! whois linuxmafia.com | grep "Name Server" Name Server: NS.PRIMATE.NET Name Server: NS.TX.PRIMATE.NET Name Server: NS1.LINUXMAFIA.COM Name Server: NS3.LINUXMAFIA.COM Name Server: NS6.LINUXMAFIA.COM RFC2182 section 5 recommends minimum 3, maximum 7 authoritative nameservers for a domain, so five is pretty good. I note that a depressingly large number of allegedly professional outsourced DNS providers violate the RFCs with dangerously thin nameservice, e.g.: :r! whois baycon.org | grep "Name Server" Name Server: NS1.BLUEHOST.COM Name Server: NS2.BLUEHOST.COM There, friends, I present: Bluehost, Inc., a supposedly professional hosting company. And that is the sort of incompetence you all too frequently get when you outsource.
There are providers that will do this for free
And worth every penny? ;-> As insurance concerning step (b), I also have in recent years added (c): (c) Check up on your friends, lest they disappoint. E.g., 'Oh, did I neglect to tell you I moved my nameserver to a new IP address two years ago? Dreadfully sorry.' Here is /etc/cron.weekly/mydomains, a barely good enough solution to that verification problem that could be improved with modest effort: #!/bin/sh # mydomains Cron script to sanity-check my domains' SOA records at # all of their authoritative nameservers, as a quick and # dirty way of making sure (1) they're all online and # (2) they're all serving up the same data (or at least # data with the same zonefile serial number). # # The script queries all nameservers for their current # SOA value, and then uses awk to parse out of that # verbose record just the S/N field, which is field #3. # The point is that you can visually spot offline or # aberrant nameservers by their S/Ns being (respectively) # missing or an out-of-step value. # # Written by Rick Moen (rick@linuxmafia.com) # $Id: cron.weekly,v 1.03 2011/05/21 00:35:00 rick # Copyright (C) Rick Moen, 2011. Do anything you want with this work. set -o errexit #aka "set -e": exit if any line returns non-true value set -o nounset #aka "set -u": exit upon finding an uninitialised variable test -x /usr/bin/mail || exit 0 test -x /usr/bin/whois || exit 0 test -x /usr/bin/awk || exit 0 test -x /bin/grep || exit 0 test -x /usr/bin/dig || exit 0 { echo "As of 2011-05-21, linuxmafia.com should show five authoritative nameservers:" echo "" echo "ns.primate.net. 198.144.194.12, (Aaron T. Porter)" echo "ns.tx.primate.net. 72.249.38.88 (Aaron T. Porter)" echo "ns3.linuxmafia.com. 63.193.123.122, aka ns.catwhisker.org (David Wolfskill)" echo "ns1.thecoop.net. 66.220.20.163, (Drew Bertola)" echo "ns1.linuxmafia.com. 198.144.195.186 (Rick Moen)" echo "" echo "As of 2011-05-21, unixmercenary.net should show five authoritative nameservers:" echo "" echo "ns.primate.net. 198.144.194.12, (Aaron T. Porter)" echo "ns.tx.primate.net. 72.249.38.88 (Aaron T. Porter)" echo "ns3.linuxmafia.com. 63.193.123.122, aka ns.catwhisker.org (David Wolfskill)" echo "ns1.thecoop.net. 66.220.20.163, (Drew Bertola)" echo "ns1.linuxmafia.com. 198.144.195.186 (Rick Moen)" echo "" echo "If any is missing from reports below, or produces odd data, something is wrong." echo "" echo "Zonefile S/Ns, linuxmafia.com:" echo "" dig -t soa linuxmafia.com. @ns.primate.net. +short | awk '{ print $3 " on ns.primate.net." }' dig -t soa linuxmafia.com. @ns.tx.primate.net. +short | awk '{ print $3 " on ns.tx.primate.net." }' dig -t soa linuxmafia.com. @ns3.linuxmafia.com. +short | awk '{ print $3 " on ns3.linuxmafia.com." }' dig -t soa linuxmafia.com. @ns1.thecoop.net. +short | awk '{ print $3 " on ns1.thecoop.net."}' dig -t soa linuxmafia.com. @ns1.linuxmafia.com. +short | awk '{ print $3 " on ns1.linuxmafia.com."}' echo "" echo "Zonefile S/Ns, unixmercenary.net:" echo "" dig -t soa unixmercenary.net. @ns.primate.net. +short | awk '{ print $3 " on ns.primate.net." }' dig -t soa unixmercenary.net. @ns.tx.primate.net. +short | awk '{ print $3 " on ns.tx.primate.net." }' dig -t soa unixmercenary.net. @ns3.linuxmafia.com. +short | awk '{ print $3 " on ns3.linuxmafia.com." }' dig -t soa unixmercenary.net. @ns1.thecoop.net. +short | awk '{ print $3 " on ns1.thecoop.net."}' dig -t soa unixmercenary.net. @ns1.linuxmafia.com. +short | awk '{ print $3 " on ns1.linuxmafia.com."}' echo "" echo "Authoritative nameservers from whois, linuxmafia.com:" echo "" whois linuxmafia.com | grep 'Name Server' | awk -F: '{ print $2 }' | head -n 7 echo "" echo "Authoritative nameservers from whois, unixmercenary.net:" echo "" whois unixmercenary.net | grep 'Name Server' | awk -F: '{ print $2 }' | head -n 7 echo "" echo "Parent-zone NS records and matching A records (glue), linuxmafia.com:" echo "" dig -t ns linuxmafia.com. @$(dig -t ns com. +short | head -n 1) +nocmd +noquestion +nostats +nocomments echo "" echo "Parent-zone NS records and matching A records (glue), unixmercenary.net:" echo "" dig -t ns unixmercenary.net. @$(dig -t ns net. +short | head -n 1) +nocmd +noquestion +nostats +nocomments echo "" echo "In-domain NS records and matching A records, linuxmafia.com:" echo "" dig -t ns linuxmafia.com. @$(dig -t ns linuxmafia.com. +short | head -n 1) +nocmd +noquestion +nostats +nocomments echo "" echo "In-domain NS records and matching A records, unixmercenary.net:" echo "" dig -t ns unixmercenary.net. @$(dig -t ns unixmercenary.net. +short | head -n 1) +nocmd +noquestion +nostats +nocomments } | mail -s "Domains linuxmafia.com and unixmercenary.net SOA check" rick@linuxmafia.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 03/10/18 14:28, Rick Moen via luv-talk wrote:
RFC2182 section 5 recommends minimum 3, maximum 7 authoritative nameservers for a domain, so five is pretty good.
RECOMMEND .... Minimum is two, I've never seen any problems having just two with both being on different Internet links at different locations. It wouldn't hurt to have them in different cities and/or countries, but sometimes you just need them to be reasonably easy to access in your location. I have mine on opposite sides of the city for instance and both are able to be easily commuted to as needed. You are more likely to have problems with an accidental error in the zone records than losing both name servers at the same time. Even if you do lose two name servers for a short period of time, normal mail servers won't give up that easily and the same arguments can be had for backups MX servers. It is far from necessary to have more than 2 name servers and it is, as Rick said, not worth having backup MX servers these days (I've never had a backup MX). Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8LbvwAKCRCoFmvLt+/i +xybAQCA5qIAkcUGXLNOuaw6fDO7TMjkHdGVQx9kOeVAXDN/NgEAtr+PENjHH3Xm KGokcenT1bWmyW7oxXfQpRNQKsWjaG0= =uGvH -----END PGP SIGNATURE-----
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
On 03/10/18 14:28, Rick Moen via luv-talk wrote:
RFC2182 section 5 recommends minimum 3, maximum 7 authoritative nameservers for a domain, so five is pretty good.
RECOMMEND ....
{sigh} Oh, here we go. Someone just has to justify thin nameservice. Here's the RFC wording: The DNS specification and domain name registration rules require at least two servers for every zone. That is, usually, the primary and one secondary. While two, carefully placed, are often sufficient, occasions where two are insufficient are frequent enough that we advise the use of more than two listed servers. Various problems can cause a server to be unavailable for extended periods - during such a period, a zone with only two listed servers is actually running with just one. Since any server may occasionally be unavailable, for all kinds of reasons, this zone is likely, at times, to have no functional servers at all. On the other hand, having large numbers of servers adds little benefit, while adding costs. At the simplest, more servers cause packets to be larger, so requiring more bandwidth. This may seem, and realistically is, trivial. However there is a limit to the size of a DNS packet, and causing that limit to be reached has more serious performance implications. It is wise to stay well clear of it. More servers also increase the likelihood that one server will be misconfigured, or malfunction, without being detected. It is recommended that three servers be provided for most organisation level zones, with at least one which must be well removed from the others. For zones where even higher reliability is required, four, or even five, servers may be desirable. Two, or occasionally three of five, would be at the local site, with the others not geographically or topologically close to the site, or each other. [...] Matches precisely the lessons of my professional experience, and following those words of wisdom is cheap insurance.
Minimum is two, I've never seen any problems having just two with both being on different Internet links at different locations.
I have. Getting by with only two always seems OK until the day it isn't. The 'gosh, I couldn't possibly have anticipated that' scenario typically is _not_ 'two disparate nameservers going down at the same time'. It's more like someone (or your monitoring) calls your attention to the fact that one of them has failed, so now you're down to just one with no redundancy, so you're rummaging for a replacement machine to kickstart and, before Chef can put it into service, some unrelated problem takes the second nameserver down and now all of your domains aren't being served at all except for where they're cached and not past TTL. And you think when you get done with massive firefighting and an embarrassed accounting to the CTO, 'Pity I didn't have three. Maybe those RFC authors were drawing on professional sysadmin experience, or something.'
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 14/10/18 18:12, Rick Moen via luv-talk wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au): Oh, here we go. Someone just has to justify thin nameservice.
Many would say that about not having a backup MX, but anyway, guess we beg to differ on this one. I do have a DNS problem that is bugging me..... Android phone, mobile data off, local WiFi on. Sometimes the mobile gets DNS answers for public DNS instead of the private one... running bind9. A laptop continuously testing from the same local network as per the Android phone never, ever gets the public answer :confused: The closest I could get to on this is that the WiFi drops out and reconnects, but then a tool to query DNS on the device doesn't give any answers if I disable WiFi too. Something is interfering with the DNS request, somehow. I first thought it was just a K9 problem, but this happens outside of K9. It /may/ be, but I doubt it, that while the mobile's interface is getting it's IP details via DHCP, it has a temporary address that causes the public answer to be returned. Any ideas on this one? Thanks A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8LwWQAKCRCoFmvLt+/i +9wvAP42n5jHv+GFLwdUqP6sLaC7r6O3YCJZS0VxjHYL3eMpiwEAtS/DR3Cj7P3i 3ymK9BrTEDK5Uh3T6tKZlDsi8Pf8UqI= =YfTQ -----END PGP SIGNATURE-----
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Many would say that about not having a backup MX, but anyway, guess we beg to differ on this one.
I've never known any third authoritative nameserver to be directly usable by spammers to cause a domain to DoS itself (which you may recall my saying is exactly what often happens with a backup MX). Also, if SMTP becomes undeliverable for less than four days (the customary 45x delivery timeout for most MTAs; suggested somewhere in RFC 5321) before restoration of service, no mail loss occurs, as it will all get delivered during subsequent retries. (Worst that happens is that senders will get some tempfail DSNs during your downtime.) And, hey, if you cannot figure out how to receive 25/tcp traffic again somewhere in the world within 4 days, I don't think you should call yourself a sysadmin. ;-> By contrast, if all of a domains auth nameservers go on holiday, the moment cached data reaches TTL at any recursive nameserver or host DNS cache, the domain's totally offline from there, all services broken and hardfailed. IMO, that's rather a bit more urgent and severe a breakdown than if incoming SMTP deliveries are merely stuck in a 4-day holding pattern pending your standing up a new MTA host.
I do have a DNS problem that is bugging me.....
Android phone, mobile data off, local WiFi on. Sometimes the mobile gets DNS answers for public DNS instead of the private one... running bind9.
Using views, I guess?
A laptop continuously testing from the same local network as per the Android phone never, ever gets the public answer :confused:
Yeah, don't know offhand. Maybe closely check the BIND9 logs for clues about why some queries are being handed the wrong view data? Double-check the Android 'phone about what network it's on when this happens. (I'm handwaving, there, out of lack of knowledge about what to check on such a smartphone.)
Any ideas on this one?
Wish I did. It's peculiar, all right.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 14/10/18 18:46, Rick Moen via luv-talk wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au): IMO, that's rather a bit more urgent and severe a breakdown than if incoming SMTP deliveries are merely stuck in a 4-day holding pattern pending your standing up a new MTA host.
I'm not positive, but I think if mail is in the queue and resolution for the domain name isn't forthcoming due to possible down DNS server(s), then the mail will stay in the queue and it will be tried for delivery later with fresh DNS requests as well (in terms of mail when it comes to DNS answers). Of course, finding a server for other services (web for instance) would be an immediate problem when the TTL expires.
I do have a DNS problem that is bugging me.....
Android phone, mobile data off, local WiFi on. Sometimes the mobile gets DNS answers for public DNS instead of the private one... running bind9.
Using views, I guess?
yes.
A laptop continuously testing from the same local network as per the Android phone never, ever gets the public answer :confused:
Yeah, don't know offhand. Maybe closely check the BIND9 logs for clues about why some queries are being handed the wrong view data? Double-check the Android 'phone about what network it's on when this happens. (I'm handwaving, there, out of lack of knowledge about what to check on such a smartphone.)
Any ideas on this one?
Wish I did. It's peculiar, all right.
Wish you did too ;-) Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8L2gwAKCRCoFmvLt+/i +wL1AP0WnB0KUJCtmdBV33835L3N8WMos7gzEXACbWwz179KKAEAg2WtclYKcszy jh5MFJHA64PSTTvMTOWfdFNmUKOZ6ak= =089F -----END PGP SIGNATURE-----
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
I'm not positive, but I think if mail is in the queue and resolution for the domain name isn't forthcoming due to possible down DNS server(s), then the mail will stay in the queue and it will be tried for delivery later with fresh DNS requests as well (in terms of mail when it comes to DNS answers). Of course, finding a server for other services (web for instance) would be an immediate problem when the TTL expires.
Could be right. I'd not embarrass myself by saying your guess is right or wrong without checking. ;-> Being specific about scenarios, here: I'm pretty sure that any newly generated mail that triggers a DNS lookup that gets immediate socket failure on all auth nameservers is going to get immediate 45x hard fail. Hmm, a test mail to a non-existent FQDN is a logically identical case, wouldn't you agree? I could be missing something, otherwise, it would appear that in the scenario I describe the failure is immediate. (In my time zone, it's late-ish, and I probably shouldn't be trying to work through even gedankenexperiments. ;-> )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 14/10/18 19:04, Rick Moen via luv-talk wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
I'm not positive, but I think if mail is in the queue and resolution for the domain name isn't forthcoming due to possible down DNS server(s), then the mail will stay in the queue and it will be tried for delivery later with fresh DNS requests as well (in terms of mail when it comes to DNS answers). Of course, finding a server for other services (web for instance) would be an immediate problem when the TTL expires.
Could be right. I'd not embarrass myself by saying your guess is right or wrong without checking. ;->
Being specific about scenarios, here: I'm pretty sure that any newly generated mail that triggers a DNS lookup that gets immediate socket failure on all auth nameservers is going to get immediate 45x hard fail.
Hmm, a test mail to a non-existent FQDN is a logically identical case, wouldn't you agree? I could be missing something, otherwise, it would appear that in the scenario I describe the failure is immediate.
It might not be so easy to test. The name servers for a domain name are "glued" in the system, so to speak. That is, the authoritative IP address to use for name servers need not necessarily have an "A" RR associated with it. The upstream registry has to know where (IP address) to get answers from for the domain name. If you have "A" records (as you would normally do), then you can make DNS queries using those servers using the IP given by the A record. dig @ip.ad.dr.es -t a mail.unknown.net So, you need a domain name that has no name servers assigned whatsoever or you need to deliberately take the name servers down; neither of which I plan to do right now, but I might test further at another time with a less significant domain name. Using a random and otherwise non-existent domain name will give you an immediate fail though. Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8L+OAAKCRCoFmvLt+/i +wcvAP9hTQKL4+ish0aIGUT2x534FjrBkbL1FjD5e3YdhiHtGwD/Q2q9ydnAZDtu 7if9WfH707O3LeNnnLTVqFMBnJZBFVA= =5peL -----END PGP SIGNATURE-----
On Sunday, 14 October 2018 7:28:46 PM AEDT Andrew McGlashan via luv-talk wrote:
On 14/10/18 19:04, Rick Moen via luv-talk wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
I'm not positive, but I think if mail is in the queue and resolution for the domain name isn't forthcoming due to possible down DNS server(s), then the mail will stay in the queue and it will be tried for delivery later with fresh DNS requests as well (in terms of mail when it comes to DNS answers). Of course, finding a server for other services (web for instance) would be an immediate problem when the TTL expires.
Could be right. I'd not embarrass myself by saying your guess is right or wrong without checking. ;->
Being specific about scenarios, here: I'm pretty sure that any newly generated mail that triggers a DNS lookup that gets immediate socket failure on all auth nameservers is going to get immediate 45x hard fail.
45x isn't a hard fail, all the 4xx codes are for temporary failures. 45x are for corrupted mailbox, server connection problem, or server storage limit exceeded.
Hmm, a test mail to a non-existent FQDN is a logically identical case, wouldn't you agree? I could be missing something, otherwise, it would appear that in the scenario I describe the failure is immediate.
It might not be so easy to test.
# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 3C48FEE5F 425 Sun Oct 14 11:51:28 root@sws.net.au (Host or domain name not found. Name service error for name=test.coker.com.au type=MX: Host not found, try again) test@test.coker.com.au It's trivial to test, put in an NS record for a subdomain of one of your domains that points to a system that's well firewalled and refuses to respond to port 53. Then send mail.
The name servers for a domain name are "glued" in the system, so to speak. That is, the authoritative IP address to use for name servers need not necessarily have an "A" RR associated with it. The upstream registry has to know where (IP address) to get answers from for the domain name. If you have "A" records (as you would normally do), then you can make DNS queries using those servers using the IP given by the A record.
http://wiki.gandi.net/en/glossary/glue-record The above page has a good description of glue records. You should still have A records that match the glue records (I haven't tested what happens if you don't, it would probably work much of the time and fail in strange and interesting ways).
Using a random and otherwise non-existent domain name will give you an immediate fail though.
Yes, you get a failure if an authoritative name server says that the name in question doesn't exist. In terms of my example mail sent to test@test2.coker.com.au will generate an immediate bounce. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting russell@coker.com.au (russell@coker.com.au):
45x isn't a hard fail, all the 4xx codes are for temporary failures. 45x are for corrupted mailbox, server connection problem, or server storage limit exceeded.
Yeah, as I said, it was late (here), I was very tired, and I tried to remember the SMTP spec details from fatigued memory rather than bothering to check. Surely you knew I meant 55x, though. But aspies have to aspie? ;->
It's trivial to test, put in an NS record for a subdomain of one of your domains that points to a system that's well firewalled and refuses to respond to port 53. Then send mail.
Yeah, that, for example.
http://wiki.gandi.net/en/glossary/glue-record
The above page has a good description of glue records.
Jesus, Russell. I've only been teaching people about glue records for about a quarter century. As I said, I was overdue to go to bed and had no business attempting to work through technical problems.
Rick Moen via luv-talk wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Many would say that about not having a backup MX, but anyway, guess we beg to differ on this one.
I've never known any third authoritative nameserver to be directly usable by spammers to cause a domain to DoS itself (which you may recall my saying is exactly what often happens with a backup MX).
I think I already mentioned null-mx and tarpit anti-spam techniques upthread, but I'll say it again: example.org IN MX 10 null-mx.example.org example.org IN MX 20 mail.example.org example.org IN MX 30 tarbaby.junkemailfilter.com null-mx should not listen on 25 at all -- this means you'll need a second public IP address. I don't actually know who operates tarbaby.junkemailfilter.com; it's a teergrube and I've been using it forever. For paranoia reasons I should probably host the equivalent in-house, but I have been too lazy to do so, so far. It appears to be this thing: http://wiki.junkemailfilter.com/index.php/Project_tarbaby
Quoting Trent W. Buck (trentbuck@gmail.com):
I think I already mentioned null-mx and tarpit anti-spam techniques upthread, but I'll say it again:
example.org IN MX 10 null-mx.example.org example.org IN MX 20 mail.example.org example.org IN MX 30 tarbaby.junkemailfilter.com
Sold. And thanks for the reminders. I've long considered the null-mx trick, as the logic is compelling, and just implemented now. The tarbaby thing I'm a very tiny bit leery about for the same reason you are, but am giving it a try.
Rick Moen via luv-talk wrote:
example.org IN MX 10 null-mx.example.org example.org IN MX 20 mail.example.org example.org IN MX 30 tarbaby.junkemailfilter.com
The tarbaby thing I'm a very tiny bit leery about for the same reason you are, but am giving it a try.
If you *do* set up an SMTP teergrube, I'm interested (so I can copy-paste it).
Quoting Trent W. Buck (trentbuck@gmail.com):
Rick Moen via luv-talk wrote:
example.org IN MX 10 null-mx.example.org example.org IN MX 20 mail.example.org example.org IN MX 30 tarbaby.junkemailfilter.com
The tarbaby thing I'm a very tiny bit leery about for the same reason you are, but am giving it a try.
If you *do* set up an SMTP teergrube, I'm interested (so I can copy-paste it).
To clarify, I was lazy and set up a MX 30 entry pointing to tarbaby.junkemailfilter.com -- taking on faith that it only ever tempfails.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, tl;dr -- it's fixed. On 14/10/18 18:29, Andrew McGlashan via luv-talk wrote:
On 14/10/18 18:12, Rick Moen via luv-talk wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au): I do have a DNS problem that is bugging me.....
Android phone, mobile data off, local WiFi on. Sometimes the mobile gets DNS answers for public DNS instead of the private one... running bind9.
A laptop continuously testing from the same local network as per the Android phone never, ever gets the public answer :confused:
NO other device seems to have had any problems with DNS. Shutdown and disabled dnsmasq that was "accidentally" running on OPN Sense firewall (default gateway machine). Still, I'm confused about another issue now. The Android phone, when DNS queries are made, presents as the client IP of the WiFi AP (setup as an AP and NOT as a router with NAT involved)... not sure what is causing that; I have seen it present with it's own client IP properly, but I can't find out what is causing this .... yet. However, every single query from the Android phone when connected to the WiFi access point is getting the proper private (view) answer. Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8Re0wAKCRCoFmvLt+/i +yaxAP9sZm54m+0f9/hDI2JmKQJTGA1dd5iHmgErHm6mXqbleQEA0BDD1e+0QZdC VFQ16Iq6q/ZiGnON6FXyN8Ddxoq46+E= =8ZVM -----END PGP SIGNATURE-----
On 14/10/18 18:12, Rick Moen via luv-talk wrote:
Here's the RFC wording: It is recommended that three servers be provided for most organisation level zones
Servers, not IP addresses. These days with load balancers and anycast addresses a company could have 100 DNS servers which look like one IP address from the outside. On 03/10/18 14:28, Rick Moen via luv-talk wrote:
I note that a depressingly large number of allegedly professional outsourced DNS providers violate the RFCs with dangerously thin nameservice, e.g.:
:r! whois baycon.org | grep "Name Server"
Name Server: NS1.BLUEHOST.COM Name Server: NS2.BLUEHOST.COM
There, friends, I present: Bluehost, Inc., a supposedly professional hosting company. And that is the sort of incompetence you all too frequently get when you outsource. They are using 2 DNS names (which happen to translate into 2 IP addresses). Do you know what technology (load balancers, anycast, etc) they are (not) using so you can substantiate your claim that are violating the RFC?
Quoting Kim Oldfield (luv@oldfield.wattle.id.au):
They are using 2 DNS names (which happen to translate into 2 IP addresses). Do you know what technology (load balancers, anycast, etc) they are (not) using so you can substantiate your claim that are violating the RFC?
No, for all I know, they're both massively redundant anycast network clusters spread all over multiple geographic areas, networks, and power grid segments, the way many of the 13 root nameservers are. Of course, this _does_ happen to be Bluehost, Inc., which has a long history as a singularly technically deficient and inept firm, particularly since being acquired and massively downsized. In light of which, I will sleep soundly in the face of doubts about my being unfair. ;->
On Tuesday, 16 October 2018 10:16:04 AM AEDT Rick Moen via luv-talk wrote:
Quoting Kim Oldfield (luv@oldfield.wattle.id.au):
They are using 2 DNS names (which happen to translate into 2 IP addresses). Do you know what technology (load balancers, anycast, etc) they are (not) using so you can substantiate your claim that are violating the RFC?
No, for all I know, they're both massively redundant anycast network clusters spread all over multiple geographic areas, networks, and power grid segments, the way many of the 13 root nameservers are.
Of course, this _does_ happen to be Bluehost, Inc., which has a long history as a singularly technically deficient and inept firm, particularly since being acquired and massively downsized. In light of which, I will sleep soundly in the face of doubts about my being unfair. ;->
Also FWIW I've setup monitoring scripts to check all zones that I'm remotely involved with for being resolvable via 8.8.8.8. I configured such scripts to not alert me unless it's down for more than 5 minutes, because 8.8.8.8 falsely saying that an entry doesn't exist is something that happens periodically. It's something you probably won't notice when using the Internet, but if you have a script that checks dozens of zones 24*7 then it's going to happen. I suspect that there's something a bit broken in Google DNS, but I've had bigger problems to fix. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting russell@coker.com.au (russell@coker.com.au):
On Tuesday, 16 October 2018 10:16:04 AM AEDT Rick Moen via luv-talk wrote:
Quoting Kim Oldfield (luv@oldfield.wattle.id.au):
They are using 2 DNS names (which happen to translate into 2 IP addresses). Do you know what technology (load balancers, anycast, etc) they are (not) using so you can substantiate your claim that are violating the RFC?
No, for all I know, they're both massively redundant anycast network clusters spread all over multiple geographic areas, networks, and power grid segments, the way many of the 13 root nameservers are.
Of course, this _does_ happen to be Bluehost, Inc., which has a long history as a singularly technically deficient and inept firm, particularly since being acquired and massively downsized. In light of which, I will sleep soundly in the face of doubts about my being unfair. ;->
Also FWIW I've setup monitoring scripts to check all zones that I'm remotely involved with for being resolvable via 8.8.8.8. I configured such scripts to not alert me unless it's down for more than 5 minutes, because 8.8.8.8 falsely saying that an entry doesn't exist is something that happens periodically.
Sounds extremely useful. Of course, 8.8.8.8 would be returning the result from cache, so this tells you only whether that one nameserver still has the RR with an expired time to live, right? That's valuable information, of course -- just different from knowing whether the authoritative nameservers are running & returning correct zone information, whether they are still authoritative, and whether glue records exist in the parent zones. Coincidentally, I happen to have written a (fugly) shell script for a similar need: My server (linuxmafia.com aka unixmercenary.net aka hugin.imat.com) lives at my house with an ASDL line as uplink. This past Tuesday, the firm AT&T, which is NOT my ISP but rather (in USA technical jargon) the 'ILEC' (incumbent local exchange carrier) shot in the foot my _actual_ ISP small, highly competent, highly technical firm Raw Bandwidth Communications (the 'CLEC' = competitive local exchange carrier -- taking my entire household's ADSL service offline for 2 days and 7 hours. As a matter of ethics on Tuesday, I sent mail from my fallback mail account to everyone ns1.linuxmafia.com does do authoritative DNS for, advising of downtime. Two days later, when AT&T fixed its hapless gaffe at the local exchange off and restore service, I needed to send matching mail, saying DNS service was back. But I wanted to do it semi-automatically with a script that (1) would tally up a set of all authoritative nameservers for a domain, (2) query each of them for their zonefile S/N for that domain, and (3) report that value for each nameserver. It was the usual Ops rule: Any time you're going to do a bunch of commands more than twice, it's time to script it. Here (pro bono publico) is what I came up with: Date: Fri, 26 Oct 2018 01:18:43 -0700 From: Rick Moen <rick@linuxmafia.com> To: Duncan MacKinnon <duncan1@gmail.com> Subject: ns1.linuxmafia.com downtime ended Thursday ~3pm local Greetings! This is an advisory about ns1.linuxmafia.com DNS nameserver downtime having ended. Root cause: AT&T (_not_ my ISP) sabotaged my ASDL at their local exchange around 8am Tueday, then took about 2 days and 7 hours to find and fix their problem. All services are back. ns1.linuxmafia.com is back to doing auth. nameservice, as arranged, for the following domains of yours: bluedreamz.com (master) substancez.com (master) substancez.net (master) substancez.org (master) Evidence below is via fugly shell script ~/bin/testns that I just cranked out: #!/bin/bash domain=$1 for ns in $(whois $domain | grep "Name Server" | \ awk '{ print $3 }' | tr '\r\n' ' '); do echo -n $ns 'is '; dig +short @"$ns". $domain. SOA | awk '{print $3}'; done :r! bin/testns bluedreamz.com NS1.LINUXMAFIA.COM is 2010060700 NS1.SVLUG.ORG is 2010060700 :r! bin/testns substancez.com NS1.LINUXMAFIA.COM is 2011052000 NS1.SVLUG.ORG is 2011052000 :r! bin/testns substancez.net NS1.LINUXMAFIA.COM is 2011052000 NS1.SVLUG.ORG is 2011052000 :r! bin/testns substancez.org NS1.LINUXMAFIA.COM is 2010060700 NS1.SVLUG.ORG is 2010060700
Quoting Kim Oldfield (luv@oldfield.wattle.id.au):
On 14/10/18 18:12, Rick Moen via luv-talk wrote:
Here's the RFC wording: It is recommended that three servers be provided for most organisation level zones
Servers, not IP addresses. These days with load balancers and anycast addresses a company could have 100 DNS servers which look like one IP address from the outside.
On 03/10/18 14:28, Rick Moen via luv-talk wrote:
I note that a depressingly large number of allegedly professional outsourced DNS providers violate the RFCs with dangerously thin nameservice, e.g.:
:r! whois baycon.org | grep "Name Server"
Name Server: NS1.BLUEHOST.COM Name Server: NS2.BLUEHOST.COM
There, friends, I present: Bluehost, Inc., a supposedly professional hosting company. And that is the sort of incompetence you all too frequently get when you outsource. They are using 2 DNS names (which happen to translate into 2 IP addresses). Do you know what technology (load balancers, anycast, etc) they are (not) using so you can substantiate your claim that are violating the RFC?
...oh, and also that on _many_ occasions I've smoke-tested the response from cron-scripted 'dig' queries to NS1.BLUEHOST.COM and NS2.BLUEHOST.COM on behalf of my local volunteer-run science fiction convention BayCon that hosts all of baycon.org there, gotten connection failures from one or the other, and manually double-checked and confirmed that outage to be real and persist for _days_ on end. If those FQDNs' IPs are serviced by load balancers and/or anycast networks or similar redundancy mechanisms, those must be mechanisms struck frequently with improbably severe misfortune, And it would appear that their service monitoring must be likewise frequently struck by meteors or something like that. :r /etc/cron.weekly/baycondomain #!/bin/sh # baycondomain Cron script to sanity-check the BayCon domain's SOA records at # all of its authoritative nameservers, as a quick and # dirty way of making sure (1) they're all online and # (2) they're all serving up the same data (or at least # data with the same zonefile serial number). # # The script queries all nameservers for their current # SOA value (for baycon.org), and then uses awk to parse # out of that verbose record just the S/N field, which is # field #3. The point is that you can visually spot offline # or aberrant nameservers by their S/Ns being (respectively) # missing or an out-of-step value. # # Written by Rick Moen (rick@linuxmafia.com) # $Id: cron.weekly,v 1.01 2011/05/08 07:04:55 rick set -o errexit #aka "set -e": exit if any line returns non-true value set -o nounset #aka "set -u": exit upon finding an uninitialised variable test -x /usr/bin/mail || exit 0 { dig -t soa baycon.org. @NS1.BLUEHOST.COM. +short | awk {'print $3'} dig -t soa baycon.org. @NS2.BLUEHOST.COM. +short | awk {'print $3'} } | /usr/bin/mail -s "Domain baycon.org SOA check" rick@linuxmafia.com
On Sunday, 14 October 2018 5:01:41 PM AEDT Andrew McGlashan via luv-talk wrote:
On 03/10/18 14:28, Rick Moen via luv-talk wrote:
RFC2182 section 5 recommends minimum 3, maximum 7 authoritative nameservers for a domain, so five is pretty good.
RECOMMEND ....
Minimum is two, I've never seen any problems having just two with both being on different Internet links at different locations. It wouldn't
daisee.com. 21599 IN NS ns-1221.awsdns-24.org. daisee.com. 21599 IN NS ns-2000.awsdns-58.co.uk. daisee.com. 21599 IN NS ns-912.awsdns-50.net. daisee.com. 21599 IN NS ns-420.awsdns-52.com. If you use "Route 53" (the DNS service from Amazon) then by default you get 4 authoritative name servers such as the above from different regions and different TLDs. I don't know if this is because the Amazon SREs have encountered unusual situations where multiple TLDs have become unavailable for some reason making this sort of thing genuinely necessary or whether they are just going over the top to convince customers that they will get an unreasonable number of "nines" of uptime. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 14/10/18 23:21, Russell Coker via luv-talk wrote:
On Sunday, 14 October 2018 5:01:41 PM AEDT Andrew McGlashan via luv-talk wrote:
On 03/10/18 14:28, Rick Moen via luv-talk wrote:
RFC2182 section 5 recommends minimum 3, maximum 7 authoritative nameservers for a domain, so five is pretty good.
RECOMMEND ....
Minimum is two, I've never seen any problems having just two with both being on different Internet links at different locations. It wouldn't
daisee.com. 21599 IN NS ns-1221.awsdns-24.org. daisee.com. 21599 IN NS ns-2000.awsdns-58.co.uk. daisee.com. 21599 IN NS ns-912.awsdns-50.net. daisee.com. 21599 IN NS ns-420.awsdns-52.com.
If you use "Route 53" (the DNS service from Amazon) then by default you get 4 authoritative name servers such as the above from different regions and different TLDs.
It's not unusual for businesses with one domain name, to have lots more covering all sorts of combinations in a similar manner to protecting trade marks. example.com example.net example.com.au .... ... This can easily get out of hand as well. Of course, "example" above could go with other options that suit the business without having just one base domain name to work from with a bunch of TLDs for each one as they make sense. There are long version domain names and short versions too; all of which are like "holding" real estate to some degree, protecting the brands and products on offer from the business. Given that I manage a number of my own domains and a bunch of others that I manage rely upon my name servers, I will put in place a third authoritative name server at some stage, hopefully fairly soon too. It wont hurt, but as I've got so many domains to manage, I won't palm this off to anyone, I'll handle it myself on a friend's machine (I manage his servers anyway). He has always said that I could put a name server there, but I never thought it was necessary, nor useful enough to worry about. Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8NN9gAKCRCoFmvLt+/i +8JMAPsEBB7VLMU9heWI6/MzibwO54CKJaXAaOfvaZKLjXJCYAD7B77I8dGhzyXM V+7n6ktEHxgpZIQMwZivQOvYgx+RDGk= =tLkh -----END PGP SIGNATURE-----
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Given that I manage a number of my own domains and a bunch of others that I manage rely upon my name servers, I will put in place a third authoritative name server at some stage, hopefully fairly soon too.
It wont hurt, but as I've got so many domains to manage, I won't palm this off to anyone, I'll handle it myself on a friend's machine (I manage his servers anyway). He has always said that I could put a name server there, but I never thought it was necessary, nor useful enough to worry about.
This is the sort of thing I do, with a small circle of friends: We all run authoritative nameservers, and each do secondary for each other. I can offer one somewhat amusing cautionary tale, on a theme of 'people are flaky, and need to be checked up on'. The underlying assumption of mutual secondary nameservice for friends is that each will do the bare minimum to avoid screwing up, if only out of Golden Rule concerns. After all, after initial setup, there's zero work to do. Secondaries just track what the primary does. Should be pretty foolproof, right? Into this idyllic picture steps the Pacific Coast beach town of Santa Cruz, California, across the Santa Cruz Mountains from Silicon Valley and about 150 km south of San Francisco. Santa Cruz is a hippie haven, long home of many fundamentally flaky people, with a laid-back demeanour at sharp odds with Silicon Valley's work ethic. Santa Cruz is best known for its beach-side amusement park and for surfing. I'm told I rankle some Santa Cruzans with my brisk manner and binary logic. 'It's a local motion issue', a friend helpfully explained. Around 2000, a young man named Jacob Hunter launched a Santa Cruz LUG with the wince-worthy name Santa [C]ruz Microsoft-Alternative User Group or SMAUG. (Great, now we're defining ourselves in reference to Microsoft?) Santa Cruzans liked the whimsy and whiff of fantasy. A number of us from VA Linux Systems would occasionally drive over the mountains to help Jacob. Jacob had not bothered to ensure that a suitable Internet domain was available before naming his group. After flailing around a bit, he registered scruz.org . A Linux-oriented business owner in Colorado with the glorious name of Crawford Rainwater underwrote the domain registration. I and five other volunteers stepped forward to do authoritative nameservice, with my ns1.linuxmafia.com serving as master. It all tested well, and we rested in the knowledge that the infrastructure had massive redundancy. Roll forward a couple of years. Cue 'uh-oh' music. One day during a winter storm, my house (where ns1.linuxmafia.com lives) had a few hours without electrical power. When service was restored, I found several people complaining that scruz.org had been completely unresolvable. The period of outage corresponded suspiciously to my house's power outage. Moreover, one of the people complaining most bitterly, and suggesting it was somehow all my fault, was the operator of one of the DNS secondaries for the domain. I smelled a rodent.... After some work using whois and dig, and a couple of telephone calls, I uncovered the full picture. Over those couple of years since domain setups: o Two of the Santa Cruzans had re-IPed their nameservers, and not bothered to inform the master. o Another of the Santa Cruzans had retired his nameserver, and not bothered to inform the master. o Another of the Santa Cruzans' nameservers was working but he'd unilaterally decided to cease serving the scruz.org domain, and not bothered to inform the master. o The fifth secondary operator could no longer be contacted, and both he and his nameserver had simply vanished. The domain showed as having six auth nameservers, but de-facto, after flaky admin defections, it had eroded to one -- thus dropping off the Net during my power outage. I explained said debacle to the assembled (who doubtless assumed I was just being mean, and needed more surfboard time), then fixed the nameservice -- and created weekly cron jobs such as the one I recently posted here to check DNS particulars rather than trusting to friends to not be flaky. SMAUG limped along for a few more years and then collapsed because the Santa Cruzans couldn't be bothered to keep it running.
Rick Moen via luv-talk wrote:
The domain showed as having six auth nameservers, but de-facto, after flaky admin defections, it had eroded to one.
Well, isn't that why you run something like nagios, to constantly check whether things that should stay the same, actually do? (Except IME nagios gets confused and sends alerts so often that you end up ignoring it forever, putting you back where you started.)
Quoting Trent W. Buck (trentbuck@gmail.com):
Well, isn't that why you run something like nagios, to constantly check whether things that should stay the same, actually do?
Well, at work, yeah. But the shoemakers' kids tend to go barefoot. (I'm over being sheepish about this, and have reconciled myself to gradually filling in various 'good enough' kludges, whenever the dry side of the dike starts getting too wet.) Current example of problem-solving automation shooting me in the foot: http://linuxmafia.com/pipermail/conspire/2018-August/009325.html
On Wednesday, 3 October 2018 8:36:00 AM AEDT Brian May via luv-talk wrote:
1. Hosting the DNS domain. This is easy. There are providers that will do this for free. e.g. https://dns.he.net, although it looks like this particular one is closed beta. Currently they don't support DNSSEC, which may not actually be an issue here.
While not strictly within the scope of LUV, as we do have a LUV DNS server and the costs of running DNS are very small there's no reason why we couldn't do that for LUV members. All the systems running DNS for luv.asn.au are under my control and I can set them up to run DNS for LUV members.
2. Hosting the email. This one requires keeping up to date with latest SPAM filtering standards, etc. Not so easy, especially if you are short on time. I believe there are third party services you can use to do the spam filtering for you and still use your own mail server, but I haven't had experience here. I personally use a paid account at https://kolabnow.com, and point my domain there. https://protonmail.com looks very interesting too.
There's probably more than a few LUV members who could offer this as a service. I could host some more domains on the server that runs my mail. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Rohan McLeod (rhn@jeack.com.au):
-Trent is pointing out the huge number of 'gotcha's', which would be involved in that path
Care to guess who you reduce that 'large number' to a very small one? You just eschew _obvious_ mistakes. E.g.: 1. SMTP servers require static IP addresses that are from a decent provider (one that doesn't block outbound ports) and allocated from a static IP address netblock. 2. SMTP servers require valid rDNS that matches forward lookup. 3. SMTP servers require correct, strongly asserted SPF RRs. 4. SMTP servers must not have their distro default MTA configurations manually sabotaged to accidentally create an open relay. 5. SMTP servers should have data that matter backed up because all data that matters should be backed up. You might object: not obvious to everyone. True! They are not immediately obvious to someone newly arrived at the notion of running his/her own SMTP server, _but_ OTOH they are pretty much the first things an interested newcomer will find in basic cautions and documentation, _or_ said newcomer will immediately hear on a LUG mailing list if he/she asks 'What requirements should I meet in order to run my own SMTP mail server?' Happily, LUV offers that exact variety of assistance. Quod erat demonstrandum. That reduces Trent's 'large number' to a very small number, namely one: 1. SMTP servers in 2018 need manual, post-install work by the local sysadmin to make the MTA configuration spam-resistant, otherwise the rain of it will annoy until you decide to do that work. That's indeed non-trivial work -- but worth the effort, and not brain-surgery.
Rick Moen via luv-talk wrote:
Quoting Rohan McLeod (rhn@jeack.com.au):
-Trent is pointing out the huge number of 'gotcha's', which would be involved in that path Care to guess who you reduce that 'large number' to a very small one? You just eschew _obvious_ mistakes. E.g.:
1. SMTP servers require static IP addresses that are from a decent provider (one that doesn't block outbound ports) and allocated from a static IP address netblock. 2. SMTP servers require valid rDNS that matches forward lookup. 3. SMTP servers require correct, strongly asserted SPF RRs. 4. SMTP servers must not have their distro default MTA configurations manually sabotaged to accidentally create an open relay. 5. SMTP servers should have data that matter backed up because all data that matters should be backed up.
You might object: not obvious to everyone. True! They are not immediately obvious to someone newly arrived at the notion of running his/her own SMTP server, _but_ OTOH they are pretty much the first things an interested newcomer will find in basic cautions and documentation, _or_ said newcomer will immediately hear on a LUG mailing list if he/she asks 'What requirements should I meet in order to run my own SMTP mail server?'
Happily, LUV offers that exact variety of assistance. Quod erat demonstrandum.
That reduces Trent's 'large number' to a very small number, namely one:
1. SMTP servers in 2018 need manual, post-install work by the local sysadmin to make the MTA configuration spam-resistant, otherwise the rain of it will annoy until you decide to do that work.
That's indeed non-trivial work -- but worth the effort, and not brain-surgery.
Rick many thanks for your encouragement and apologies if I sounded as though I was abandoning, the DIY spirit of the hacker community (original sense); what do you think of my idea that first I try to acquire the domain name, then have it hosted by a third party, then at some later time try immitating your example ? regards Rohan McLeod
Quoting Rohan McLeod (rhn@jeack.com.au):
Rick many thanks for your encouragement and apologies if I sounded as though I was abandoning,
I didn't worry about that, but you're very welcome. (That's a verbose, North American alternative to the much more sonorous, cheery, and concise Oz expression. ;-> )
the DIY spirit of the hacker community (original sense); what do you think of my idea that first I try to acquire the domain name, then have it hosted by a third party, then at some later time try immitating your example ?
I think it's a really splendid idea. First of all, it wins in the sense of accomplishing the easy parts and deferring the difficult parts. Also, it makes give you something that is yours and can be migrated. Which is to say, domains and related DNS are modular parts of the solution. You can use best of breed for each of the modular pieces. Implement each of them wherever best suits your needs, and bear in mind your freedom to move each to somewhere different.
Quoting Trent W. Buck (trentbuck@gmail.com):
Rick Moen via luv-talk wrote:
2. SMTP servers require valid rDNS that matches forward lookup.
Note how I forgot this one in my earlier checklist :-)
And the bit about a strongly asserted SPF reference record, making your point further. ;->
On Wednesday, 3 October 2018 8:19:29 AM AEDT Rohan McLeod via luv-talk wrote:
- What about if I could just acquire "jeack.com.au" (at the moment that seems analogous to owning a company name); then have the domain hosted by someone else ? Thus postponing hosting it myself !
The requirement for a .com.au to refer to an Australian company appears not to have been enforced for some years. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 14/10/18 15:13, Russell Coker via luv-talk wrote:
On Wednesday, 3 October 2018 8:19:29 AM AEDT Rohan McLeod via luv-talk wrote:
- What about if I could just acquire "jeack.com.au" (at the moment that seems analogous to owning a company name); then have the domain hosted by someone else ? Thus postponing hosting it myself !
The requirement for a .com.au to refer to an Australian company appears not to have been enforced for some years.
There are alternate rules, you don't have to be a company per se, but you do need to have a product or service as an alternative "reason" to have said domain name. There are plenty of temporary .com.au domain names that are used for competition and/or other marketing purposes that wouldn't fit the ordinary "name" rules. Still, .com.au are meant to be entirely for "commercial purposes". Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW8LaaAAKCRCoFmvLt+/i +1iiAQC9jyverQivk6oybA5ljcDUhINbEsxEAmS7kTGdtoSghQEAkJjjFGpouJJn 0gcxYv1siaC0XlFR0/Xqv/UEz1NjyuA= =zDkS -----END PGP SIGNATURE-----
Russell Coker wrote:
On Wednesday, 3 October 2018 8:19:29 AM AEDT Rohan McLeod via luv-talk wrote:
- What about if I could just acquire "jeack.com.au" (at the moment that seems analogous to owning a company name); then have the domain hosted by someone else ? Thus postponing hosting it myself ! The requirement for a .com.au to refer to an Australian company appears not to have been enforced for some years.
Russell and Andrew; thanks for your thoughts on this matter. Just to update the situation in my email above - I am definitely going with this idea of first attempting to 'own'; the above domain and postponing 'hosting' it - The relevant person at the domain 'registrant' (PlanetDomain Pty Ltd) has assured me that; the current 'owner' (Hotkey) has some ? contractual obligations concerning the domain - The relevant person at Hotkey seems quite helpful and is looking into the technical issue of whether I am the sole 'user' of the domain, this seems to amount to whether I am the only person with" jeack.com.au" after the "@" symbol in their email adress - He has informed me via email that the requirements for 'owning' com.au and net.au are: --An Australian registered company --Trading under a registered business name in any Australian State or Territory --An Australian partnership or sole trade --A foreign company licensed to trade in Australia --Be an owner of an Australian Registered Trade Mark --An applicant for an Australian Registered Trade Mark --An association incorporated in any Australian State or Territory --An Australian commercial statutory body Now since I am looking for the simplest(and hopefully the cheapest :-)) possible solution to the problem; my questions are : - Does the 'entity' (ie any of the above) which owns the domain need to have "jeack' in it's name ? -- because purchasing the company and company name " Jeack Pty Ltd " is actually an option but a complex and expensive one ! -- IF NOT a much simpler and cheaper option is to own it via one of two "registered business names" which I already have regards Rohan McLeod mclrhn@vfemail.net
On Sunday, 14 October 2018 5:44:00 PM AEDT Rohan McLeod via luv-talk wrote:
- I am definitely going with this idea of first attempting to 'own'; the above domain and postponing 'hosting' it
If you want quick hosting, that can be done in a matter of minutes. Once you have a mail server with more than a few domains adding another isn't difficult.
- He has informed me via email that the requirements for 'owning' com.au and net.au are:
--An Australian registered company --Trading under a registered business name in any Australian State or Territory --An Australian partnership or sole trade
These don't appear to be enforced, but I can understand someone wanting to strictly comply with all requirements when doing unusual things. https://www.ato.gov.au/Business/Starting-your-own-business/Before-you-get-st... https://www.business.gov.au/planning/business-structures-and-types/business-... To be a sole trader just register for an ABN. https://www.business.gov.au/Registrations/Register-for-an-Australian-Busines... Applying for an ABN is free. You just have to declare that you plan to do some work as a sole trader.
my questions are : - Does the 'entity' (ie any of the above) which owns the domain need to have "jeack' in it's name ?
Not sure, but it wouldn't do any harm. "Rohan McLeod trading as Jeack Computers" sounds nice.
-- because purchasing the company and company name " Jeack Pty Ltd " is actually an option but a complex and expensive one !
You definitely don't need that.
-- IF NOT a much simpler and cheaper option is to own it via one of two "registered business names" which I already have
A registered business name which doesn't correlate to the domain name seems unlikely to be well accepted. You aren't trying to convince the people who delegate .com.au (who don't seem to care), you are trying to convince the ISP that owns the name. As you have used jeack in a lot of online correspondence related to Linux stuff, it seems almost like a personal brand for you. Making it some sort of registered business name seems like a good strategy. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tuesday, 2 October 2018 6:43:17 PM AEDT Rohan McLeod via luv-talk wrote:
who was going to look into whether I was the sole 'user of the domain' ?; if the domain name became available....I might just consider that path !
Do it. It's a good educational experience. Come to the Saturday LUV meetings and we will help you to set it up. There's usually at least 2 people there who run their own mail servers. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Rick Moen via luv-talk wrote:
Quoting Rohan McLeod (rhn@jeack.com.au):
What I will do now is start to look around for a durable non-web email address ; that is obviously not tied to a particular ISP ...suggestions welcome!
1. Register your own domain. 2. Do your own DNS. 3. Host your own mail.
Works for Me.™
This *may* be beyond Rohan's current skill level. Setting up a "good enough" mail server is not terribly hard, but if you've never done it before, there are several gotchas, e.g. * what do you mean my ISP blocks outbound 25 unless I upgrade to a "business grade" ADSL subscription? * what do you mean other MTAs auto-block me because my IP address is listed as being in a "dynamically assigned by the ISP range?" * what do you mean I accidentally became an open gateway for a couple of days, and now RBLs are blacklisting me? * what do you mean I forgot to put rate limiting or 2FA on the SASL, and someone is reading all my mail and maybe privesc'd to root and installed an open-access FTP server and/or bitcoin minerd? * what do you mean I actually get spam again, because I didn't know to do all the little things to stop getting spam? (e.g. null MX, tarpit MX, postscreen, maybe even crm114 if your username is something like "sales") * what do you mean I should have a second, offsite, MX? (and, like, ANY backup regimen?) Rohan, if you don't care about the US government reading your mail, the cheapest and easiest answer will be one of the big mail vendors (like gmail). You can acces them via IMAP/SMTP, no browser required. I don't know if they block Tor. You can pay them a little extra and they'll be the backend for a custom domain you own (e.g. if you want to be rohan@example.com, you buy example.com and pay gmail to be the mail server for it). It sounds like you *do* care about that, in which case you should probably stop using email altogether, because enough mail passes through the US that they can work out what's going on anyway. Organize your terror cell using traditional methods, entirely OFFLINE. I think I saw some SOE field manuals about this on gutenberg.net.
Quoting Trent W. Buck (trentbuck@gmail.com):
This *may* be beyond Rohan's current skill level.
To be sure. It was beyond mine when I did it, too. (I was not an IT guy at the time.) Fortunately, nobody told me I lacked the necessary skills, so I just worked through configuration (on a real static IP), and it worked.
* what do you mean I should have a second, offsite, MX?
I very much do not agree, FWIW. Additional MXes are now an actively bad idea, because of collateral damage from the spam problem. Back in the early 2000s, I noticed that spammers preferentially delivered mail to high-numbered MXes even when the low-numbered ones are fully reachable. This isn't ineptitude but rather strategy. It's very common for backup MXes to have looser antispam regimes, so from the spammer's tactical perspective the initial delivery is more likely to be successful. Then, when follows of course is your backup MX attempting to redeliver to your primary MX, and your primary MX either refusing delivery or punishing the delivering MTA, e.g., with teergrubing and similar. So, the spammer has conjured up a scenario where your MXes are DoSing each other over spam redelivery. The best-case (or, I would say, least-bad-case) version of that scenario is where you apply identical antispam policies to both backup and primary MX (i.e., you abandon the old model where friends do backup MX for each other and run both hosts): In that case, your backup MX is still going to be accepting a certain amount of spam, and facing the no-win dilemma about what to do with it: Try to redeliver to the primary MX (aka your MTAs DoSing each other), issue a failure Delivery Status Notification (aka generating backscatter spam), or discarding/spamboxing it. IMO, it's smarter to dispense with the idea of backup MXes and just know that you have about four days to SMTP restore service somewhere in the world before failure DSNs start. (Fortunately, that's not really difficult).
Trent W. Buck wrote:
* what do you mean I actually get spam again, because I didn't know to do all the little things to stop getting spam? (e.g. null MX, tarpit MX, postscreen, maybe even crm114 if your username is something like "sales")
Incidentally, anyone using postscreen's "expensive" tests? http://www.postfix.org/POSTSCREEN_README.html#after_220 If so, how do you deal with large mail networks (e.g. bigpond, gmail) retrying from a different IP address? Do you use https://github.com/stevejenkins/postwhite ? Do you use a negative postscreen_dnsbl_whitelist_threshold ? Does it Just Work with no special action?
participants (8)
-
Andrew McGlashan -
Brian May -
Kim Oldfield -
Mark Trickett -
Rick Moen -
Rohan McLeod -
Russell Coker -
Trent W. Buck