While looking in my DNS records I found SRV records but don't know how they got there

For background info, I operate behind a DHCP non-commercial connection, and late last month I tried having one of my three domains run with BIND on my Virtualmin server. The FQDN’s were bought at Google Domains. On Google’s DNS settings I turned off the DNSSEC, waited two days, then switched from Google’s nameservers to mine on my Virtualmin server, and waited a couple more days. Things worked right for the most part, but my main goal was to have eMail and all the features work right (DKIM, SPF, DMARC). I came close, but because Spamhaus ZEN and SORBS DUHL blacklisting my IP, I still had to bounce messages off MailGun for general delivery to the masses (Yahoo!, Gmail).

I decided to roll-back and have Google be the nameserver and DNS record giver again. I was going through the DNS entries on Virtualmin and putting the appropriate ones on Google.
Virtualmin => Server Configuration => DNS Records | [Manually Edit Records].
One thing I never saw before was a section in the file that looked like this:

_autoconfig._tcp.MYFQDN.tld. 3600 IN SRV 0 1 80 mail.MYFQDN.tld.
_autodiscover._tcp.MYFQDN.tld. 3600 IN SRV 0 1 80 mail.MYFQDN.tld.
_imap._tcp.MYFQDN.tld. 3600 IN SRV 0 1 143 mail.MYFQDN.tld.
_imaps._tcp.MYFQDN.tld. 3600 IN SRV 0 1 993 mail.MYFQDN.tld.
_pop3._tcp.MYFQDN.tld. 3600 IN SRV 0 1 110 mail.MYFQDN.tld.
_pop3s._tcp.MYFQDN.tld. 3600 IN SRV 0 1 995 mail.MYFQDN.tld.
_submission._tcp.MYFQDN.tld. 3600 IN SRV 0 1 587 mail.MYFQDN.tld.

I don’t know how it got there, and it vanished sometime between the roll-back and the time of writing this. If I hadn’t transposed them to Google, I wouldn’t have been able to say what I saw!

I was going to put similar records on Google for the other two domains, but couldn’t find them or figure out how to have them appear by clicking buttons in Virtualmin.

So my question is, why were they there, and how did they get there? Are they meaningless on the Google DNS custom resource records? I don’t see the K-9 Mail guessing right from autoconfigure, so is that K-9’s fault or mine for not having a static IP to work with?

If MailGun uses LDAP, Active Directory or similar authentication system, it might explain the SRV records, which are similar to MX records for looking up mail hosts. The only way they could have ended up in a domain’s zone was by Virtualmin’s BIND. Google DNS may do the same if you don’t get to it first.

SORBS has always been an overzealous pain-in-the-assets… Don’t get me started.

As for Android clients, I doubt K-9 supports autoconfig but you should be able to override it with manual settings.

I don’t know enough about what I’m about to say, so there’s that. I only use MailGun to send messages out, and they have a single UserID, Password combo for each FQDN. I receive eMails directly to the Virtualmin server. So outbound mail will hit my Postfix and it will lookup then send through MailGun based on my sender_dependent_relayhost_map & smtp_sasl_password_map files. I don’t think there’s any LDAP connection.

At the same time I switched that one domain to work only through Virtualmin’s BIND, I shut off the MailGun connection for that virtual-server. I was testing the mail system by sending from Virtualmin created addresses for that FQDN to Gmail & Yahoo! as well as other FQDN’s on my server via mobile devices using no WiFi. Only the ones to my own FQDN’s got delivered and looking at the IP hops I know they weren’t handled internally. I made that mistake with early tests :wink: thinking I was sending externally and finding out it just stayed on the server.

So those SRV records appeared after the testing of the system and vanished on their own after I reconnected it to Google nameservers and started using MailGun again.

I just looked at the SORBS delisting thing and vaguely remember this run around years ago before giving up and using MailGun.

That K-9 client must be as you say because what I did for testing last week was just write “mail” where it guessed “imap” and “smtp”.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.