When i register a DNS with a registrar i enter a responsible DNS
Server for a domain name which defines the authoritative DNS Server.
This defines the SOA entry of the domain name lookup. This is where i
am missing some informations. How is the registrar's information (soa,
authoritative dns server ip etc.) pushed into the dns service system.
Or how does a client check the SOA's authenticity of a domain?
This is not exactly how it works, or maybe just an issue with terminology.
(you can look at RFC 8499 "DNS Terminology" for full details)
For any domain name to resolve it needs to have nameservers authoritative for it and those nameservers need to be listed at the parent zone, in NS records.
So, if you have example.com
you can decide that ns1.example.net
and ns2.example.net
will be authoritative nameservers for it and you configure them. This is not enough. For the resolution to work both nameservers must be listed in the parent zone, that is .COM
here.
All of this is basic DNS delegation mechanism, so this is covered by the canonical RFCs on the DNS, which are RFC 1034 and 1035. Note however that they are old, many things in them do not apply anymore (and of course many new things not described in them now apply) and some terms there, such as domain name, are used with another meaning that the one we have today.
How does the change in the parent zone happen?
You go to the registrar of example.com
and provide it with the nameservers. The registrar will then submit them through a specific non public protocol, typically EPP, to the registry, and after "some time" the registry authoritative nameservers on the zone will have NS records for your domain listing your nameservers.
EPP is STD 69, however you won't gain any useful high level understanding by reading those RFCs as they explain the protocol in details, which you never see anyway because it is only between registries and registrars.
As you can see, there is nowhere the mention of SOA
in the above. The SOA record is in your zone, not outside it, and will be given back, if asked for or for relevant queries, by either of your authoritative nameservers on your zone.
Note also that domain name registrar and DNS provider are two completely separate jobs. You choose a DNS provider to manage your authoritative nameservers, you choose a registrar to register a domain name and then update nameservers attached to it from time to time. Of course a given company can do both jobs at the same time but technically they are each doing specific things not related to the other one.
As for the authentication of the records, making sure they are not tampered with while in transit, as Nikita Kipriyanov already replied, this is a job for DNSSEC.
There are multiple RFCs covering DNSSEC and this technology is not trivial to master, you need first a solid understanding of DNS, including dark corners such as wildcards and CNAME, and then a basic understanding of cryptography. Instead of RFCs for this I suggest first having the introduction from Wikipedia which is good enough to wet one's appetite: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
To summarize things VERY broadly, with DNSSEC, all records (so not just the SOA
absolutely all records in the zone) will also have new associated RRSIG
records which holds a signature computed with some key over the content (the DNS record); if someone on the path changes part of the content, the signature will not match anymore (and no, obviously, he can't recompute the signature on the fly to make it match again).
For your specific use case you mention (a malicious ISP that can both listen on all your DNS queries - for analytics -, filter your queries, modify the responses), some people (including some browser vendors) will try to convince you that DNS over HTTPS (DNS over TLS exists too) solves all problems, which is false, and at the very least it does not provide the same services as DNSSEC.
But the idea of using DNS over HTTPS (where normally DNS is over port 53 in TCP and UDP, so all traffic is in plain text; DNSSEC adds integrity and authentication but not confidentiality, the whole traffic is still in the clear) is that by using HTTPS which is itself over TLS you gain confidentiality as TLS will encrypt all exchanges, that is both your DNS queries and your DNS responses.
Where promoters of this myth fail to adequately assess the problem, is that you do gain privacy for all your DNS exchanges (and the related fact that responses can not be modified; they still can be filtered), but ONLY between you and the recursive DNS server you query over DoH (the nickname of DNS over HTTPS). That specific DNS resolver obviously sees both your queries and answers as he is the one working on them for you, and hence it can give you absolutely what it wants, without any proof of authenticity... if DNSSEC is not used.