The question edges the opinionated answer because decoupling models belonging to layers of the same application (source code) is as legit as the opposite. It boils down to a matter of trade-offs and it should be driven by real needs.
If I'm allowed to opine (and I have built and worked on these kinds of applications), I would say, don't do it early. Don't create unnecessary barriers in your code, because it increases the complexity and, in this case, the verbosity too. It also makes the maintenance expensive and tedious.
Right now, you are assuming that business DTOs will cover all UI needs, but when they don't (and they won't sooner or later), you will add a 3rd type of DTO. So, every time you add a new table or change an existing one, you have to consider 3 different models and the layers they go through.
If your design is data centric and you have built verticals around tables1 and considering what I said, I would rather keep things simple.
Given these designs makes
DAL to be the core of the application, I would consider allowing
BLL to work with the
DAL model2, and leave mappings (DTO) to the
UI layer because it's the one that usually needs it.
The view is likely to change more often than business or persistence, it's also the layer you want to be as flexible as possible but you don't want
UI needs driving your business and core. Even if you have no plan to support different views (desktop, browser, mobile, etc).
BLL might need (occasionally) custom inputs/outputs. That's fine. It's expected from the business to impose a contract and it's the outer-layers responsibility to respect it. In other words, do the mappings.
If at some point you are interested in more sophisticated layered designs, It might interest you to read about orthogonal designs and concepts like ports & adapters or dependency inversion.
1: 1 table, 1 Model, 1 repository [occasionally and 1 service]
2: business usually operates with the core, it's rare to decouple from it. I could be decoupled if the core is an absolute abstraction. I'm confident it's not the case