Yes, DNSSEC is immune to this kind of attack. Starting at an anchor (usually the root, sometimes DLV), every delegation is either explicitly secure (presence of DS set on delegation):
powerdns.com. 172800 IN NS powerdnssec1.ds9a.nl.
powerdns.com. 172800 IN NS powerdnssec2.ds9a.nl.
powerdns.com. 86400 IN DS 44030 8 3 7DD75AE1565051F9563CF8DF976AC99CDCA51E3463019C81BD2BB083 82F3854E
powerdns.com. 86400 IN DS 44030 8 2 D4C3D5552B8679FAEEBC317E5F048B614B2E5F607DC57F1553182D49 AB2179F7
powerdns.com. 86400 IN DS 44030 8 1 B763646757DF621DD1204AD3BFA0675B49BE3279
or explicitly insecure (NSEC[3] bitmap proves absence of DS on delegation):
gov-1l.us. 7200 IN NS HNS1.BEYONDHOSTING.NET.
gov-1l.us. 7200 IN NS HNS2.BEYONDHOSTING.NET.
gov-1l.us. 86400 IN NSEC GOV-ABUSE.us. NS RRSIG NSEC
or implicitly insecure (NSEC3 opt-out):
stackexchange.com. 172800 IN NS brad.ns.cloudflare.com.
stackexchange.com. 172800 IN NS roxy.ns.cloudflare.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
4OTDAP6T1E8VS8BHMCK8CDHSGE3GCOBM.com. 86400 IN NSEC3 1 1 0 - 4OTJJUP7OGM6C149HPOE7O9M1L9LS1OP NS DS RRSIG
(stackexchange.com
hashes to 4otjehvpu9q5tm1d5v0ec302rcbll9um
which is covered by the second denial, thus there is no secure delegation).
In all of these cases, IF there is a secure delegation, the NSEC[3] record for the name in question will prove the presence of DS. Thus, if signatures are stripped, a validating client can detect this.
For further reading, I highly recommend RFC7129: Authenticated Denial of Existence in the DNS and section 5.2 (Authenticating Referrals) of RFC4035 (Protocol Modifications for the DNS Security Extensions)