why is my socks and dns server different. my socks5 is denmark, but dns show netherlands when i check whoer.net

kasper2

Carder
Messages
51
Reputation
0
Reaction score
11
Points
8
how can i fix this dns problem, i use 911.re and proxifier, thanks in advance :)
 

CarderPlanet

Professional
Messages
2,555
Reputation
7
Reaction score
594
Points
83
Describes the different ways to add additional DNS servers
You can add an additional DNS server to the Keenetic in different sections of the web configurator. In this article, we'll cover the differences in customization.
You can add an additional DNS server on the following pages:
  • "Home network" (in the DHCP server settings);
  • "Wired" / "Wireless ISP" / "DSL-connection" (in the IP settings);
  • "Internet Filter" (in the "DNS Servers" section).

You can add a DNS server in the advanced DHCP settings for your home network.
DNS addresses registered here will be issued via DHCP to devices on your home network. And in this case, the devices will refer directly to these addresses, and not to the DNS-proxy of the Keenetic router.
If you do not make the above settings, the devices will contact the Keenetic DNS proxy, and it will already transmit these requests to the addresses of the DNS servers that it has in the list.

The Keenetic DNS-proxy list includes DNS addresses received from the provider and registered manually in the "Internet" section on the Internet connection page ("Wired" / "Wireless ISP" / "DSL-connection") or in the "Network rules" section on page "Internet filter".
The only difference between the last two settings is that when you enter the DNS server address in the "Internet" section, it will be bound to the current Internet connection. And in the "Network rules" section on the "Internet filter" page, you can bind it to any router connection or leave the default value for any connection. Binding is only needed if you have a connection to several providers, and you need to use one DNS when connecting to one of them, and another DNS when connecting to another.

To leave only the DNS servers specified by the user in the Keenetic DNS list, and not use the provider's, you must enable the "Ignore DNS" option on all connections.
When using the provider's login and password authorization, a similar option must be enabled in the settings of the corresponding PPPoE, PPTP or L2TP connection.
For more information, see the Ignore DNS Provider article.

Ignore the DNS provider
Typically, the ISP automatically provides its users with their own domain server (DNS), but in some cases you may need to stop using these servers and replace them with the addresses of the public DNS or VPN provider.
Starting from KeeneticOS 3.1, in the web configurator, you can enable the option to ignore (disable) DNS servers automatically received from the provider. This feature is available for connections on the "Wired" page (including PPPoE / PPTP / L2TP), "Wireless ISP", "DSL connection".
Let's look at an example. In the router's web configurator, on the System Monitor page, in the Internet pane, click Connection Details. The line "DNS servers" displays the DNS addresses obtained automatically from the provider and additional servers specified manually.
The option to disable the DNS provider is located on the internet connection page. It prohibits using the addresses of DNS servers obtained via DHCP for the current connection.
When using an IPoE connection (without authorization) or with authorization via PPPoE / PPTP / L2TP, this setting can be found on the "Wired" page in the "IP and DNS Settings" section. The settings for WISP and ADSL connections are found on the respective Wireless ISP and DSL Connection pages.
Click "Show advanced IP settings" and enable the "Ignore DNS" option.

Important! After enabling the "Ignore DNS" option and saving the settings, a reconnection to the provider will automatically occur (disconnection and activation of the interface for accessing the Internet).
After disabling DNS on the "System Monitor" page, the "DNS servers" line will no longer display the addresses automatically received from the provider.

Important! Network configurations vary from ISP to ISP. Disabling the provider's DNS addresses can lead to inoperability of tunnel connections (PPPoE / PPTP / L2TP), failures in the operation of additional services, etc. Before ignoring the DNS provided by your provider, make sure that there are no domain names of servers authorizing your connection in the settings. If they contain a server address in the format of a domain name, for example tp.internet.beeline.ru, in this case, you cannot disable DNS on the connection that is used to connect to the authorization server - usually this is a Wired (ISP) connection, since this can make it impossible to determine the address of the server providing access to the Internet.

Note: If one of the Internet filters (Yandex.DNS, SkyDNS, AdGuard DNS) is enabled in the router settings, all DNS requests will be directed to the service addresses. In this case, the provider's DNS servers and additional ones added manually will not be used. If DoT / DoH servers are used in the router settings , they are not displayed on the "System Monitor" page in the "DNS servers" line. When the ISP's DNS is disabled, the DoT / DoH service addresses will be used.
You can find more information in the article "Using Public DNS Servers".

How to intercept DNS?
There can also be several approaches here.
  • Interception of DNS traffic via PCAP or NFLOG
    Both of these interception methods are implemented in the sidmat utility. But it has not been supported for a long time and the functionality is very primitive, so you still need to write a binding for it.
  • Analysis of DNS server logs
    Unfortunately, the recursors known to me cannot log responses, but only queries. In principle, this is logical, since, unlike requests, responses have a complex structure and it is difficult to write them in text form.
  • DNSTap
    Fortunately, many of them already support DNSTap for this purpose.

What is DNSTap?
gc4gqsppif5ypkbf06ok0oihll4.png


It is a client-server protocol based on Protocol Buffers and Frame Streams for transferring from a DNS server to some kind of structured DNS queries and responses collector. In fact, the DNS server transmits the metadata of requests and responses (type of message, IP of the client / server, and so on) plus full DNS messages in the (binary) form in which it works with them over the network.

It is important to understand that in the DNSTap paradigm, the DNS server acts as the client and the collector acts as the server. That is, the DNS server connects to the collector and not vice versa.

Today DNSTap is supported in all popular DNS servers. But, for example, BIND in many distributions (like Ubuntu LTS) is often compiled for some reason without its support. So let's not bother with rebuilding, but let's take a lighter and faster recursor - Unbound.

How to catch DNSTap?
There are a dnstap dnstap-ldns number of CLI utilities for working with a stream of DNSTap events, but they are poorly suited for solving our problem. So I decided to reinvent my bike that does whatever it takes: dnstap-bgp

Work algorithm:
  • When launched, it loads a list of domains from a text file, inverts them (habr.com -> com.habr), excludes broken lines, duplicates and subdomains (i.e. if the list contains habr.com and www.habr.com, it will be loaded only the first) and builds a prefix tree to quickly search this list
  • Acting as a DNSTap server, it waits for a connection from the DNS server. In principle, it supports both UNIX and TCP sockets, but the DNS servers I know are only able to use UNIX sockets
  • Incoming DNSTap packets are deserialized first into the Protobuf structure, and then the binary DNS message itself, located in one of the Protobuf fields, is parsed to the level of DNS RR records
  • It is checked whether the requested host (or its parent domain) is in the loaded list, if not, the answer is ignored
  • Only A / AAAA / CNAME RRs are selected from the response and the corresponding IPv4 / IPv6 addresses are pulled from them
  • IP addresses are cached with configurable TTL and advertised to all configured BGP peers
  • When receiving a response indicating an already cached IP - its TTL is updated
  • After the TTL expires, the entry is removed from the cache and BGP announcements

Additional functionality:
  • Re-reading the domain list by SIGHUP
  • Synchronizing cache with other dnstap-bgp instances over HTTP / JSON
  • Duplicate cache on disk (in the BoltDB database) to restore its contents after restart
  • Support for switching to a different network namespace (why this will be described below)
  • IPv6 support

Restrictions:
  • IDN domains are not yet supported
  • Few BGP settings

I have compiled RPM and DEB packages for easy installation. Should work on all relatively recent OSs with systemd, since they have no dependencies.

Scheme
So, let's start assembling all the components together. As a result, we should have something like this network topology:
cmksuol_njfgyjznmlf3oj6u94m.png


The logic of work, I think, is clear from the diagram:
  • The client has our server configured as DNS, and DNS requests must also go through the VPN. This is necessary so that the provider cannot use DNS interception for blocking.
  • When the client opens the site, it sends a DNS request of the form "what are the IPs of xxx.org"
  • Unbound resolves xxx.org (or takes from the cache) and sends a response to the client "xxx.org has such and such IP", duplicating it in parallel via DNSTap
  • dnstap-bgp announces these addresses to BIRD via BGP if the domain is on the blocked list
  • BIRD announces a route to these IPs with a next-hop selfclient router
  • Subsequent packets from the client to these IPs go through the tunnel

On the server for routes to blocked sites, I use a separate table inside BIRD and it does not intersect with the OS in any way.
There is a drawback in this scheme: the first SYN packet from the client, most likely, will have time to leave through the domestic provider. the route is not announced instantly. And here options are possible depending on how the provider makes the blocking. If he just drops traffic, then there is no problem. And if he redirects it to some DPI, then (theoretically) special effects are possible.
Also, miracles are possible with clients not observing the DNS TTL, which can lead to the fact that the client will use some outdated records from his rotten cache instead of asking Unbound.
In practice, neither the first nor the second caused problems for me, but your mileage may vary.

Server Tuning
For ease of rolling out, I wrote a role for Ansible. It can configure both servers and clients based on Linux (designed for deb-based distributions). All settings are pretty obvious and set in inventory.yml. This role was cut from my big playbook, so it may contain bugs - pull requests welcome :)
 

coke88

Member
Messages
9
Reputation
0
Reaction score
6
Points
3
Most of the methods on the network are outdated, but you can learn from them. DNS is inconsistent, indicating that your network is not a true global proxy. You need a real global proxy, buy a router, install Clash, this software, buy 911s5, forward the traffic to the router, connect the router WiFi so that the network is a real global proxy
 
Top