Wow, kids are taught about Bitcoin at school these days? What a time to be alive! Keep it up Sandra.
I find your question interesting in light of the latest Bitcoin release, v23.0 not too long ago (April 2022) which changed a few things with regards to the P2P network.
P2P and network changes- A bitcoind node will no longer rumour addresses to inbound peers by default. They will become eligible for address gossip after sending an ADDR, ADDRV2, or GETADDR message. (#21528)
- Before this release, Bitcoin Core had a strong preference to try to connect only to peers that listen on port 8333. As a result of that, Bitcoin nodes listening on non-standard ports would likely not get any Bitcoin Core peers connecting to them. This preference has been removed. (#23542)
So yes, there are DNS seeds for initial configuration, but as jackg mentioned they are not needed for further operation, since Bitcoin Core will discover other nodes quickly.
When it comes to SPV nodes, you may have misunderstood a little bit. They typically don't use DNS seeds like Bitcoin Core, but just connect to a trusted node. This type of software often has something hard-coded that connects to the software developers' own Bitcoin node and
should absolutely be changed to point to your own node. There are different connection methods, such as connecting to a local node, or using the Electrum protocol (not to be confused with the Electrum wallet, even though it does use this protocol).
8. Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep
a copy of the block headers of the longest proof-of-work chain, which he can get by querying
network nodes until he's convinced he has the longest chain, and obtain the Merkle branch
linking the transaction to the block it's timestamped in. He can't check the transaction for
himself, but by linking it to a place in the chain, he can see that a network node has accepted it,
and blocks added after it further confirm the network has accepted it.
The Bitcoin wiki is also a good place to look at.
Simplified payment verification
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. bitcoinj is an implementation of this mode.
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.
In case you are interested what the Bitcoin Core project has to say about DNS seed operators, there is a
policy on GitHub.
https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md
