Verify DNS SOA (Start of Authority)

Question

I am having trouble understanding a very specific part of the DNS Service and it's underlying structure. It is best described by showing a specific problem that could arise by a malicious ISP (Internet Service Provider).

Assuming the case that my ISP modifies the SOA of dns records it delivers to it's users. How could i verify the SOA correctness if i cannot access other DNS Servers.

My Knowledge of the processes so far:

• 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?
• One the authority of a DNS Server is defined within the DNS Servers by the means of the dns structure, the authoritative servers can return the dns entries for a domain.

I hope to have made my question as understandable as possible. If possible reference RFC's that are specifically on this topic but also summarize the logic behind it.

Thank you

Answer 1

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.

Answer 2

SOA is just another DNS resource record. Of cource, it has a special function, but still what applies to DNS RR in general will apply to SOA. It could be requested as usual (like this: host -vt soa example.com).

This record constitutes of name of some authoritative DNS server, administrative e-mail address (in "domain name" form, where @ is replaced with a dot), and bunch of numbers, which define zone serial number (intented to only increase and never go down) and timers, of which negative reply lifetime is very important, as it defines for how long remote caches can store "NXDOMAIN" replies.

In raw "good old" DNS there is no mechanism to check for DNS RR tampering on the fly. Indeed, an ISP could do that and will go unnoticed.

There IS a measure to fight this in modern DNS. It is called DNSSEC. In the essence, this is a bunch of special DNS RRs with digital keys and digital signatures which authenticate the corresponding data RRs, and the whole chain of trust beginning with DNS root (.), whose keys are stored inside any DNSSEC-capable resolver. These keys authenticate the servers responsible for TLDs, each TLD authenticates server of 2nd level domains and so on, down to the end server which authenticates the particular record. Following this chain of trust, this resolver could detect any malicious tampering. This includes the ability to authenticate non-existence of some record. Also nobody could deny the fact the domain uses DNSSEC, because this information is signed by their parent DNS level. For example, the .com zone is signed, and thus if you provide required DNSSEC data to your registrar and they published it in the .com zone, nobody can falsely claim you don't use DNSSEC for your domain, because that claim wouldn't verify against .com zone signatures, and if they would try to claim .com isn't signed, that wouln't verify against keys stored on the resolver itself.

In general, these signatures remain valid even when served by the DNS caching server, so it doesn't prevent caching. They only authenticate the presented record was produced by the authoritative server and it is presented exactly without modifications.

However, the malicious ISP can still deny service to such "too smart" resolver. The only thing resolver could do if it detects tampering is to return an error, which results in denial of service. An ISP then might tamper with every DNS packet so that DNS effectively wouldn't work with DNSSEC checking enabled, motivating users to disable that, reverting to plain old unsecure DNS. They might invent all sorts of looking-good reasons to excuse this behaviour. Then, after convincing users that DNSSEC is bad, this ISP could do anything.