Some servers filter responses with intranet IP addresses

[kkkgo]

I've noticed that certain server are filtering intranet domain names and returning empty records when the resolved IP address is a private address. One such server is jp.tiar.app. I suspect that this filtering is implemented for security reasons. However, can we consider these server as having "filter=false" behavior?

To reproduce the issue, you can test it with the following domain name: local.03k.org (10.9.8.7).

[kkkgo]

## sby-limotelu

non-censoring, non-logging, DNSSEC-capable Hosted in Surabaya, Indonesia (Dnscrypt) https://limotelu.org maintained by poentodewo (https://github.com/poentodewo)

sdns://AQcAAAAAAAAAEzE5OS4xODAuMTMwLjM5Ojg0NDMg1U5MYSDK58uVdJ8dKtp0UZaCKSG0znwQLVHYKk1QyuwcMi5kbnNjcnlwdC1jZXJ0LnNieS1saW1vdGVsdQ

# dnslookup local.03k.org sdns://AQcAAAAAAAAAEzE5OS4xODAuMTMwLjM5Ojg0NDMg1U5MYSDK58uVdJ8dKtp0UZaCKSG0znwQLVHYKk1QyuwcMi5kbnNjcnlwdC1jZXJ0LnNieS1saW1vdGVsdQ
dnslookup v1.9.1
dnslookup result (elapsed 16.285129805s):
;; opcode: QUERY, status: REFUSED, id: 52879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags:; udp: 1232
; EDE: 18 (Prohibited): (EIM4)

;; QUESTION SECTION:
;local.03k.org. IN       A

;; ADDITIONAL SECTION:
explanation.invalid.    10800   IN      TXT     "blocked by DNS rebinding protection"

[kkkgo]

Furthermore, I believe that this behavior can be detected using a script and can be addressed by running periodic checks through actions. These checks can remove the "No filter" label from these servers.

[jedisct1]

Hi!

And thanks for reporting this!

Indeed, it is not expected to block local IP addresses when the "no filter" flag is set.

And this is causing more issues that it solves.

I'll run a scan of the servers for that. Thanks again!

[kkkgo]

I tested all DNS servers using a simple script to get a list of some DNS servers that will filter, I hope this helps.
List of DNS servers that will filter:
https://raw.githubusercontent.com/kkkgo/PaoPao-Pref/main/dnscrypt_resolver/ban_list.txt

[Brueggus]

Good catch!
This restriction should now be removed from all dnscry.pt resolvers. It's part of the default configuration CentOS/Alma Linux ship with unbound and I missed to remove it.

[dct-infra]

@kkkgo

Okay, let's play a little game. It's that time of year again, you know, when the urge to resurrect old arguments hits like a holiday hangover. This year's victim? Why is that list of lying DNS resolvers are not resolving private IPs, of course!

So, I ask you, my friend, why on earth would a public DNS resolver be bothered with your little local network? Seriously, who's asking for 10.9.8.7 to be looked up on some random server? It's just weird with a bunch of security and privacy implications.

I mean, it's called a "private" network for a reason, right? A sanctuary for your internal devices to gossip amongst themselves, blissfully unaware of the outside world.

Before you go running scripts and adding tags like you're redecorating a haunted house, maybe take a peek at these:

https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Filters#dns-rebinding-protection
https://en.wikipedia.org/wiki/DNS_rebinding
But hey, if you're determined to invite your internet neighbors to your private party, do so by your own means and do it knowingly.

[kkkgo]

@dct-infra

Thank you for your response, but I’d like to respectfully address a few points regarding the filtering of private IPs by DNS resolvers that claim to be “non-filtering.”

1. Commitment to Transparency

When a public DNS resolver advertises itself as “non-filtering,” it creates an expectation of neutrality and transparency. If such a resolver is filtering requests to private IP addresses, that constitutes a form of filtering, even if it is framed as a security measure.

• If filtering is implemented, it should be disclosed to users so they can make informed choices. Transparency is a fundamental principle of trust in public services.

2. Legitimate Use Cases for Private IP Resolution

While private IPs are typically used within local networks, there are valid scenarios where resolving them via public DNS servers is necessary:

• Testing and debugging: Developers often simulate network behavior or IoT device configurations that require external resolution of private IPs.
• Cross-network setups: In certain environments, private IP resolution may be intentional for collaboration or specialized architectures.
  Filtering these requests by default can disrupt legitimate use cases rather than enhance security.

3. Distinguishing DNS Rebinding Risks

You cited DNS Rebinding as a justification for filtering private IPs. However, DNS Rebinding attacks rely on malicious domain names resolving to private IPs, typically targeting browser vulnerabilities.

• Preventing DNS Rebinding is better addressed at the client or application level (e.g., browser security policies or firewalls) rather than blanket filtering by public DNS resolvers.
• Overgeneralized filtering may also block legitimate dynamic DNS or development-related scenarios, which could be counterproductive.

4. Balancing Security and User Awareness

The key issue isn’t whether filtering is “bad” or unnecessary—it’s the lack of transparency. If filtering is implemented for private IPs, users should be informed clearly and upfront, so they can understand and evaluate the trade-offs involved.
The purpose of a DNS resolver is to provide accurate answers to queries, not to decide what is “good” or “bad” for users. Expanding the scope of filtering in the name of protecting users can lead to overreach.

• If private IP filtering is deemed acceptable, what’s stopping DNS providers from also filtering other content, such as certain websites, under the pretense of "protecting you"?
• This logic mirrors the slippery slope seen in broader internet censorship, where “for your own good” often becomes an excuse for opaque, restrictive behavior. A non-filtering resolver should prioritize correctness in responses over moral or security-based gatekeeping.
• Resolving Is About Correctness, Not Judgment

5. Looking to Industry Standards

If we’re searching for best practices in handling these scenarios, it’s worth examining what leading DNS providers are doing. Major providers like Google Public DNS and Cloudflare’s 1.1.1.1 do not filter private IP addresses by default.

• This demonstrates that large-scale, security-conscious providers find it unnecessary to implement such filtering for public DNS resolvers. If they can balance security with flexibility, why shouldn’t others follow suit?

[kkkgo]

@dct-infra Let me provide a real-world use case: an organization needs to connect to a VPN to access internal resources, such as an internal website with an HTTPS connection that resolves to a private IP address. Under modern browser standards, HTTPS is mandatory for certain APIs, like crypto (https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API), to function correctly. Simply using a private IP address is often impractical as it may trigger browser errors or fail to support scenarios where a single IP serves multiple services or websites.

Clearly, if I use most basic open-source solutions—such as the OpenVPN client—there’s no built-in functionality to hijack local DNS or modify the hosts file for the user. Blocking the resolution of private records for internet domain names unnecessarily complicates this otherwise straightforward collaboration setup—What I mean is, I just need to make a simple change to the DNS records to deliver the "configuration" to the client side.

[dct-infra]

@kkkgo

I'm so busy with filtering today so I'll get right to the point.

1. Private networks should be, you know, private! Let's not get all social about it. No point in discussing this.
2. It's about privacy and security for everyone, not just those who think they're special enough to need private IPs or local hostnames resolved publicly.
3. Rebinding attacks are real and can be messy, no justifications here. They're just one of the million reasons why private networks should remain private. Specific needs must be addressed with specific setups.
4. Moral judgment.
5. If we were to follow we wouldn't exist. The only standards I know of are here: https://www.rfc-editor.org/

[kkkgo]

@dct-infra
RFC 1918 defines the range of private address blocks, but resolving domain names to private addresses does not violate any explicitly defined behavior in RFC standards.

While modern HTTPS security standards have made older DNS rebinding attacks harder to execute, as you mentioned, if ethical standards are to be used for filtering, I believe you can manually add the required address blocks from the DNSCrypt documentation you referenced, or propose default filtering in client settings, much like the default DNS rebinding protection option in OpenWRT. Filtering behavior should occur at the client side, not at the public DNS server. As noted in the DNSCrypt documentation you shared, certain applications (like Plex) require disabling rebinding protection to correctly detect local clients.

In fact, I believe the discussion should not even focus on whether filtering is necessary, security concerns, or ethical implications—filtering is just filtering, as simple as 1=1, don’t you think?
Filtering is an objective fact. If you think this filtering is different from other types of filtering, you can even propose adding diversified "filtering type" labels.

[Brueggus]

unsubscribe Am 18. Dezember 2024 08:36:55 MEZ schrieb kissshot ***@***.***>:

…

@dct-infra RFC 1918 defines the range of private address blocks, but resolving domain names to private addresses does not violate any explicitly defined behavior in RFC standards. While modern HTTPS security standards have made older DNS rebinding attacks harder to execute, as you mentioned, if ethical standards are to be used for filtering, I believe you can manually add the required address blocks from the DNSCrypt documentation you referenced, or propose default filtering in client settings, much like the default DNS rebinding protection option in OpenWRT. Filtering behavior should occur at the client side, not at the public DNS server. As noted in the DNSCrypt documentation you shared, certain applications (like Plex) require disabling rebinding protection to correctly detect local clients. In fact, I believe the discussion should not even focus on whether filtering is necessary, security concerns, or ethical implications—filtering is just filtering, as simple as 1=1, don’t you think? Filtering is an objective fact. If you think this filtering is different from other types of filtering, you can even propose adding diversified "filtering type" labels. -- Reply to this email directly or view it on GitHub: #813 (comment) You are receiving this because you commented. Message ID: ***@***.***>