A) If we want to verify that the owner of a domain created a DNS record, why not go through the same process as wildcard TLS certificate issuance ?
Verify ownership of *.example.org Why do we need a new trusted root key (moreover issued in the US) that takes precedence over the bundled (OS/browser) trusted CAs ?
B) If your computer runs a local resolver or goes through a compromised network, can the compromised network replace all the public keys in DNSKEY response (including the answer for root) and make your computer believe that the DNSSEC record is valid ?
If your computer runs a normal local resolver and goes through a compromised network, there's nothing DNSSEC does at all to help you. It's a server-to-server protocol; between stub resolvers and servers, the whole protocol collapses to a single "AD" bit in the header that says "trust this packet, your server really did all the signature validation". This is a silly design, and is the reason for things like DoH.
If you're running your own DNS server, attackers can't simply replace the DNS root key; there's a somewhat elaborate process for publishing new ones, which are stored in anchors usually on the filesystem of your DNS server. See Paul Wouters article here:
https://www.redhat.com/en/blog/what-you-need-know-about-firs...
In practice, you can ignore pretty much all of this, because DNSSEC is moribund and almost nobody uses it; in reality, the DNSSEC root private keys could land on Pastebin tomorrow and nothing would "break", and most tech company security teams wouldn't even need to be paged.
In order to have a chain of trust, you need a starting point and the root is the starting point for the DNS. The root key--it's actually the root Key Signing Key (KSK)--enables a DNSSEC-aware resolver to validate the signatures from a TLD (like .com) to your zone example.com.
It’s the same concept X.509 uses. A root certificate is used to sign an intermediate certificate which signs the certificate you get from Lets Encrypt, for example. Your browser trusts that certificate because it can cryptographically validate the signatures back to the root certificate.
Because of the flexibility of DNSSEC, if for whatever reason, you choose to not trust the root KSK, you can use a different entry point and create your own island of trust.
If we want to verify that the owner of a domain created a DNS record…
DNSSEC is for authenticating the data in DNS records, not for verifying ownership or identity. When a DNSSEC-aware resolver validates a signed zone, we know the DNS records haven’t been tampered with.
The DNSSEC chain of trust is separate from the X.509/Web PKI chain of trust; DANE (DNS-based Authentication of Named Entities) can be used to bridge these two chains.
Remember: DNSSEC only deals with digital signatures; X.509/Web PKI deals with certificates, which is a public key + an identifier.
If your computer runs a local resolver or goes through a compromised network, can the compromised network replace all the public keys in DNSKEY response (including the answer for root) and make your computer believe that the DNSSEC record is valid
Short answer: no.
Longer answer: All DNSSEC-aware resolvers--BIND, Unbound, Knot, etc.--have the root KSK built-in, so they don't rely on the network for it.
Since the resolver already has the root KSK, the validation of the corrupted signatures would fail.
Since the root KSK is the public trust anchor for DNSSEC, it’s widely available and easy to check: https://www.iana.org/dnssec/files.
A great introduction to DNSSEC + DANE: https://youtu.be/BhvU19RJrPY
This presentation on DNSSEC and DANE is long but it’s worth your time if you want to understand DNSSEC better: https://youtu.be/A8SgW9y__io