User-Agent

[ajorg]

Most (many?) dynamic DNS services use variations of the DynDNS v2 protocol. That protocol requires that update clients send a User-Agent header.

All clients must send a well-formed user agent that includes company name, model number, and software build revision. An example would be: Mellenium Inc. - Router 25001 - 1.1

Some services will even respond with badagent if you don't send a good User-Agent or if the client you're using is known to misbehave at a particular version.

I do see that ddupdate doesn't support Dyn, but it does support others like no-ip and google domains which use the same protocol and require a User-Agent string.

From No-IP.com, for example:

Important: Setting the Agent
When making an update it is important that your HTTP request include an HTTP User-Agent to help No-IP identify different clients that access the system. Clients that do not supply a certified and approved User-Agent risk being rate-limited or blocked from the system.

Services are probably in a bind when they see default Python or cURL User-Agent strings. Blocking them would be bad because it would prevent testing and development. Throttling is likely though. Providing a good User-Agent string lets them reach back out to the project if they see bad behavior.

The specification seems to naively assume that clients will be routers, and recommends an agent string format that doesn't conform to the convention used by other software, so I'm a bit unsure what to recommend for this client. ddclient uses the <program>/<version> format, as does inadyn, so I'm inclined to say that the spec is wrong and it's probably fine to use the conventional ddupdate/0.7.0 format.

I'm unsure of the best way to implement this. It might be best for the plugin system to provide a utility function for update requests that sets the User-Agent, but in the short term an update to plugins for services that ask for a User-Agent seems fine.

[leamas]

If you could identify any service which actually have this problem by testing this would be important. And if any service is blocking clients due to this it should of course be fixed.

However, I'm reluctant to change anything just because of documentation. Also, throttling does not really make sense in this context which leads to the question if the no-ip docs are overall applicable to this usecase at all.

The basic problem with updating plugins is testing. As long as patches have been tested, there are no problems. But to overall update a lot of plugins means lot's of testing which often needs time-consuming setups of accounts etc.

Since all plugins have been tested at one point I don't think we should change them until we have a testcase that demonstrates a problem, and that the proposed patch fixes it.

[leamas]

Ping? Should we close this?

[ajorg]

I suppose closing it makes sense, if the bar for fixing it is active throttling and not mere correctness according to protocol documentation.

…

On Fri, Apr 1, 2022, 5:52 AM leamas ***@***.***> wrote: Ping? Should we close this? — Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7TWO62QVHGVRTA25MEJDVC3WRZANCNFSM5NUNT3EA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[leamas]

OK, let's close. Thanks for heads-up!