Join Log in
Score:0
jdmayfield avatar Server

Network Solutions DNS not always returning DKIM and SPF records

cn flag
jdmayfield

If there is a more appropriate place to ask this or it is a duplicate, please tell me.

I have a client who hosts their domains with Network Solutions. Some of their emails were bouncing due to stricter authorization requirements enforced on certain recieving mail-servers. This was because they had no DKIM, SPF, or DMARC policy. So I set SPF and DKIM up for them-- DMARC pending a solution to the following:

Problem is, the records seem to be failing to retrieve quite frequently. Specifically this is from ns89.worldnic.com and ns90.worldnic.com . I've used both dig and mxtoolbox.com to perform repeated tests, and it's a crapshoot.

I have set many, many DKIM, SPF, and DMARC records up, or provided needed tweaks and changes to them-- probably hundreds of times by now. I am aware of the 48 hour rule. Definitely been more than 48 hours since I set the SPF record. Not quite 24 for the DKIM.

In the many instances of setting up these kinds of records I have rarely had to wait more than 5 or 10 minutes to get solid record retrievals. Usually this is with other registrars. Not sure when the last time I set up SPF, DKIM, and DMARC on Network Solutions was.

Client is still getting some bounces, specifically stating due to missing SPF records, which is exactly why I started repeatedly testing retrieval, and sure enough-- I'd say it's about 80 to 90% successful for those two specific nameservers. That means there is a minimum 10 to 20% bounce rate for this particular recieving MX, which has adopted a hard stance on the existence of SPF and/or DKIM authentication mechanisms.

Is there a problem with their nameservers, is there something else that could cause their nameservers to frequently not return records, or am I just being impatient? I've never had this problem before, but cannot find any information reporting outages with their nameservers. Are they under a DDOS attack? They seem to be replying, but the replies appear unstable.

My Google-fu is, unfortunately only turning up advertisements on how great NetSol is, and a bunch of completely unrelated stuff involving networking, mostly ads.

The SPF and DKIM test good according to all the following methods below, if they are successfully retrieved, so the problem is definitely not in the keys themselves.

I.e. using the following patterns:

SPF txt record, ttl 15 mins, hostname @

v=spf1 include:emailsrvr.com ~all

DKIM txt record, ttl 15 mins, hostname 1234-word._domainkey

v=DKIM1; k=rsa; p=[PUBLIC KEY]

