Here's a more psychology-focused answer.
Agile decreases certainty to increase delivery speed of features. This trade-off means that you will never be 100% certain about what is required to develop a specific feature. (If you were 100% certain, it would be waterfall!) This necessarily means that estimates are less precise and more likely to be incorrect.
A developer who is used to waterfall and/or having their estimates used as hard deadlines, will feel intrinsically uncomfortable with such imprecise estimates because in their past experience, that leads to work not delivered on time, which directly translates into working overtime to get things done and/or unhappy managers. Even if that developer is now working in an agile manner, where they know that points are not equal to time, the bad experiences they've had in the past as a result of imprecise estimates are likely to translate into anxiety (often subconscious) around not estimating accurately.
Essentially then, the concern your developers are expressing around not having enough information to estimate accurately, could simply be them attempting to rationalise this anxiety that they may not even realise they have. As such, discussing this possibility with them could be a good way for them to potentially understand more about themselves, and lead them to be less anxious about estimation going forward.
Regarding not knowing enough about a task to estimate it accurately, this could indicate that said task is too complex and should be broken down further. But this could tie into trust; many developers are unwilling to estimate on something they themselves haven't investigated because they don't trust that the developer who did the investigation, did a good job of it. This is especially true if the investigating developer is more junior, or has a track record of not investigating thoroughly enough.
In the former case, the developers complaining about lack of knowledge should be expected to have more knowledge than the junior, and thus be able to assist the junior in estimating. Over time, as the junior gains more experience with the system and becomes less junior, their estimates will intrinsically improve. If they don't, the team needs to have a discussion with the junior to address this (escalating to management if the situation doesn't improve).
It becomes more complex when some developers don't trust another to investigate adequately. This almost always points to an issue with the developer in question; people don't build up reputations overnight. Again, this is a situation where the team as a whole needs to sit down and have a frank discussion about how this developer's lack of due diligence is affecting the team's performance and morale. This is unlikely to be an easy discussion to have, but sometimes the issue really is that the developer who is a problem doesn't know it, and merely being informed of it will prompt them to improve. If not, and/or if that developer is hostile to the notion, it is time to get management involved, and sometimes the simplest and easiest solution is simply to get rid of the bad apple because of the negative influence they're having on the team as a whole. Trust is so incredibly important in building a well-functioning dev team, and it's almost impossible to foster that trust when everybody knows there's a problem child they have to deal with.
Obviously, if a developer doesn't understand a particular task well enough, they're going to feel that there's little point in trying to estimate it. If there are many tasks where this is true, that developer is likely to feel they're not making a valuable contribution to the estimation session and/or that their time is being wasted. This can be particularly true of juniors, who know almost nothing about the system.
The thing is, it's simply not feasible to have everyone clued up on every part of the system, no matter what development methodology you use. Especially on larger systems and teams, different people are going to know more or less about different areas of that system - even the most senior developers will only know that certain sections of the system exist.
This by itself is not a problem, it's reality. What is a problem is when developers start being assigned, or choosing to work on, tasks that deal with working on parts of the system that are familiar to said developer. Then you start getting into a situation where knowledge is siloed, and that's a bad place to be.
This might not even be happening intentionally, because people naturally gravitate towards things that they know, and avoid unknowns. There are other factors that might cause developers to choose what they know: previously being in a stressful environment where output was valued over consistency (so getting work done fast was important, and you always work faster on something you know); or merely being one of those people who thinks that having more points completed in a sprint makes them a better developer than the rest of the team. (You should be wary of the latter kind; they often turn out to be poor team players.)
You need to be watchful to ensure that such silo-ing doesn't take place. If you do see it happening, all you can really is encourage the developers in question to work on other things, or to pair with their peers who may be less familiar with that part of the system. Trying to prevent it by manually assigning tasks to certain developers is unlikely to go down well, and is very un-agile, but may unfortunately be necessary in situations where the softer approach hasn't worked. Obviously though, avoid putting juniors on difficult system-critical work, and avoid putting seniors on basic stuff that is going to bore them to tears.
Ultimately, it feels like your team doesn't understand the democratic nature of agile. While it might appear more efficient to let people who know the work be the ones to estimate it, it prevents other members of the team - particularly the ones less familiar with that area of the system - from asking questions and gaining system knowledge from their peers. I've been in many planning sessions where a seemingly innocuous question from a very junior member has caused a big "oh c**p" moment amongst the most senior members, simply because the junior's lack of understanding highlighted something major that had been missed. Even better, because a junior often doesn't have the "indoctrination" into the way of thinking about the system that seniors have, they can often bring entirely fresh and valuable perspectives into how to tackle a section of that system that the team thinks they know.
Which dovetails nicely into the retrospective. A retro can and should share knowledge, but about the sprint, not the system under development. It's perfectly okay for a developer in retro to say "I discovered X about section Y of the system while working on the task, which made the estimate junk, but next time we'll all know so we can estimate correctly"; it's not okay for said developer to then follow on with a technical discussion of what they discovered. That sort of information should instead be conveyed by developer team meetings that exist especially for that purpose.
And perhaps that's what your team is missing. It's perfectly okay for the whole dev team to take an hour or two every sprint, sit down together, and simply discuss the system as they know it. Such a knowledge-sharing session is a valuable opportunity for juniors to learn so that they feel able to estimate more accurately, while also being a good way to prevent silo effects among seniors, and would likely solve the issue around uncertain estimates due to not enough knowledge. It doesn't have to happen every sprint, or involve all the developers; it can happen whenever someone has completed a big rework of an old subsystem, or added a new one, or upon a new team member joining. If the team really is agile, they decide as and when it's needed.
Developers generally have a very visceral (and understandable) reaction to the word "meeting", which is why I've been very careful to avoid it until now, but in a truly agile working environment (and I'd argue, any functional working environment) they should understand that knowledge-sharing is vital and part of their jobs, and a team meeting really can't be beat for accomplishing that. If they can get value out of it, that can also help to make them more motivated for the standard ceremony-type meetings like planning, estimation and retro.
