Hi Michael, Thank you for the historical context on HTTP vs port 53, that’s exactly why the protocol went this route. NAT traversal and avoiding the hijacking issues that plagued port 53 were key considerations.
The DoH angle is interesting. RFC 3007 over HTTPS with proper authorization could be a cleaner long-term approach, though it would require more complexity on the client side It's very interesting. The current HTTP-based design prioritizes simplicity for embedded devices and existing DDNS client ecosystems. I’ll proceed with reaching out to implementers.benefit from a standardized protocol If you have suggestions on other implementers or communities worth engaging, I’d welcome the input. Thank you also for the time you dedicate to my perhaps sometimes generic questions. Best regards, Andrea Ferro > >>> On 19 Jan 2026, at 19:11, Michael Richardson <[email protected]> wrote: >>> >>> >>> Andrea Ferro <[email protected]> wrote: >>> You raise a fair point about working group fit. The protocol is indeed >>> HTTP-based rather than modifying DNS wire format, so I understand DNSOP >>> may not be the natural home. >> >> I think that the major reason HTTP was used is that it was "simple" to >> implement. It gets through NAT44, and does not get hijacked as has occured >> in the past to port-53 :-( >> >> OTH, we now have DoH, and so we could well put DNS wire protocol style (3007) >> updates over HTTPS with the right authorizations. >> >>> Med (as DNSOP Area Director) has clarified that DNSOP serves as DNS >>> dispatch for the IETF, and suggested I continue the discussion here. >> >> Yes, that's fair enough. >> >>> I’d welcome any guidance on the right path forward. Would this be >>> better suited for an existing WG, or would forming a new tightly-scoped >>> group be the recommended approach? If the latter, what would be the >>> typical first steps? >> >> I'd say that the first step is: >> >>> I’m also happy to reach out to other providers and client implementers >>> to gauge interest in collaborating on this. >> >> without implementers, there is no useful specification :-)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
