If Service Layer is doing nothing, just calling methods in DAO. Can my Service Interface just extend DAO Interfaces?
No.
You don't have a service layer for the sake of having a service layer. It's a layer that further hides your data source and how that's implemented and also adds coordination logic for the DAOs (Say you have an user action that involves access to multiple DAOs. Who would coordinate that?). In most cases your service layer also contains your application business logic.
Might want to read on the Service Layer before anything else. See the following questions just to get you started:
https://stackoverflow.com/questions/2295445/purpose-of-the-service-layer
https://stackoverflow.com/questions/2762978/the-purpose-of-a-service-layer-and-asp-net-mvc-2
A service layer is considered an anti-pattern by OOP purists (i.e. an anemic domain model) but it is useful in large enterprise applications because it offers an easier model to work with and also allows it to be used as a transaction boundary. Again, you can find advantages and disadvantages of a service layer online.
Getting back to your question. If your service layer is just calling a DAO, then that's what it's doing. You need to preserve the abstraction and not have services build in a way in some place, and services built in another way somewhere else. Be consistent. Have the simple services just delegate to the DAOs, not implementing them.
Not sure from where your question arose, but just to cover this point also, if you are learning to build an application using service layers and DAOs, be aware that most books, tutorials, etc, don't quite go into explanations or complex details, so most service examples just delegate to DAOs, letting people scratching their heads and thinking "Well this is dumb! Why have an extra layer that does nothing? Just call the DAOs. Done. Much better". Well, NO.
So if you have a service layer, keep it clean and at a higher level of abstraction. Don't pollute it with your DAOs. Inject the DAOs instead and delegate to them.