Bottom line: Review the IPv4 and IPv6 update paths as two explicit jobs. Record the expected A and AAAA values and verify each against its own checking method and interface.
\nThe OPNsense Dynamic DNS reference requires one account using an IPv4 checking service and another using an IPv6 checking service to update both an A and an AAAA record. The same note requires Allow IPv6 on the General Settings tab. Check ip method selects the service used to obtain the appliance address. Interface to monitor selects the interface used to connect to that checking service, or the interface from which to collect an address when the method is Interface.
\nThis article addresses the documented dual-record update configuration, not a guarantee of global DNS propagation or application reachability. It does not choose a provider credential scope or qualify every Dynamic DNS backend.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a two-row update worksheet, one row for IPv4 and one for IPv6. Put the account, hostname, checking method, monitored interface and intended record value in each row. Keep a provider credential reference without copying the secret into the worksheet.
\nReview what the interface field means for the selected checking method. For an external checking service, name the connection the request should use. For the Interface method, identify the exact local interface whose address is intended. Do not approve the entry from a familiar interface label without comparing its active address and purpose.
\nUse an approved test hostname for the first dual-stack trial. Ask the DNS owner to confirm that both record types belong in the intended zone and that the expected values are suitable for the service. Treat an existing stale record as a separate observation rather than silently deleting it during account setup.
\nPlan a controlled address-change rehearsal only where the network owner permits it. Keep the original account definitions and DNS values available for restoration. Agree how to handle a missing IPv6 path without publishing a guessed address or weakening a separate application access rule.
\nProposed verification: inspect both accounts and the global IPv6 option against the worksheet. Observe the actual address obtained by each configured method, then query the intended DNS name for A and AAAA separately. Record the observation times and returned values so the reviewer can distinguish record state from the update attempt.
\nIn an approved change rehearsal, compare each later update with its intended new value. Include the case where only one address family changes and inspect the other record independently. Check the application path through each intended family as a separate acceptance task; an updated record should not close an unperformed connectivity test.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Review the IPv4 and IPv6 update paths as two explicit jobs. Record the expected A and AAAA values and verify each against its own checking method and interface.\nSource fact: what the authority says\nThe OPNsense Dynamic DNS reference requires one account using an IPv4 checking service and another using an IPv6 checking service to update both an A and an AAAA record. The same note requires Allow IPv6 on the General Settings tab. Check ip method selects the service used to obtain the appliance address. Interface to monitor selects the interface used to connect to that checking service, or the interface from which to collect an address when the method is Interface.\nWhat the source does not establish\nThis article addresses the documented dual-record update configuration, not a guarantee of global DNS propagation or application reachability. It does not choose a provider credential scope or qualify every Dynamic DNS backend.\nApplicability questions\n\nWhich fully qualified name and address-family records are intended?\nWhat address should each checking method observe on the selected connection?\nIs an interface address or an external checking service the approved source of truth?\nWho can compare the published A and AAAA values with the network inventory?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a two-row update worksheet, one row for IPv4 and one for IPv6. Put the account, hostname, checking method, monitored interface and intended record value in each row. Keep a provider credential reference without copying the secret into the worksheet.\nReview what the interface field means for the selected checking method. For an external checking service, name the connection the request should use. For the Interface method, identify the exact local interface whose address is intended. Do not approve the entry from a familiar interface label without comparing its active address and purpose.\nUse an approved test hostname for the first dual-stack trial. Ask the DNS owner to confirm that both record types belong in the intended zone and that the expected values are suitable for the service. Treat an existing stale record as a separate observation rather than silently deleting it during account setup.\nPlan a controlled address-change rehearsal only where the network owner permits it. Keep the original account definitions and DNS values available for restoration. Agree how to handle a missing IPv6 path without publishing a guessed address or weakening a separate application access rule.\nVerification and evidence\nProposed verification: inspect both accounts and the global IPv6 option against the worksheet. Observe the actual address obtained by each configured method, then query the intended DNS name for A and AAAA separately. Record the observation times and returned values so the reviewer can distinguish record state from the update attempt.\nIn an approved change rehearsal, compare each later update with its intended new value. Include the case where only one address family changes and inspect the other record independently. Check the application path through each intended family as a separate acceptance task; an updated record should not close an unperformed connectivity test.\nOfficial references\n\nOPNsense — Dynamic DNS — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Review the IPv4 and IPv6 update paths as two explicit jobs. Record the expected A and AAAA values and verify each against its own checking method and interface.\n\n## Source fact: what the authority says\n\nThe [OPNsense Dynamic DNS reference](https://docs.opnsense.org/manual/dynamic_dns.html) requires one account using an IPv4 checking service and another using an IPv6 checking service to update both an A and an AAAA record. The same note requires Allow IPv6 on the General Settings tab. Check ip method selects the service used to obtain the appliance address. Interface to monitor selects the interface used to connect to that checking service, or the interface from which to collect an address when the method is Interface.\n\n## What the source does not establish\n\nThis article addresses the documented dual-record update configuration, not a guarantee of global DNS propagation or application reachability. It does not choose a provider credential scope or qualify every Dynamic DNS backend.\n\n## Applicability questions\n\n- Which fully qualified name and address-family records are intended?\n\n- What address should each checking method observe on the selected connection?\n\n- Is an interface address or an external checking service the approved source of truth?\n\n- Who can compare the published A and AAAA values with the network inventory?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a two-row update worksheet, one row for IPv4 and one for IPv6. Put the account, hostname, checking method, monitored interface and intended record value in each row. Keep a provider credential reference without copying the secret into the worksheet.\n\nReview what the interface field means for the selected checking method. For an external checking service, name the connection the request should use. For the Interface method, identify the exact local interface whose address is intended. Do not approve the entry from a familiar interface label without comparing its active address and purpose.\n\nUse an approved test hostname for the first dual-stack trial. Ask the DNS owner to confirm that both record types belong in the intended zone and that the expected values are suitable for the service. Treat an existing stale record as a separate observation rather than silently deleting it during account setup.\n\nPlan a controlled address-change rehearsal only where the network owner permits it. Keep the original account definitions and DNS values available for restoration. Agree how to handle a missing IPv6 path without publishing a guessed address or weakening a separate application access rule.\n\n## Verification and evidence\n\nProposed verification: inspect both accounts and the global IPv6 option against the worksheet. Observe the actual address obtained by each configured method, then query the intended DNS name for A and AAAA separately. Record the observation times and returned values so the reviewer can distinguish record state from the update attempt.\n\nIn an approved change rehearsal, compare each later update with its intended new value. Include the case where only one address family changes and inspect the other record independently. Check the application path through each intended family as a separate acceptance task; an updated record should not close an unperformed connectivity test.\n\n## Official references\n\n- [OPNsense — Dynamic DNS](https://docs.opnsense.org/manual/dynamic_dns.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/", "url": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Review OPNsense IPv4 and IPv6 DDNS updates separately", "item": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/#article", "identifier": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/", "url": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/", "headline": "Review OPNsense IPv4 and IPv6 DDNS updates separately", "description": "Use separate address-family accounts and verify both published records rather than treating one successful dynamic DNS update as a dual-stack result.", "abstract": "Use separate address-family accounts and verify both published records rather than treating one successful dynamic DNS update as a dual-stack result.", "articleBody": "Bottom line: Review the IPv4 and IPv6 update paths as two explicit jobs. Record the expected A and AAAA values and verify each against its own checking method and interface.\nSource fact: what the authority says\nThe OPNsense Dynamic DNS reference requires one account using an IPv4 checking service and another using an IPv6 checking service to update both an A and an AAAA record. The same note requires Allow IPv6 on the General Settings tab. Check ip method selects the service used to obtain the appliance address. Interface to monitor selects the interface used to connect to that checking service, or the interface from which to collect an address when the method is Interface.\nWhat the source does not establish\nThis article addresses the documented dual-record update configuration, not a guarantee of global DNS propagation or application reachability. It does not choose a provider credential scope or qualify every Dynamic DNS backend.\nApplicability questions\n\nWhich fully qualified name and address-family records are intended?\nWhat address should each checking method observe on the selected connection?\nIs an interface address or an external checking service the approved source of truth?\nWho can compare the published A and AAAA values with the network inventory?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a two-row update worksheet, one row for IPv4 and one for IPv6. Put the account, hostname, checking method, monitored interface and intended record value in each row. Keep a provider credential reference without copying the secret into the worksheet.\nReview what the interface field means for the selected checking method. For an external checking service, name the connection the request should use. For the Interface method, identify the exact local interface whose address is intended. Do not approve the entry from a familiar interface label without comparing its active address and purpose.\nUse an approved test hostname for the first dual-stack trial. Ask the DNS owner to confirm that both record types belong in the intended zone and that the expected values are suitable for the service. Treat an existing stale record as a separate observation rather than silently deleting it during account setup.\nPlan a controlled address-change rehearsal only where the network owner permits it. Keep the original account definitions and DNS values available for restoration. Agree how to handle a missing IPv6 path without publishing a guessed address or weakening a separate application access rule.\nVerification and evidence\nProposed verification: inspect both accounts and the global IPv6 option against the worksheet. Observe the actual address obtained by each configured method, then query the intended DNS name for A and AAAA separately. Record the observation times and returned values so the reviewer can distinguish record state from the update attempt.\nIn an approved change rehearsal, compare each later update with its intended new value. Include the case where only one address family changes and inspect the other record independently. Check the application path through each intended family as a separate acceptance task; an updated record should not close an unperformed connectivity test.\nOfficial references\n\nOPNsense — Dynamic DNS — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T20:33:11+00:00", "dateModified": "2026-10-29T20:33:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-opnsense-ipv4-and-ipv6-ddns-updates-separately/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review OPNsense IPv4 and IPv6 DDNS updates separately" }, "articleSection": [ "Networks & Infrastructure" ], "keywords": [ "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 542, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Dynamic DNS", "url": "https://docs.opnsense.org/manual/dynamic_dns.html" } } ] } }