Improve SPF Answer (Protocol)

[weyCC81]

Request
/api/v1/scan/gitlab.com

Reply
scanResult.error
spf:read udp 192.168.0.165:49336->8.8.8.8:53: i/o timeout; bimi:read udp 192.168.0.165:34625->8.8.8.8:53: i/o timeout

advice
spf : {We couldn't detect any active SPF record for your domain. Please visit https://dmarcguide.globalcyberalliance.org to fix this.}

Additional
Tool: https://mxtoolbox.com/SuperTool.aspx#
v=spf1 include:mail.zendesk.com include:_spf.google.com include:mktomail.com include:_spf.salesforce.com include:_spf-ip.gitlab.com a:zgateway.zuora.com include:mailgun.org -all

  | SPF Included Lookups | Too many included lookups (15) Too many DNS Lookups? Solve this problem with SPF Flattening

Workaround
--dnsProtocol tcp
Is this related to '--dnsProtocol' can the error message is different over udp or is there a reason why not fallback to tcp is initiated?

Additional Documentation Advice:

When deploy the Container on Azure Container you need to set "Command Override Array" to ["/dss", "serve", "api", "--port", "80"] or ["/dss", "serve", "api", "--port", "80","--advise"] other wise it can not be started.

[wolveix]

Hey @weyCC81, this looks to be a network issue on your end, as the error message states.

You can see that it works fine with our public instance, accessible through https://dmarcguide.globalcyberalliance.org or you can hit the API directly: https://dss.globalcyberalliance.org/api/v1/scan/gitlab.com

[weyCC81]

Hi @wolveix

Are you using just tcp on the public instance, or can udp set by default and fallback to tcp?
Anyway, the Message "We couldn't detect any active SPF record for your domain" is just parly right with udp...

[wolveix]

Hey @weyCC81, please see our public instance's configuration below. We're using TCP for it, but from testing a default installation with no configuration changes, it works just fine (using UDP).

Regarding the message, I agree that the message could be improved to be a little more specific, e.g. "We couldn't detect any active SPF record for your domain because we encountered an error". I'll make this adjustment shortly.

Edit: this adjustment isn't so simple with the current architecture, as the advisor doesn't have access to the error. I'll note it as part of the pending pull request #22.

dss-api:
  container_name: dss-api
  image: 'ghcr.io/globalcyberalliance/domain-security-scanner:latest'
  command: serve api -a --checkTLS --concurrent=20 --dnsBuffer=8192 --dnsProtocol tcp --nameservers 9.9.9.9,149.112.112.112,1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4 --prettyLog=false --timeout=20s
  ports:
    - 8081:8080
  logging:
    options:
      tag: "{{.Name}}"
  restart: unless-stopped