First thing I'd like to say is that I'm not particularly impressed/ convinced by this kind of "who owns what" arguments. As far as I'm concerned, the end product is what matters. Everybody involved in the design and development process should be "owning" the product. Everybody should be taking part somehow into the discussion of how best to deliver the awesome product that users will fall in love.
But anyway, I understand where the arguments are coming from. And it is sometimes a politically necessary thing to do (think Jira or other issue tracking systems).
The first factor to take into account is what is YOUR COMPANY's own definition of the departments, i.e. what are the responsibilities of UX and Dev departments respectively? Is there a formal agreement or something like that which exists?
The second factor is about YOUR TEAM. How willing are you guys to own it? Do you feel like it's something UX guys should be doing?
The third factor is the CONTEXT of this issue concerning the zoom function. Is it a complicated feature/fix that requires elaboration, wireframe, visual design? Was it already defined anywhere anytime before? Or it's just a really simple development detail or bug?
On the other hand, generally speaking, the role of UX is to bridge the gap between users and the system. We are often considered the user advocate, trying to fight against implementation-centric or system-oriented models (which are real bad for users).
The obvious question now is that is it OK for you to let the Dev team solve the issue without consulting you? What if they come up with a implementation-centric solution that looks and works just really bad from a UX point-of-view?
I guess not. In my opinion, UX department would need to have a say anyway in how you would like to design to be fixed. And it's best to do it before the Dev department tries to tackle the problem, usually with their technical know-how and sometimes ignores how it would turn out for users.
In your case, the Dev is asking for wireframes, so it looks like the issue might be something they can't resolve (or so they think) without your input.
So in general, I think UX should "own" it. Having a hand on the problem first, explore it (no matter how fast it can be), then discuss with the Devs to work out a solution.