Domain Name System | BOINC | Domains | How to DNS?

DNS-GA


Server Information

DNS 1

Address:
dns1.dns-ga.de
dns1.dns-ga.net
dns1.dns-ga.com
Resolved:
31.16.127.20 (may change)
2a02:8108:8780:157e:6af7:28ff:fe98:c366
DoT:
YES
DoH:
YES
DNSSEC:
YES
Recursion:
YES
Authoritative:
YES
Website:
NO
Ports:
53, 443, 853

DNS 2

Address:
dns2.dns-ga.de
dns2.dns-ga.net
dns2.dns-ga.com
Resolved:
217.160.166.161
2001:8d8:820:3a00::b:c47
DoT:
YES
DoH:
YES
DNSSEC:
YES
Recursion:
YES
Authoritative:
YES
Website:
YES (www.)
Ports:
53, 80, 443, 853, 10443

DATA HANDLING

The website does not save nor process any user data. The services available via the Domain Name Service do.
Here is how your data is processed/saved/deleted on our (and other DNS) servers.

Logging

Log example / explanation

The following data is logged:

  1. Date of request
  2. Timestamp with milliseconds
  3. Client ID
  4. Full (public) IP address of the client that is requesting
  5. The complete domain, with host and sub-level-domains, which the client is requesting the address for
  6. The view (server internal) from which the client requests. Is used to split public and company dns traffic for example and normally depends on the ip address that is sending the request
  7. Same as 5. The query sent to the server
  8. 'IN A' means that the client requests an internet address (IPv4) and the '+' implies the recursion desired flag (rd flag) is set. It tells the server to look up what the address is, if it doesn't exist in the servers chache
  9. The address of the server tasked to process the query. If it would show anything different from 217.160.166.161 (dns2.dns-ga.de) then there's definitely something wrong
  10. Sometimes the domain doesn't resolve to an address or the dns server responsible for the domain doesn't respond. In this case the server either sends 'NXDOMAIN', which means the domain does not exist or it will send a SERVFAIL (timed out)