The SPF and DKIM record are provided by the mailserver host, a billion+ dollar company (not NetSol, and the DKIM private key is handled internally by them.

REPLICATION:

To replicate, set up new SPF and DKIM records on Network Solutions, then go to mxtoolbox.com and repeatedly test for those records.

If you have a domain with existing SPF and DKIM records that have been in use for a long time, repeatedly test on mxtoolbox.com for those records. What I really want to know is the retrieval success rate for existing SPF and DKIM records, but I have no way to test this.

If you have an actual mail server at your disposal, set up the corresponding DKIM private key on it.

Send emails to a gmail account and use "Show Original" to view SPF and DKIM auth-check status for that email, or more likely you will simply get a bounce within 5 minutes.

Sending an email to [email protected] and you will instantly get an email back showing success or failure status for SPF, DKIM, and Reverse DNS.

Basically, I'm trying to establish whether this is a temporary issue, or I need to recommend they move to another registrar. They are a big company, so high failure rates such as I've been experiencing with NetSol are not going to be acceptable.

TRANSCRIPTS:

Transcript examples of successful and failed SPF and DKIM lookups using mxtoolbox.com:

SUCCESSFUL SPF LOOKUP

- - - txt:[email-domain]

 1 k.gtld-servers.net xxx.52.178.30 NON-AUTH 23 ms Received 2 Referrals , rcode=NO_ERROR  [email-domain]. 172800 IN NS ns89.worldnic.com,[email-domain]. 172800 IN NS ns90.worldnic.com,
 2 ns90.worldnic.com 162.159.27.117 AUTH 14 ms Received 1 Answers , rcode=NO_ERROR  [email-domain]. 900 IN TXT v=spf1 include:[mx-domain] ~all,
Record returned is an RFC 4408 TXT record.
MAIL FROM:
RETURN-PATH:

- - Ranges
- TXT:[mx-domain]
xxx.166.43.0/24
xxx.20.86.8
xxx.20.161.0/25
xxx.47.34.7
xxx.203.187.0/25
xxx.106.54.0/25
xxx.232.172.40

- - Subqueries
TXT:[mx-domain]

- - Results
TXT:[mx-domain] = SoftFail
TXT:[email-domain] = SoftFail
LookupServer 127ms

FAILED SPF LOOKUP

- - - txt:[email-domain]

 1 l.gtld-servers.net xxx.41.162.30 NON-AUTH 22 ms Received 2 Referrals , rcode=NO_ERROR  [email-domain]. 172800 IN NS ns89.worldnic.com,[email-domain]. 172800 IN NS ns90.worldnic.com,
 2 ns90.worldnic.com xxx.159.27.117 AUTH 91 ms Received 1 Referrals , rcode=NO_ERROR  [email-domain]. 3600 IN SOA mname=NS89.WORLDNIC.com rname=namehost.WORLDNIC.com serial=115072811,
LookupServer 147ms

SUCCESSFUL DKIM LOOKUP

- - - dkim:20220603-ywjypl4z._domainkey.[email-domain]

 1 h.gtld-servers.net xxx.54.112.30 NON-AUTH 24 ms Received 2 Referrals , rcode=NO_ERROR  [email-domain]. 172800 IN NS ns89.worldnic.com,[email-domain]. 172800 IN NS ns90.worldnic.com,
 2 ns90.worldnic.com xxx.159.27.117 AUTH 2 ms Received 1 Answers , rcode=NO_ERROR  20220603-[random-letters]._domainkey.[email-domain]. 900 IN TXT v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0bwKMEJDmRSXMb99XZkRgh3qo6rxyCkdz09Y73HArqQWYdDuD9a8L8iGuCU4PmlMNJJCKU3OJuWr0O4YxNb32NaAko1+5uzhLTye/b8HZp6WASNQFGqPdpCQPMusCDx/FZVvNmf+TNUXF7XQ+7S9dYd5OoX2nwOLuxH6z5IUP0wIDAQAB,
Record returned is an RFC 6376 TXT record.
LookupServer 26ms

FAILED DKIM LOOKUP

- - - dkim:20220603-ywjypl4z._domainkey.[email-domain]

 1 b.gtld-servers.net XXX.33.14.30 NON-AUTH 0 ms Received 2 Referrals , rcode=NO_ERROR  [email-domain]. 172800 IN NS ns89.worldnic.com,[email-domain]. 172800 IN NS ns90.worldnic.com,
 2 ns90.worldnic.com XXX.159.27.117 AUTH 86 ms Received 1 Referrals , rcode=NO_ERROR  [email-domain]. 3600 IN SOA mname=NS89.WORLDNIC.com rname=namehost.WORLDNIC.com serial=115072811,
LookupServer 86ms

SAMPLE DIG OUTPUT:

user@onyx ~ $ dig [email-domain] txt 20220603-asdf._domainkey.[email-domain]

; <<>> DiG 9.10.3-P4-Ubuntu <<>> [email-domain] txt 20220603-asdf._domainkey.[email-domain]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 893
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;[email-domain].        IN  TXT

;; ANSWER SECTION:
[email-domain]. 729 IN  TXT "v=spf1 include:emailsrvr.com ~all"

;; Query time: 108 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Jun 04 10:55:36 PDT 2022
;; MSG SIZE  rcvd: 90

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24138
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;20220603-asdf._domainkey.[email-domain]. IN A

;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Jun 04 10:55:36 PDT 2022
;; MSG SIZE  rcvd: 73



user@onyx ~ $ dig [email-domain] txt 20220603-asdf._domainkey.[email-domain]

; <<>> DiG 9.10.3-P4-Ubuntu <<>> [email-domain] txt 20220603-asdf._domainkey.[email-domain]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13290
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;[email-domain].        IN  TXT

;; AUTHORITY SECTION:
[email-domain]. 3409    IN  SOA NS89.WORLDNIC.com. namehost.WORLDNIC.com. 122060319 10800 3600 604800 3600

;; Query time: 17 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Jun 04 10:55:38 PDT 2022
;; MSG SIZE  rcvd: 103

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40465
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;20220603-asdf._domainkey.[email-domain]. IN A

;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Jun 04 10:55:38 PDT 2022
;; MSG SIZE  rcvd: 73

user@onyx ~ $
25
0 + 0
spf
anx avatar
fr flag
anx
This site is generally *much* better at providing specific diagnostics & guidance for questions about DNS that actually specify the name/record to be looked up.
3
Reply
jdmayfield avatar
cn flag
jdmayfield
Unfortunately, I am not at liberty to disclose that information, which is why I outlined the replication procedure very specifically. Most likely they cannot answer the question if they can't replicate it. Otherwise it would just be a guess.
0
Reply
anx avatar
fr flag
anx
Consider showing the (non-identical for consecutive calls, right?) *result* lists of your `dig` calls, or some of the tools that check for obvious mistakes then, [replacing](https://meta.serverfault.com/a/6063) the domain with "example.com" (start at https://dnsviz.net/ and https://zonemaster.net/).
3
Reply
joeqwerty avatar
cv flag
joeqwerty
Not your fault, but I've never quite understood the logic of "I'm not at liberty to divulge the name of a **publicly** registered domain."
3
Reply
jdmayfield avatar
cn flag
jdmayfield
@joeqwerty It's a business. I work for an MSP. I am under contract. It would require both their permission.
0
Reply
jdmayfield avatar
cn flag
jdmayfield
@anx I updated the question with the basic pattern of the SPF and DKIM records. There is no problem with the records themselves. The records are auto-generated by mail-host. They test good and pass authorization checks, including gmail-- when and if they are successfully retrieved.
0
Reply
jdmayfield avatar
cn flag
jdmayfield
@anx Also updated with transcript samples from mxtoolbox.com of both successful and failed spf/skim record lookups.
0
Reply
jdmayfield avatar
cn flag
jdmayfield
@anx Also tacked on some dig output. As you can see, I get different results with the same command. The SPF record sometimes shows, sometimes not, the DKIM record almost never shows, however this is not the case with the other 60+ domains I have similarly setup SPF and DKIM on. They always show both, 100% of the time; but none of them are hosted on Network Solutions.
0
Reply
joeqwerty avatar
cv flag
joeqwerty
In the successful queries, ns90.worldnic.com returns an answer. In the failed queries, ns90.worldnic.com appears to return a referral to ns89.worldnic.com. To me it looks like something is borked with ns90.worldnic.com on the NetSol side and is worth a call to their support.
1
Reply
joeqwerty avatar
cv flag
joeqwerty
Try querying ns90.worldnic.com directly with dig or nslookup and see what it returns on multiple, successive queries.
1
Reply
joeqwerty avatar
cv flag
joeqwerty
Also, query ns90.worldnic.com for the NS records for the domain and see if it returns itself as an NS for the domain. Then query it for any other record in the domain and see if it returns an authoritative answer.
1
Reply
jdmayfield avatar
cn flag
jdmayfield
@joeqwerty 10-4. Interesting. Thanks for the confirmation. What I thought. All the domains I admin give same results every time. But their not on netsol Never seen it like this. Out of time at the moment. Will check in later today. Thank you!
0
Reply
Score:4
joeqwerty avatar Server
cv flag
joeqwerty

Since DNS records don't propagate except within and between the authoritative name servers for a particular zone, and since you've narrowed down the problem to ns89.worldnic.com and ns90.worldnic.com, I'd suggest querying those servers directly for the records in question, and also for the NS records for the domain. Do they answer authoritatively for the domain? If so, do they return the records in question? If the answer to either or both questions is no then I'd open a support case with NetSol.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.