DynIP – Dynamic DNS ที่รองรับ RFC 2136, IPv6, DNSSEC และ BYOD

 (dynip.dev)
1 คะแนน โดย GN⁺ 22 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DynIP คือบริการ Dynamic DNS สำหรับโฮมแล็บ, เอดจ์เราเตอร์ และทีมโครงสร้างพื้นฐาน โดยมีอัปเดตทุก 60 วินาทีและแพ็กเกจฟรี
  • รองรับ RFC 2136 TSIG, REST API และการอัปเดตผ่าน UDP/53 พร้อมการผสานรวมกับ FortiGate, OPNsense, OpenWRT และ MikroTik
  • รองรับ IPv6 ควบคู่กับ IPv4 เพื่ออัปเดตระเบียน A และ AAAA แบบคู่ขนาน รองรับทั้ง dual-stack และโซนแบบ IPv6-only
  • DNSSEC ทำให้การสร้าง signing key, การเผยแพร่ไปยัง parent zone และการลงลายเซ็นระเบียนเป็นแบบอัตโนมัติ ซึ่งจำเป็นต่อการออกใบรับรอง Let’s Encrypt
  • ด้วย BYOD สามารถเชื่อมต่อโดเมนที่มีอยู่เพื่อสร้างซับโดเมนแบบไดนามิกได้ แต่ต้องมอบสิทธิ์ไปยัง ns1.dynip.dev และ ns2.dynip.dev

ภาพรวมของ DynIP

  • DynIP คือบริการ Dynamic DNS สำหรับโฮมแล็บ, เอดจ์เราเตอร์ และทีมโครงสร้างพื้นฐาน โดยชูจุดเด่นเรื่องการอัปเดตทุก 60 วินาที, แพ็กเกจฟรี, RFC 2136 TSIG, การใช้โดเมนของตัวเอง และ DNSSEC
  • ออกแบบมาให้เมื่อเราเตอร์ส่งการอัปเดต ชื่อโฮสต์จะถูก resolve ได้อย่างถูกต้องทั่วโลกภายในประมาณ 60 วินาที
  • มี TTL 60 วินาที, การกระจายแบบอิง NOTIFY และเนมเซิร์ฟเวอร์หลายรีเจียน
  • มี สมัครใช้ฟรี และ เอกสาร

มาตรฐาน DNS และการผสานรวมกับเราเตอร์

  • รองรับ RFC 2136 TSIG จึงใช้งานได้กับ FortiGate, OPNsense, OpenWRT และเราเตอร์ที่รองรับ DNS UPDATE
  • ผู้ใช้ MikroTik สามารถใช้การผสานรวม HTTP API แบบเนทีฟได้
  • วิธีที่รองรับมีทั้ง RFC 2136 TSIG, REST API และ native update ผ่าน UDP/53
  • ในหน้าส่วนแสดง configuration snippets สามารถสร้างบล็อกการตั้งค่าเพื่อคัดลอกได้จากประเภทอุปกรณ์, IP ปลายทาง, โดเมน และ TSIG key
  • ระหว่างที่โซนใหม่กำลังกระจายไปยังเนมเซิร์ฟเวอร์ การอัปเดต RFC 2136/TSIG ของ FortiGate ต้องรอก่อน
  • HTTP API updates เช่น cURL, PowerShell, Python และ MikroTik จะทำงานได้ทันที

IPv6 และ DNSSEC

  • รองรับ IPv6 ควบคู่กับ IPv4 ทำให้สามารถอัปเดตระเบียน A และ AAAA แบบขนานกันได้
  • รองรับทั้งการตั้งค่าแบบ dual-stack และโซนแบบ IPv6-only
  • หากต้องการออกใบรับรอง Let’s Encrypt จะต้องเปิดใช้ DNSSEC ในโซนนั้น
  • เมื่อเปิด DNSSEC ระบบจะสร้าง signing key, เผยแพร่ไปยัง parent zone และลงลายเซ็น DNS records ทั้งหมดโดยอัตโนมัติ
  • การตั้งค่า DNSSEC เป็นขั้นตอนครั้งเดียว และหลังจากนั้นโซนนั้นจะยังคงอยู่ในสถานะ signed ต่อไป
  • เวลาโดยประมาณที่แสดงคือ 30 วินาที

