[DNSOP] Re: Introducing draft-ferro-dnsop-apertodns-protocol-00.txt

[Michael Richardson <[e-mail]>]

Andrea Ferro <[e-mail]> wrote:
    > What is my goal? I want to establish a modern, open standard for
    > dynamic DNS updates that can eventually replace the current fragmented
    > landscape. You described the problem perfectly "devices hand-picking
    > from proprietary provider lists, each with their own protocols". The
    > current de facto "standard" is dyndns2, which Dyn documented on their
    > website but never published as a vendor-neutral specification. There's
    > no RFC, just one company's API that others adopted by imitation. This
    > space hasn't seen meaningful evolution in 15 to 25 years, and I believe
    > it deserves a proper, open standard.

Yes, it would be nice to have a better dynamic update mechanism.
One that is happier with SIG(0) than with TSIG.  That bridges the gap between
some-random-stuff-over HTTP and RFC3007.

Which could also use other authentications, including leveraging TLS and
EAP-mechanisms over/inside TLS, probably including GSSAPI.

    > Why am I doing this? Honestly, because I believe connectivity should be
    > accessible to everyone. My guiding principle with ApertoDNS has been
    > "No Walls": no paywalls, no artificial restrictions. I'm not looking
    > for commercial gain. I want to contribute something useful that
    > outlasts any single project or company.

I don't know if you are NAT44 focused or IPv6-happy.
I have very poor experiences with dual-stack hosts, and if doing v4, then one
might need SVCB/HTTPS RR support, with port numbers.  Which the end-host
might not exactly know.

While I appreciate your desire to not do this for "commercial gain", running
DNS infrastructure costs money.  Particularly for people who insist they
can't do IPv6, and really want to live in a triple-NAT44'ed docker container on a Win7
desktop... needing extensive hand-holding, costs money. (Someone has to pay my therapist)

The point is there while you don't want to make money, I don't want to lose
money, so please think about what commercial relationships need to exist in
order to facilitate this process.  Mostly this means errors around expired
accounts, ways to sign up that are both sane and secure, and account limit notifications.

    > Which path makes sense? This is where I'd genuinely appreciate your
    > guidance. Since my goal is maximum adoption, becoming the standard that
    > vendors actually implement,, it sounds like working group adoption
    > might be the stronger path. I'm open to that, but I'll admit I'm
    > uncertain how the process works in practice. If a WG adopts the draft,
    > what typically happens? Do authors remain involved as editors? What
    > kinds of changes are common?

1. The alternative to WG adoption are: AD sponsorship or Independent
   Sumission Editor.  Generally, both are going to ask the WG when they
   deconflict, and I think that this belongs in the WG.
2. Technically, who are the editors is up to the WG chairs.
   It's very rare that document proponents are replaced as editors, but it
   does happen.  The whole NoteWell Process started back in ~1997 when a
   document proponent refused to apply WG consensus, and then asserted
   copyright over the document, and that WG had to do something else.
   (The result was inferior.  The author was, IMHO, right)

    > I raised this in dnsop because I wasn't sure where else to start. You
    > mentioned dnssd might be more natural. I'm happy to take it there if
    > that's more appropriate. Or if you think ISE is actually the better fit
    > for what I'm describing, I'm open to that perspective too.
    > I appreciate any guidance you can offer.

DNS-SD is not the right place.
A proposed SETTLE WG, were it already mature, might be better, but it's still
not even a BOF.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [