DNS Logs and Data Sovereignty: Why Location Matters

DNS logs look like technical records at first glance, but consider what they contain: which user, from which device, at what time, tried to reach which address. That information can reveal a person's interests, work patterns, bank and health sites. Wherever DNS logs can be linked to an identifiable person, they qualify as personal data under data protection law — Türkiye's KVKK (Law No. 6698) and the GDPR alike — and where they are processed becomes a legal question, not just a technical one.

This article is for general information and is not legal advice; consult your data protection counsel for an assessment specific to your organization.

What personal data do DNS logs contain?

• Source IP and device information: Inside an organization, usually assigned to a specific employee.
• User identity: On systems that use Active Directory mapping, queries are recorded directly against a username.
• The domains being visited: Queries to health, union, religious or political sites can indirectly point to special categories of personal data.
• Timestamps: They expose working hours and behavioral patterns.

Under both KVKK and GDPR, any information relating to an identified or identifiable natural person is personal data; DNS logs on a corporate network cannot fall outside that definition.

Where does data go with cloud-based DNS security?

In cloud-based DNS security services, the organization's DNS queries are redirected to the vendor's cloud infrastructure for analysis. The practical consequences:

• Query logs are processed and stored in the vendor's data centers, usually abroad.
• Retention periods, access rights and secondary use are governed by the vendor's policies.
• The foreign law the vendor is subject to can result in third-party access to the data.

Under KVKK Article 9 — and under the GDPR's transfer rules — moving personal data across borders is, as a rule, subject to explicit consent or specific safeguards (adequacy decisions, appropriate guarantees). DNS logs flowing to a cloud service are technically an international data transfer and should be recorded as such in the organization's data inventory, privacy notices and records of processing.

Additional requirements for public institutions and critical infrastructure

For public institutions the picture is clearer still: public-sector information security regulations generally require critical data and log infrastructure to remain under the institution's control. In critical infrastructure sectors — defense, energy, finance — sector regulations impose further conditions on where log data resides and who can access it. In this framework, processing DNS logs in a foreign cloud service is a non-starter for many organizations.

Statutory log retention obligations also require organizational control over the integrity and availability of logs; that control is limited when retention periods and formats depend on a vendor's subscription plan.

How does the picture change with an on-premise model?

With on-premise DNS security, analysis, logging and AI run on the organization's own servers:

• The transfer question disappears: Because data never leaves the organization, there is no international transfer to assess; the chain of responsibility stays in-house.
• Retention policy belongs to the organization: The organization decides how long logs are kept, in what format, and who can access them — including indefinite retention.
• Audits become simpler: The entire log infrastructure can be demonstrated within the organization's own boundaries.
• Air-gap compatibility: The same protection and logging continue even on networks closed to the internet.

You can find the security architecture comparison of on-premise and cloud models on the Obsolix security and compliance page, and the product-by-product table on the comparison page.

Control questions for your organization

1. Where are your DNS logs processed and stored right now — in-house, or in a cloud service?
2. If in a cloud service, is that flow recorded as an international transfer in your data inventory and privacy notices?
3. Does your contract with the vendor address retention, deletion and access rights in line with your data protection obligations?
4. Can you demonstrate the DNS log chain end to end in an audit?
5. If transfer rules tighten, can your architecture adapt?

Frequently asked questions

Does anonymizing DNS logs solve the problem?

True anonymization — where data can no longer be linked to a person by any means — is difficult for DNS logs; IP addresses, timing and behavioral patterns often allow re-identification. Pseudonymized data remains within the scope of data protection law.

Doesn't threat intelligence require sending data out?

No. Threat intelligence can be a one-way download: current malicious domain lists come in, and the organization's query data never goes out. That is the core design principle of the on-premise model.

Doesn't an on-premise model fall behind on current threats?

No; intelligence updates and model updates are brought in as packages, and analysis happens locally. Even in environments closed to the internet, updates continue via offline packages.