เริ่มต้นใช้งานอย่างรวดเร็วและการจัดการโซน

  • การเริ่มต้นอย่างรวดเร็วมีลำดับคือใส่ชื่ออุปกรณ์, เลือกโดเมนพื้นฐาน และคลิก Create Zone เพื่อสร้างโซน
  • จากปุ่ม Snippets ข้างโดเมนใหม่ สามารถดึงค่าตั้งค่า เลือกประเภทอุปกรณ์ แล้วคัดลอกบล็อกการตั้งค่าที่สร้างขึ้นไปยัง CLI ของเราเตอร์
  • IPv4 และ IPv6 จะถูกตรวจจับและอัปเดตอัตโนมัติตามการเชื่อมต่อขาเข้า
  • รายการโซนจะแสดงโดเมนและเครื่องมือ, IP ปัจจุบัน, TSIG Secret, DNSSEC และสถานะใบรับรอง SSL
  • ในแต่ละโซนสามารถจัดการสถานะล็อก, snippets, การลบ, การแจ้งเตือน, เวลาซิงก์, การเปิด-ปิด DNSSEC และการดาวน์โหลด-ต่ออายุ-ออกใบรับรอง SSL ได้

การใช้โดเมนของตัวเอง

  • ฟีเจอร์ Custom Namespaces(BYOD) ช่วยให้เชื่อมต่อโดเมนที่มีอยู่เข้ากับ DynIP และสร้างซับโดเมนแบบไดนามิกภายใต้ namespace นั้นได้
  • หากต้องการเปิดใช้งาน namespace ต้องสร้าง NS records ทั้งสองรายการที่ผู้รับจดทะเบียนโดเมน
  • ระบบจะปฏิเสธการมอบสิทธิ์ NS เพียงรายการเดียว
  • NS records ที่ต้องใช้คือ ns1.dynip.dev และ ns2.dynip.dev
  • การตรวจสอบการตั้งค่าจะแสดงขั้นตอนยืนยันว่าการมอบสิทธิ์เปิดใช้งานแล้ว หรือดูว่าต้องดำเนินการอะไรเพิ่มเติมที่ผู้รับจดทะเบียน

Quick Sync และระบบอัตโนมัติ

  • Quick Sync คือฟังก์ชันที่ทำให้โซนที่เลือกตรงกับ IP ภายนอกปัจจุบันของอุปกรณ์ได้ทันที
  • จะแสดง IP เครือข่ายที่ตรวจพบ และผู้ใช้สามารถอัปเดตโซนที่เลือกได้ในครั้งเดียว
  • สามารถลงทะเบียนโซนใหม่แบบโปรแกรมได้ด้วยการส่งคำขอ POST ไปยังเอ็นด์พอยต์ /register พร้อม session token
curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \
     -H "Authorization: Bearer {{ token }}"
  • session token จะหมดอายุเมื่อออกจากระบบ ดังนั้นหากต้องการทำงานอัตโนมัติระยะยาวควรใช้ API token
  • API tokens เป็นฟีเจอร์ตั้งแต่ Pro ขึ้นไป และใช้กับระบบอัตโนมัติ เช่น monitoring scripts, CI pipelines และการผสานรวมกับ MSP
  • API token จะไม่หมดอายุเมื่อออกจากระบบ และสามารถจำกัดขอบเขตเป็นแบบอ่านอย่างเดียวหรือเข้าถึงเต็มรูปแบบ รวมถึงเพิกถอนได้ทุกเมื่อ
  • API token ใหม่จะแสดงเพียงครั้งเดียวตอนสร้าง จึงควรเก็บไว้ใน password manager หรือ secret store

แพ็กเกจราคาและความปลอดภัยของบัญชี

  • หน้าราคาแพ็กเกจจะแสดง tier ของการสมัคร, สถานะ, วันต่ออายุหรือวันสิ้นสุดการเข้าถึง, รอบการชำระเงิน, จำนวนโซนที่ใช้อยู่ และจำนวนโดเมนสูงสุด
  • หากมีการดาวน์เกรดแพ็กเกจ จะคงให้ใช้งานได้เฉพาะโซนที่เก่าที่สุดตามจำนวนที่อนุญาต ส่วนโซนที่เหลือจะถูกล็อกและไม่สามารถรับการอัปเดต IP ได้
  • หากการชำระเงินล้มเหลว จำเป็นต้องอัปเดตวิธีชำระเงินเพื่อรักษาการเข้าถึงต่อไป
  • ความปลอดภัยของบัญชีรองรับ 2FA ทางอีเมลและ TOTP โดยเมื่อเปิดใช้ TOTP แล้วจะมาแทนที่ 2FA ทางอีเมล
  • การตั้งค่า TOTP ประกอบด้วยการสแกน QR code ด้วย Google Authenticator, Authy หรือแอป 2FA ที่ต้องการ แล้วตรวจสอบรหัส