Most DNS-Services say that they are not logging their dns traffic data. Whom to trust is up to the user.
Even though we are logging dns traffic data (and we're not hiding it), we solely use it to debug and improve our services.
The data doesn't leave our dns servers in any way, other than the query-answers of course. The servers host a statistics website, on which there is information about quantity of queries received, qeury type, etc. Lucky few, who find it c:
Although it uses the server data to create the statistics, it does not contain any personal data. After some time the logs, which are kept on the server, are deleted in a specific way, which we will clarify further down on this site.
We are trying our best to keep data collection to a minimum, as we are aware that it is a point of interest for some attackers... which brings us to:

Security Features

security features1
A dnssec response with complete and one with failed validation.

security features2
On the top the server side. On the left a TLS response. On the right a HTTPS response.

The security features of our dns servers are as follows:

  1. DNSSEC enabled
  2. DNS over TLS
  3. DNS over HTTPS
  4. Rate limeted responses
  5. No redirection of non existent domains
  6. Many more...

DNSSEC

DNSSEC is a feature of the domain name system. It uses different trust anchors and multiple dnssec enabled dns servers, to make sure you're really getting the answer you'd expect to get.
If the dnssec validation fails (like for the purposefully wrongly configured domain dnssec-failed.org), the server that was asked (and this has to be done specifically, although every modern system should do it on it's own) will return a 'SERVFAIL' response.
The response code 'SERVFAIL' is used for many things such as timed out connections and misconfigurations. The best use of it by far probably being not to send an ip address when dnssec fails.
It will protect the user (client) from being redirected to some malicious websites and makes sure that the ip address of the requested website is not changed somewhere down the chain.
Sadly the whole process still depends on a rather insecure protocol: UDP
The protocol has it's advantages, but in terms of user security it has it's flaws. One is it being unencrypted, meaning a man-in-the-middle attack is fairly simple to do.
That's why they (Internet Engineering Task Force) proposed a standard to send the dns data via an encrypted protocol (SSL/TLS) and thus made it harder to attack the sent packets.
Which brings us to:

DoT - DNS over TLS/SSL

The TLS (Transport Layer Security) protocol (the name speaking for itself) is used to encrypt the dns data and uses the port 853 rather than 53 on the dns server.
One advantage of this is the very strong encryption and (additionally) chain of trust which has to be broken in order for an attacker to change the dns data.
That being a very hard task I should say. The protocol protects you from man-in-the-middle attacks, and almost all sorts of attacks that have to do with eavesdropping and manipulating your request or reply data.
Dns over tls is faster than dns over https.

DoH - DNS over HTTPS

DNS over HTTPS uses the hypertext transfer protocol with tls encryption to securely get your data from one to another place.
It is commonly known as being a part of the url ('https://www.example.com') in your browser and relies on port 443.
If correctly configured it will even protect you from logging on the dns servers
Both HTTPS and TLS have one disadvantage though. As encryption often does, the protocols require much larger bandwith and storage availability on the dns servers.
For the end user however, it is the best practice. Activate dns over tls/https whenever you can!

Rate Limit ??

Why would rate limiting on a server like this make sense?
Security!
The limiting of dns replies is a simple way of protecting not only one induvidual on the internet. It can disencourage and help with protecting from denial of service attacks.
The attacks consist of one or more attackers (botnets!) sending dns requests in the name of their victims (sending requests with source address: victim) and thereby sending lots (and most of the time too much) data on it's way too the victim, which the server believes to be the requesting entity.
Often times the attackers try with large amounts of requests to exhaust their victims bandwith (creating a denial of service event) and preferably with UDP packets as they are easy to forge.

Rate limiting not only helps to prevent attacks but also protects the dns servers from being queried a bunch of 'NXDOMAIN' requests, which are sent by bots a lot of the times, many times a second.
This may have the side effect of not exhausting the client's but the server's internet connection, which leads to denial of service on a whole other level than intended.
Therefore we are rate limiting to prevent such occasions.

No Redirection!

Some dns providers redirect 'NXDOMAIN' response codes to their marketing driven websites. Which, no doubt you agree, is aweful
for both, your experience browsing the web as well as the independence and impartiality and purity of the internet services. We don't do that! You can try it yourself right now by asking our servers (or even try your internet provider's) a domain which is not existent.
Simply try some random string of characters infront of dns-ga.de like abcdefzyx.dns-ga.de and you'll find yourself with a 'NXDOMAIN' response,
either indicated by your browser with 'ERR_NAME_NOT_RESOLVED' (or similar) or the NXDOMAIN response header somewhere. (We can guarantee the domain doesn't exist... for obvious reasons ^-^)

While talking about redirection...
As you may have noticed if you're on https://dns-ga.de/: Why is this website on port 10443?
Simple answer: We cannot bind to port 443 (HTTPS standard) as our dns services require to be reachable via https (DoH) on port 443.
That's why we have allowed to redirect you to the correct port for this website. This website is also available via http on port 80 (standard).
In case you think you typed .com instead of .de, you may be right. We are redirecting .net and .com to .de as we're writing in English anyway.

And many more...

The dns servers are secured with all kinds of mechanisms and settings. We have listed above which options are your choice. Now it's up to you to enable the features!

Deleting Data

logrotate

Deletion of your data is made easy by the system we're using.
Every time there is a new log event, our logs get bigger in size (disk usage).
When adding a new entry the system checks if the log has reached a certain data size. (Our largest being 250 Megabytes)
As soon as the data limit is reached, the system will close the log file and start a new one. (On our systems for up to 3 versions)
In the event that a predetermined version limit is reached (amount of different log files of one type) then the system will close the last log file,
and delete the first log file created and create a new one after. There it will start the process all over again. Deleting and creating a second, and a third.
After less than a day all log files were deleted and new ones created.
Thus making sure that your data will not stay longer than a few days at most.
Small note for protection law enthusiasts: In case you file a data deletion request... we're just gonna dump all our log files. It's that easy,
because we're not collecting data in other ways. (Plus, we would love to see you try deleting google's dns logs first :P)

Statistics

Last server reload: 10.07.2022

Incoming Queries

Source: collected data
Last updated: 10.07.2022

Type Value
Queries 38,313,894
A (IPv4) 37,371,183
MX (Mail) 1,704
CNAME (Canonical) 324,950
AAAA (IPv6) 269,112
PTR (Pointer) 203,328
TXT (Text) 90,019

Cache Database

Source: collected data
Last updated: 10.07.2022

Type Value
Stored ~300,000
A (IPv4) ?
NS (Name Server) ?
CNAME (Canonical) ?
AAAA (IPv6) ?
PTR (Pointer) ?
NXDOMAIN (Non existent) ?

Outgoing Queries

Source: collected data
Last updated: 10.07.2022

Type Value
Queries ~73,000,000
A (IPv4) ?
AAAA (IPv6) ?
MX (Mail) ?
CNAME (Canonical) ?
PTR (Pointer) ?
NS (Name Server) ?