Data Access Object(DAO) and Data Transfer Objects(DTO) are distinct J2EE design patterns.

A DAO can be thought of as a proxy used by the business tier who is its client to retrieve values from any given resource such as a RDMS, LDAP server, XML repository, OODB, flat files and so forth. The public DAO interface stays the same even if the resource implementation mechanism changes.

The DTO a.k.a. Value Transfer Object(VTO), Value Object(VO) (Martin Fowler defines VO pattern differently) is used to expose several values in a bean like fashion. This provides a light-weight mechanism to transfer values over a network or between application tiers. It's regarded as a more coarse grain object and eliminates trivial network chatter that occurs when retrieving single values one at a time.

So a DAO certainly makes use of DTOs when servicing it's clients. However, DTOs are also of value when communicating with other tiers within your application design (not just the persistence tier).

DTOs may be implemented with varying degrees of mutability. Using a constructor to pass in all the values with only getters gives essentially a read only object. The client then may map the values pursuant to its business objectives or pass it straight through to the presentation layer for final disposition.

There's no reason to be dogmatic about the mutability of DTOs; it's an application by application consideration and as long as you are aware of the issues (such as aliasing) you should be free of guilt (but perhaps not ridicule!) by allowing mutators in your VOs when useful.