[RCU] Misconfigured Mailing List DNS
roundcube at ptld.com
roundcube at ptld.com
Sun Aug 15 18:48:00 CEST 2021
> On 08-15-2021 11:12 am, Reindl Harald wrote:
Just wow. Okay, i didn't want to over explain, because i assumed
everyone here would know what FQND, FCrDNS, PTR's and MX records are.
Sorry if my lack of over explanation was confusing to read. Let me over
explain it now and what i meant. Im just surprised at how many people
who's gig is email get so much of this wrong.
>> I got an email from this mailing list...
>> Client IP = 18.104.22.168 -> mx.kolabsys.com
> this is a PTR
Yes, a PTR record is a mapping from an IP to a FQDN. So when you lookup
host for 22.214.171.124 you get mx.kolabsys.com
>> Client PTR = mx.kolabsys.com -> 126.96.36.199
>> -> 188.8.131.52
>> -> 184.108.40.206
>> -> 220.127.116.11
>> -> 18.104.22.168
>> -> 22.214.171.124
> this is not a PTR
This is where you got confused. I did not say those IP's where PTR's. I
said the client PTR (mapping of 126.96.36.199) = (see the = above)
mx.kolabsys.com which is a FQDN, and that FQDN maps back to -> those
IP's. Now IMO you should not share multiple IP's for the same PTR
record. Each IP should have its *OWN* PTR unique identifier AKA FQDN.
>> Kind of okay there, at least it maps back, however i have never seen
>> PTR sharing the same domain like that. Not sure that won't have
>> strange side effects. But then that client gave a HELO of...
> you don't have the slightest idea what you are talking about when you
> even don't know what a PTR or a cloud is
What the heck does cloud have to do with DNS or PTR records. Don't throw
around buzz words in an attempt to sound smart. Cloud isn't even a
thing, its a loose concept which can mean different things, its just a
marketing word to sell services. "Cloud servers" are just VPS servers.
Email nor DNS cares or even knows the difference between a "cloud
server" or a dedicated server. Its just a server reachable by an IP.
> [harry at srv-rhsoft:~]$ dig MX lists.roundcube.net
Now your last dig brings up something else wrong with the DNS. You can
see they did their mx "round robin" kind of correctly for kolabsys.com,
listing multiple mx records. But then they have two IP's listed for each
mx record. Totally unnecessary as that is what the multiple mx records
already covers. If they wanted 6 servers for receiving email they should
just make 6 mx records, not some hybrid of three "round robin" mx
records mixed with two "round robin" IP's. It serves no purpose. There
is nothing gained by listing multiple IP's to a single mx record as
clients are just going to pick one of those IP's at random to try same
as they just picked one of those three evenly weighted mx records
Then for the lists.roundcube.net mx records they have just one record,
and that one record then has six evenly weighted IP's which clients are
just going to pick one at random. Again they should have just made six
mx records so each server is uniquely identifiable. This was how mx
record were designed to be used, this is why they have weighted numbers
attached to them. They aren't even being consistent in their
methodology. One mx system is a hybrid 3 times 2 "round robin" and the
other mx system is a 1 times 6 "round robin". There is no limitation on
giving every server its *OWN* FQDN and having uniquely valid FCrDNS for
The way they set it up IMO is not good. Just for logging reasons alone
you would want each server to have its own FQDN / FCrDNS so when you get
a message that something happened on server mx.kolabsys.com you know
which server it is. Not having to guess if it was 188.8.131.52,
184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124 or
126.96.36.199. They are not saving anything by sharing the same PTR.
But none of that has anything to do with the problem that i wrote this
email about in the first place. They are using a HELO FQDN that does NOT
map back to the server using it. Maybe if the DNS followed a more clean
methodology, every server having its own unique FCrDNS with the HELO
matching PTR then maybe the confusion of allowing an invalid HELO FQDN
wouldn't have happened. As it sits now they might as well have made the
HELO be gmail-smtp-in.l.google.com as it would have the same result.
So before you come across all aggressive telling someone "you don't have
the slightest idea what you are talking about when you even don't know
what a PTR or a cloud is" make sure at the very least YOU know what the
heck you are talking about.
More information about the users