文章

发布于

Quick note: 國内遞歸 DNS 支持 DNSSEC 了嗎？Nope。

~# dig @119.29.29.29 www.dnssec-failed.org. A

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @119.29.29.29 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10361
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 400176fcef655802 (echoed)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; ANSWER SECTION:
www.dnssec-failed.org.  3600    IN      A       68.87.109.242
www.dnssec-failed.org.  3600    IN      A       69.252.193.191

~# dig @8.8.8.8 www.dnssec-failed.org. A

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @8.8.8.8 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16567
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

説明：如果 www.dnssec-failed.org 能夠返回 A 記錄，則代表遞歸 DNS 沒有對 DNSSEC 簽名進行檢驗。
其他還測試了 114.114.114.114，以及 223.5.5.5，均不支持 DNSSEC 校驗。雖然 DNSPod 支持了 DNSSEC 功能，但在國内依然是沒有什麽用處。

发布于

The importance of setting up a strong DMARC

Email spoofers are trying to up their game. By spending efforts to set up a domain for header_from SPF spoofing.

The technique involves configuring a valid SPF record for the envelope_from domain while using a spoofed domain in the header_from field, hoping that the email server does not perform thorough checks. So far domains like club-sphere-web.com, ar-realestate.com, chainyuu.com are observed for such activities.

To protect your domains, make sure to deploy strong DMARC policies (p=reject). SPF record alone is not designed to check SPF alignments between header_from and envelope_from.
Check your email: https://checkcybersecurity.service.ncsc.gov.uk/email-security-check/form

And possibly the best article to educate yourself on SPF, DKIM, DMARC – https://simonandrews.ca/articles/how-to-set-up-spf-dkim-dmarc (The only thing I disagree would be the use of -all instead of ~all, see Mailhardener’s reasoning on this – https://www.mailhardener.com/kb/spf#fail-vs-soft-fail)

<record>
	<row>
		<source_ip>156.242.10.176</source_ip>
		<count>1</count>
		<policy_evaluated>
			<disposition>reject</disposition>
			<dkim>fail</dkim>
			<spf>fail</spf>
			<reason>
				<type/>
				<comment/>
			</reason>
		</policy_evaluated>
	</row>
	<identifiers>
		<envelope_to>ezweb.ne.jp</envelope_to>
		<envelope_from>chainyuu.com</envelope_from>
		<header_from>[domains they do not control]</header_from>
	</identifiers>
	<auth_results>
		<dkim>
			<domain/>
			<selector/>
			<result>none</result>
			<human_result>no signature data</human_result>
		</dkim>
		<spf>
			<domain>chainyuu.com</domain>
			<scope>mfrom</scope>
			<result>pass</result>
		</spf>
	</auth_results>
</record>
发布于

I alwasys had fail2ban rules configured on my host server, came across this service today which provides bad acting IPs caught by honeypots and can be fed into fail2ban directly. This is some great stuff.

https://apiban.org/2024.html

发布于

Haven’t visited NameSilo in a while, ever since I transferred all my domains out following their last .com price hike. Somehow, they’ve managed to increase the price again to a staggering $17.29.

Yes, I know they have a discount program where you can deposit a minimum of $50 for a .com renewal price of $11.05, but it’s still absurd that not making a deposit results in a difference of over $6.

发布于

Weird issue for Let’s Encrypt DNS-01 resolution cache

Recently I find that my acme.sh automatic renewals had been failing over the past monthh, so I manually ran the cron job to find out what is going wrong.

By default, acme.sh waits 20 seconds after setting TXT records on DNS, then do a confirmation using CloudFlare DNS before contacting LE for challenge. However, the process was failing during the verification step with the following error:

original='{
"identifier": {
"type": "dns",
"value": "[redacted-domain]"
},
"status": "invalid",
"expires": "2024-11-27T16:02:48Z",
"challenges": [
{
"type": "dns-01",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/[redacted]/LL1-zA",
"status": "invalid",
"validated": "2024-11-20T16:03:17Z",
"error": {
"type": "urn:ietf:params:acme:error:dns",
"detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.[redacted-domain] - check that a DNS record exists for this domain",
"status": 400
},
"token": "[redacted]"
}

To diagnose the problem, I manually confirmed that:

1) _acme-challenge was added to the right place,
2) both Cloudflare and Google DNS confirmed the existence of _acme-challenge.[redacted-domain],
3) I later try to renew each domain individually, and they can succeed with additional retries.

Observation 3) gives me an idea to allow more time for Let’s Encrypt’s DNS server to properly fetch my DNS records, so I set acme.sh DNS sleep time to 60s. With that, this issue did not reoccur, and all renewal operations completed successfully.

As my domain usually renews every 2 month, judging from my last issued date, it seems this issue began sometime after October, as the cron job runs daily but does not attempt renewal unless the certificate is within one month of expiration.

Disclaimer: While I understand that there is the possibility of my Anycast DNS failing to propagate the server closest to Let’s Encrypt’s DNS server, test results from DNS propagation site shows that my Anycast DNS updated the record instantly, let alone with a 20 second delays. As such, I do not find evidence on this being an issue on my DNS side, yet.

References:
https://community.letsencrypt.org/t/dns01-validation-timeouts/116844/2

发布于

隨記 AMH php-7.4 編譯版在 Ubuntu 22 下的 OpenSSL 動態庫問題

Error: PHP 無法進行 ssl:// 的 fsocketopen，但 PHP 編譯版帶有 –with-openssl

/usr/local/php-7.4/bin# ./php -i | grep ssl
Openssl default config => /usr/local/openssl-1.1.1w/openssl.cnf

/usr/local/openssl-1.1.1w/bin# ./openssl version -a
./openssl: symbol lookup error: ./openssl: undefined symbol: EVP_mdc2, version OPENSSL_1_1_0

References:

https://github.com/openssl/openssl/issues/11227
https://blog.csdn.net/hhd1988/article/details/125563134

使用 echo “/usr/local/openssl-1.1.1w/lib” >> /etc/ld.so.conf.d/libc.conf && ldconfig 後，./openssl version -a 可以跑了，但 PHP 的 fsocketopen 依然不行，不確定何以繼續 debug，暫且改用非 SSL 端口並優先考慮環境升級。

想法來説估計把 AMH 的安裝脚本 –with-openssl 改成 3.0.2（系統版本）是最簡單的。