0

I recently acquired a domain on GoDaddy auctions on behalf of a client for their new business's website. I am building the site and hosting it.

I am in the process of configuring Google Workspaces and just finished adding txt record verification and mx records. Important to note is that while Godaddy is the registrar, I'm not using their nameservers, I'm using Digital Ocean's.

When I go to validate the mx records, I notice that the *.aspmx.l.google.com are all still propagating. However, there's an odd record showing up that I have not set anywhere that Google says needs to be deleted.

1    @     mail.picklehost.com     86400

Never encountered this before, and never managed an auctioned off domain. Few questions:

  • Do auctioned off domains commonly come with DNS baggage?

  • If so, is that something you typically just chill and wait for?

  • Why might Google Workspaces pick up an MX record that has not been set?


Below are some dns readouts from my research. the secureserver.net people initially said "you need to log into your dns and remove the record" but when I said "that's not the problem, I never set this record" they hung up on me.

NS Records :

[0] Name : mail.picklehost.com | value: ns1.totalpc.com. | ttl: 21600
[1] Name : mail.picklehost.com | value: ns2.totalpc.com. | ttl: 21600

------------------

1

2 Answers 2

1

Do auctioned off domains commonly come with DNS baggage?

If you acquire a domain from someone else it might have a working resolution already, so yet it might have DNS settings.

If so, is that something you typically just chill and wait for?

Once the domain is yours you are free to change the DNS settings (either/or the nameservers or their content aka the zone). As with any DNS changes, it may take some time to see the change, depending on how you test. Note that, contrary to popular belief, there is NO propagation, this is the wrong term to use.

Why might Google Workspaces pick up an MX record that has not been set?

You will have to ask the relevant provider on what it does or why it gets those results.

If you do a test on dnsviz.net (a very good online troubleshooting tool), it shows your domain as correctly configured, so this is well. See specifically: https://dnsviz.net/d/picklehost.com/Yc4RqA/dnssec/

If you query the authoritative nameservers for apex MX records you get:

$ dig @ns1.totalpc.com. picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.
$ dig @ns2.totalpc.com. picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.

so no taces of other MX hosts, and some major recursive servers have the correct data too:

$ dig @1.1.1.1 picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.
$ dig @8.8.8.8 picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.
$ dig @9.9.9.9 picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.

But if you queried right before doing the change, then your local recursive nameserver is having the old data in its cache, for 4 hours maybe or something else (what TTL the previous MX records had).

PS: for your kind of problem, the whois part is irrelevant for troubleshooting.

1
  • Thanks, Patrick. dnsviz is a great resource that will come in handy in the future. Also appreciate the tip re: whois. Good lookin out. Dec 30, 2021 at 22:24
1

Do auctioned off domains commonly come with DNS baggage?

The worst case may be some caching (typically then 1 day) of old information. This will only affect a small number of users, and is not normally a significant issue once the nameservers have been updated. Its certainly not the issue you are experiencing here.

Why might Google Workspaces pick up an MX record that has not been set?

In this case your the MX record HAS been set. If we do a query on the authorative nameservers (ie ns1.totalpc.com/ns2.totalpc.com) it provides an MX record of 0 picklehost.com. This is not a caching issue - the domains are authoritatively answering incorrectly -

mypcname:~$ dig @ns1.totalpc.com picklehost.com mx

; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.totalpc.com picklehost.com mx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33544
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 797182d97c7174f35f87dc2f61ce2fa5ad7fcb755c02f359 (good)
;; QUESTION SECTION:
;picklehost.com.            IN  MX

;; ANSWER SECTION:
picklehost.com.     14400   IN  MX  0 picklehost.com.

;; AUTHORITY SECTION:
picklehost.com.     86400   IN  NS  ns1.totalpc.com.
picklehost.com.     86400   IN  NS  ns2.totalpc.com.

;; ADDITIONAL SECTION:
picklehost.com.     14400   IN  A   170.249.198.42
ns1.totalpc.com.    14400   IN  A   170.249.198.42
ns2.totalpc.com.    14400   IN  A   170.249.198.43

;; Query time: 196 msec
;; SERVER: 170.249.198.42#53(170.249.198.42)
;; WHEN: Fri Dec 31 11:16:05 NZDT 2021
;; MSG SIZE  rcvd: 179

This really is an issue with your DNS provider - likely their web interface is not correctly reflecting the underlying zone. This is something that has to be fixed in the nameservers. (If They won't fix it for you, find a new nameserver provider and update your DNS servers with your registrar to bypass the problem).

You say you are using Digital Oceans nameservers - but I think this is incorrect. Your registrar/whois information and DNS all say totalpc.com are providing your DNS. This is likely your problem - maybe your registrar has not updated the nameservers?

4
  • So...I have example.com on digital ocean's nameservers. When making a Google workspace for example.com in the mx validation step I'm seeing an mx record for example.com pointing to mail.picklehost.com. So it was that I have no idea what picklehost.com is or where mail.picklehost.com was even coming from. Between your answer and Patrick's tho I know what to do now. I appreciate you both for taking the time to answer. Dec 30, 2021 at 22:32
  • " the domains are authoritatively answering incorrectly -" Why do you say that? The MX record is valid, it is totally allowed to point to apex as long as it resolves to an IP. Dec 31, 2021 at 0:54
  • !PatrickMevzek After the OP's last comment - I am not sure I understood the question correctly - I was working on the basis that the domain in question was "picklehost.com". When I did an authorative lookup for "picklehost.com" I got an MX for picklehost.com - and from the OP's question I understood the correct result was meant to be GMAILS MX records. This pointed to a problem in the nameservers zone itself.
    – davidgo
    Dec 31, 2021 at 1:05
  • You can just call me Mike dude. Both answers here gave me new knowledge, however, as I posited in my question, I just chilled and the record went away. Jan 4 at 5:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.