ลิงก์ที่เกี่ยวข้อง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 22 시간 전
ความคิดเห็นจาก Hacker News

  • ผมคือ Daniel วิศวกรเครือข่ายจากสวีเดน และสร้าง DynIP ขึ้นมาเพราะรู้สึกว่าบริการ DDNS ที่มีอยู่ยังติดอยู่กับเครือข่ายแบบยุค 2010
    เจอปัญหาซ้ำ ๆ ทั้งโปรโตคอลอัปเดตเฉพาะทางที่รองรับแค่ HTTP, การรองรับ IPv6 ที่อ่อน, การไม่มี DNSSEC, และการรองรับอุปกรณ์สมัยใหม่ที่ไม่ดีพอ ส่วน DynIP ปฏิบัติต่อ RFC 2136 / TSIG updates เป็นเส้นทางหลักระดับ first-class
    FortiGate generic DDNS และ MikroTik /tool dns-update ทำงานได้โดยไม่ต้องมีไคลเอนต์แยก และยังมี HTTP API ให้ใช้กับกรณีอื่น ๆ ด้วย
    authoritative DNS server เข้าถึงได้ผ่าน IPv6 และมีการประกาศ AAAA glue ใน parent .dev zone ขณะที่ customer zone ออก A/AAAA ได้ และรองรับไคลเอนต์แบบ IPv6-only ด้วย
    สำหรับ zone ที่เลือกไว้ สามารถเปิด DNSSEC ได้ด้วยการสลับเพียงครั้งเดียว และสามารถนำโดเมนของตัวเองมาใช้ผ่านการ delegate subdomain ได้
    สถาปัตยกรรมเป็นแบบมี primary ที่ซ่อนไว้และไม่รับ public traffic และมี secondary 2 เครื่องที่กระจายตัวทางภูมิศาสตร์ในสวีเดนและสวิตเซอร์แลนด์ ทำการตรวจสอบ TSIG แบบ local ก่อนส่งต่อไปยัง primary
    อนุญาตให้ใช้ที่อยู่ RFC 1918 และ CGNAT ในเรกคอร์ดได้ด้วย เพื่อให้ฟลีตเซลลูลาร์บน private APN สามารถใช้ public DNS hostname ที่เสถียรเพื่อชี้ไปยัง internal IP ได้
    ยังมี Docker container ขนาดเล็กชื่อ ghcr.io/33k-org/dynip-updater ด้วย และสแตกคือ PowerDNS 4.8 authoritative, FastAPI, Postgres, Postfix, Cloudflare, Paddle โดยให้บริการอยู่ที่ dynip.dev และมี free tier ด้วย

    • ผมไม่ใช่ผู้เชี่ยวชาญด้าน DDNS แต่ desec.io ก็น่าลองดูเหมือนกัน เพราะมีฟีเจอร์คล้าย ๆ กัน
      มีความสามารถอย่าง IPv6, DNSSEC, การใช้โดเมนของตัวเอง และเป็นโปรเจ็กต์โอเพนซอร์สที่ให้บริการโฮสต์ฟรีแบบเสถียรด้วย
      อาจเป็นไปได้ว่าผมหาไม่เจอในเอกสาร แต่ฝั่งนี้รองรับ IPv6 prefix delegation ทำให้เมื่อ IPv6 prefix ที่ ISP จัดสรรให้เราเตอร์เปลี่ยนไป ก็อัปเดตเฉพาะ network prefix ของโดเมนที่ต้องการได้
      ในยุโรป prefix นี้มักไม่คงที่และจะเปลี่ยนทุกครั้งที่เชื่อมต่อกับ ISP ใหม่ ดังนั้นความสามารถในการคงส่วน host ไว้และอัปเดตอัตโนมัติเฉพาะส่วน network จึงมีประโยชน์
      ตัวอย่าง: /update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56
    • บน Firefox Focus ของ Android ถ้าไม่ปิดการป้องกันการติดตามซึ่งเป็นค่าเริ่มต้น เว็บไซต์จะใช้งานไม่ได้
      ตอนกดลิงก์ยืนยันอีเมล ก็ไม่มีทั้งข้อความว่ายืนยันเสร็จแล้วหรือการแสดงสถานะใด ๆ เลย เลยทำให้งงพอสมควร
    • ถ้ากด “change password” บนแดชบอร์ด จะมีลิงก์รีเซ็ตรหัสผ่านส่งมาทางอีเมล แต่หน้ารีเซ็ตจะแสดงได้เฉพาะใน เซสชันที่ล็อกเอาต์แล้ว เท่านั้น
      ถ้ายังล็อกอินอยู่ ลิงก์จะรีไดเร็กต์กลับไปหน้าแรกของแดชบอร์ด ดังนั้นผู้ใช้ทั่วไปที่เพิ่งกดปุ่มเปลี่ยนรหัสผ่านแล้วได้รับอีเมลทันที จะต้องล็อกเอาต์ก่อน
      ถ้าในอีเมลมีข้อความว่า “ให้ล็อกเอาต์ก่อน” หรือถ้าลิงก์สามารถจบเซสชันปัจจุบันแล้วค่อยแสดงหน้ารีเซ็ตได้ ก็น่าจะลื่นไหลกว่านี้
    • สงสัยว่าสามารถพิจารณารองรับ L402 เพื่อให้เอเจนต์ซื้อบริการได้หรือไม่
    • กังวลว่าการอนุญาตให้ใช้ที่อยู่ RFC 1918 และ CGNAT ในเรกคอร์ด อาจทำให้เกิดปัญหาความปลอดภัยแบบเอา private server ของคนอื่นมาใส่ในโดเมนตัวเองเพื่อทำ การโจมตีประเภท XSS หรือไม่
      จำได้ลาง ๆ ว่าเรื่องแบบนี้เคยถือเป็นข้อห้ามด้านความปลอดภัย

  • ตัวงานดูน่าสนใจทีเดียว แต่ตอนนี้ยังไม่มีเวลาลองใช้ทันที
    อย่างไรก็ตาม ถ้าไม่ได้มาอ่านคำอธิบายในคอมเมนต์นี้ก่อน ผมน่าจะปิดแท็บจากหน้า landing page ไปเลย
    ขอโทษที่พูดตรง ๆ แต่หน้าดูเหมือน landing page สไตล์ AI ที่ผลิตออกมาเป็นแพ็ก ทั่วไป ไม่ได้หมายความว่ามันเป็นแบบนั้นจริง ๆ แต่เมื่อคำอธิบายทำได้ดีขนาดนี้ การเพิ่มเอกลักษณ์ให้ต่างออกไปน่าจะช่วยได้
    อีกอย่างคือไม่ควรสร้างบัญชี Hacker News แยกสำหรับโปรเจ็กต์โดยเฉพาะ
    “อย่าใช้ชื่อผู้ใช้เป็นชื่อบริษัทหรือชื่อโปรเจ็กต์ มันทำให้ HN ดูเหมือนถูกใช้เพื่อการโปรโมต และดูเหมือนไม่ได้เข้าร่วมในฐานะคนจริง ๆ ไม่จำเป็นต้องใช้ชื่อจริง แต่ควรมีสัญญาณว่าคุณถูกมองเป็นมนุษย์ ไม่ใช่แบรนด์ ถ้าอยากเปลี่ยนชื่อผู้ใช้ ให้ส่งอีเมลไปที่ hn@ycombinator.com”
    https://news.ycombinator.com/item?id=22336638
    และดู https://news.ycombinator.com/showhn.html เพิ่มเติมได้ด้วย

    • เป็นข้อสังเกตที่ดี และไม่ต้องรู้สึกผิดที่พูดแบบนั้น
      ตอนนี้มันอยู่ในช่วงที่มีทั้งสิ่งที่รู้และไม่รู้ ความหวังและความฝัน รวมถึงก้อนความรู้เทคนิคที่ค่อนข้างใหญ่ ส่วนด้านดีไซน์อาจไม่ใช่จุดแข็ง แต่ในตอนนี้ผมว่าโอเคแล้ว
    • คอมเมนต์ยาว ๆ ตรงนี้เองก็ดูเหมือน ข้อความที่ LLM ผลิตแบบจำนวนมาก อย่างชัดเจน
      ตามเกณฑ์ของ Pangram คือ 100% และจริง ๆ ต่อให้ไม่มีเครื่องมือแบบนั้นก็ดูออกได้อยู่แล้ว การที่ยังมีคนจำนวนไม่น้อยแยกไม่ออกแม้แต่ในที่นี่ก็น่าหดหู่เหมือนกัน

  • ยินดีที่เห็นมีการแข่งขันเข้ามาในพื้นที่นี้
    แต่ถ้าจะโฮสต์เองโดยไม่กังวลเรื่องความเสถียรหรือความง่ายในการใช้งานมากนัก bind9 ก็รองรับ RFC 2136 DNS UPDATE และ DNSSEC
    ในชุดตั้งค่าของผม เราเตอร์ที่บ้านพูด DNS UPDATE ไม่ได้ เลยต้องเขียนไฟล์รันไทม์ Go เล็ก ๆ เองเพื่อแปลงคำขอ HTTP

    • BIND ทำอะไรได้หลายอย่างรวมถึง RFC 2136 และก่อนจะตัดสินใจเลือกสถาปัตยกรรมปัจจุบัน ผมก็ลองดูหลายทางเลือก
      ผมทำ test case ไว้บางส่วนบน FortiGate และช่วงแรก DynIP ก็เริ่มจากการคัดลอกแบบง่าย ๆ เฉพาะ FortiGate บน DNS ภายใน
      มีตัวอย่างโค้ดที่ใช้ภายในได้บนโฮสต์ Windows และ Linux หลายแบบ และถ้าใน homelab มีอุปกรณ์ IoT ก็มีตัวอย่าง Arduino ด้วย
      การทำไฟล์รันไทม์ Go ก็เป็นแนวทางที่ดี ดังนั้นคอยดูการอัปเดตใต้ /docs ได้

  • การรองรับ RFC 2136 ถือว่าให้คะแนนพิเศษได้ และทำงานร่วมกับ external-dns ได้ง่าย
    ใช้ on-premises Kubernetes กับ external-dns มาหลายปีแล้ว โดยทำงานร่วมกับเซิร์ฟเวอร์ BIND แบบ self-hosted ที่ตั้งค่าโฮสต์สาธารณะไว้แบบขั้นต่ำ

    • ชุดผสม external-dns + RFC 2136 เป็นจุดที่ดีมาก
      มีคู่มือการใช้งานแบบ fleet อยู่แล้ว และแพตเทิร์นของ Kubernetes ก็เป็นการต่อยอดที่เป็นธรรมชาติ เลยคิดว่าน่าจะต้องเขียนไกด์

  • เมื่อก่อนเคยทำสคริปต์ OpenWrt DDNS เองเพื่ออัปเดต AWS Route 53 หรือ Cloudflare DNS และแค่นั้นก็เพียงพอสำหรับการใช้งาน
    หลังจาก Tailscale ออกมา ก็เลิกต้องกังวลเรื่อง DDNS หรือ CGNAT อีกต่อไป

    • Tailscale, Netbird, WireGuard ล้วนยอดเยี่ยม และตอนนี้เป็นยุคที่ดีมากเพราะมีเครื่องมือแบบนี้
      มีเขียนไกด์ไว้ที่ https://dynip.dev/guides/tailscale อธิบายว่าพวกมันอยู่ร่วมกันได้อย่างไร และทำไมถึงอยู่ร่วมกันได้
      สคริปต์ OpenWrt DDNS จะยุ่งยากนิดหน่อยเพราะเรื่องคีย์กับซีเคร็ต แต่ฟีเจอร์ snippet ช่วยให้ไม่ต้องเดาแล้วว่า “มันทำงานยังไง?” เลยค่อนข้างพอใจ
    • ตอนนี้ใช้ทั้งสองอย่าง
      ใช้ DynIP กับบริการที่เปิดสาธารณะ และใช้ Tailscale กับสิ่งที่มีแค่ผมเท่านั้นที่ต้องเข้าถึง เลยลดพื้นผิวการโจมตีลงไปได้มาก
      โชคดีที่ไม่ต้องสนใจ CGNAT

  • ลองสมัครแล้วแต่ อีเมลยืนยัน ไม่มาถึง
    หลังสมัครทันที ใน log ของเมลเซิร์ฟเวอร์ก็ไม่มีร่องรอยอะไรคล้ายกัน และแม้จะกดขอส่งใหม่หลายครั้งแล้ว ผ่านไป 6–7 ชั่วโมงก็ยังไม่มีอะไรในกล่องจดหมาย

    • ได้ trigger การส่งใหม่สำหรับอีเมลที่ยังไม่ได้ยืนยันทั้งหมดแล้ว ดังนั้นอาจมี verification token ใหม่ถูกสร้างขึ้น
    • ถ้าบอกที่อยู่อีเมลมา จะลองตรวจสอบให้

  • อยากรู้ว่าโทเค็นยืนยันของ free tier หมดอายุหลัง 24 ชั่วโมงจริงไหม
    เห็น exp claim ของ JWT แล้ว และอยากรู้จุดนี้ก่อนจะลงเวลาไปกับการย้ายระบบ
    ประเด็นสำคัญคือ free tier ใช้งานได้ยั่งยืนหรือไม่

    • “long-lived token” หมายถึง โทเค็น API สำหรับการจัดการ ที่ใช้สร้าง ลบ หรือดู zone รวมถึงงานอัตโนมัติแบบ Terraform ไม่ใช่ TSIG key สำหรับอัปเดต DNS จริง
      ทุก zone จะได้รับ TSIG key ของตัวเองในทุก tier และคีย์นั้นเป็นผู้จัดการการอัปเดตจริง
      free tier จัดการ zone ผ่านแดชบอร์ด ส่วน paid tier จะเพิ่ม API token สำหรับการจัดการแบบโปรแกรมได้
      ดังนั้น auth token ใช้เป็น bearer สำหรับ API ส่วน TSIG จะยังใช้ได้ต่อไปตราบใดที่โดเมนยังไม่ถูกลบ
      free tier อนุญาต 5 zone และแต่ละ zone มี TSIG key แยกที่เปิดใช้งานตลอด ดังนั้นถ้าไม่ได้สร้าง อัปเดต ลบ zone หลายร้อยรายการ ก็ไม่จำเป็นต้องจ่ายเงิน

  • ขอบคุณสำหรับคอมเมนต์และคำถามดี ๆ มากมาย อีกไม่กี่ชั่วโมงจะกลับมาดูเธรดต่อหลังจากพาลูกสาวไปเรียนว่ายน้ำ

    • ว่ายน้ำก็ดี และ พลศาสตร์ของไหล ก็สำคัญ
      อยากรู้ว่าเคยพิจารณาอะไรอย่าง https://github.com/hickory-dns/hickory-dns บ้างไหม
      แน่นอนว่าไม่จำเป็นต้องทำทุกอย่างด้วย Rust

  • ดูน่าสนใจ และผมใช้ DDNS เพื่อให้บริการหลายอย่างจากโฮมเซิร์ฟเวอร์แก่ไคลเอนต์ภายนอก
    ตอนนี้ใช้ NO-IP DDNS อยู่ ซึ่ง free tier ค่อนข้างใจกว้าง แต่ไม่พอใจตรงที่ไม่รองรับสิ่งอย่าง Let’s Encrypt
    กำลังคิดจะซื้อโดเมนบน Cloudflare เลยอยากรู้ว่า DynIP ต่างออกไปอย่างไรโดยเฉพาะ

    • ถ้าตอนนี้สิ่งที่ไม่พอใจใน NO-IP คือใช้ Let’s Encrypt ไม่ได้ ก็เท่ากับว่าคุณเจอฟีเจอร์ที่สร้างความแตกต่างสำหรับตัวเองแล้ว

  • การอัปเดตแบบ HTTP(S) เท่านั้น สไตล์ยุค 2000 ก็ดีเหมือนกัน
    ขอแค่มี curl/wget/fetch ก็ใช้ได้จากทุกที่ และถ้าต้องการก็แค่เพิ่มโทเค็น
    ดูเหมือน duckdns ก็ยังรองรับวิธีนี้อยู่ และไม่ต้องมีไคลเอนต์แยก เลยใช้งานได้แทบทุกที่

    • แนว curl/wget/fetch แบบ dyndns ก็ถูกต้องเหมือนกัน และดูฟีเจอร์พิเศษอื่น ๆ ที่ทำได้เพิ่มเติมใน /docs ได้
      ที่นี่ไม่ได้พยายามรวมแค่ curl/wget/fetch เท่านั้น แต่กำลังพยายามครอบคลุมฐานความสามารถที่กว้างกว่านั้น