0

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 check-auth@verifier.port25.com 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 ~ $
jdmayfield
  • 271
  • 2
  • 11
  • 5
    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. – anx Jun 04 '22 at 16:32
  • 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. – jdmayfield Jun 04 '22 at 16:43
  • 3
    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/). – anx Jun 04 '22 at 17:04
  • 5
    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." – joeqwerty Jun 04 '22 at 17:17
  • @joeqwerty It's a business. I work for an MSP. I am under contract. It would require both their permission. – jdmayfield Jun 04 '22 at 17:21
  • @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. – jdmayfield Jun 04 '22 at 17:27
  • @anx Also updated with transcript samples from mxtoolbox.com of both successful and failed spf/skim record lookups. – jdmayfield Jun 04 '22 at 17:50
  • @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. – jdmayfield Jun 04 '22 at 18:05
  • 3
    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. – joeqwerty Jun 04 '22 at 18:07
  • 1
    Try querying ns90.worldnic.com directly with dig or nslookup and see what it returns on multiple, successive queries. – joeqwerty Jun 04 '22 at 18:11
  • 1
    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. – joeqwerty Jun 04 '22 at 18:17
  • @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! – jdmayfield Jun 04 '22 at 18:38

1 Answers1

6

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.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • 2
    Yes, polling of the Authoritave server produced "consistently" mixed results-- sometimes the SPF and/or DKIM records would show, sometimes not, but always responded. Opened a ticket with NetSol. Basically their database was corrupt. Seems they didn't know until I reported it, so not sure how extensive the issue is-- or if it's local to just this domain. Anyway, they escalated the ticket. Hopefull problem will be resolved soon, but very glad it had nothing to do with me. :) Thank you for the second opinion. Exactly what I needed in order to confidently move forward. – jdmayfield Jun 05 '22 at 20:12
  • 1
    Glad to help... – joeqwerty Jun 05 '22 at 20:42