Home PC Games Linux Windows Database Network Programming Server Mobile  
  Home \ Programming \ Glibc support encryption by modifying the DNS     - Fedora network set up simple (Linux)

- Ubuntu System Log Configuration / var / log / messages (Linux)

- Nginx caching using the official guide (Server)

- The minimum initial use of the Linux operating system RancherOS feelings (Linux)

- Oracle in the add & split partition on the impact of global & local index (Database)

- MySQL InnoDB table --BTree basic data structures (Database)

- Setting the RedHat9 Intrusion Detection System (Linux)

- Spark SQL job of a lifetime (Server)

- Linux firewall Iptables study notes (Linux)

- Fedora 20 Installation and Configuration (Linux)

- Linux system ARP attack solution (Linux)

- FreeRadius installation process record (Linux)

- The Java way to stop a thread of execution (Programming)

- MySQL 5.7 perfectly distributed transaction support (Database)

- MyCAT log analysis (Database)

- Zabbix monitoring disk IO status (Server)

- Linux kernel TCP / IP parameters analysis and tuning (Linux)

- CentOS static IP network configuration (Linux)

- Creating and extracting archives 11 tar command examples in Linux (Linux)

- Use Bash script write CVS version control (Server)

  Glibc support encryption by modifying the DNS
  Add Date : 2018-11-21      
  Domain Name System (DNS) is one of the many weaknesses in Internet security; host applications accessed corresponding IP addresses can be misled to other places. In other words, it will connect to the wrong position, causing the middleman (man-in-the-middle) attacks and so forth. The DNSSEC protocol extension to DNS information through the establishment of a credible encrypted channels to resolve this vulnerability. After correctly configured DNSSEC, the application will be able to get reliable host information queries. About DNSSEC by trying to integrate better into the discussion GNU C library, we know that, to ensure information security DNS queries it is not so simple.

In a sense, this problem is solved years ago, we can configure a local domain name service for complete DNSSEC validation (verification) and allows the application by glibc function to use the service. DNSSEC can even be used to improve security in other areas, for example, it can carry SSH or TLS key fingerprint, so that the application can confirm that the dialogue with the correct server. However, when we hope to confirm the results of this self-proclaimed DNS with DNSSEC validation is not really been certified by the time - that is, when we want to rely on the security of DNSSEC promised, things get a bit complicated.


/etc/resolv.conf problem

From the point of view of glibc, the problem is in part because glibc itself does not do DNSSEC validation, instead of referring to the /etc/resolv.conf file server read from the file parsing and validation done, then the results returned to the application. If your application uses the underlying res_query () interfaces, the result will include a "Certified Data (authenticated data)" (AD) identification (if the domain name server is set up, then) to indicate DNSSEC validation has been successful. But they did not know glibc credit these results provide domain name server, so it really does not tell whether the application result is really reliable.

Recommendations by the glibc maintainer Carlos O'Donell proposed increase is an option (dns-strip-dnssec-ad-bit) in the resolv.conf file tells glibc unconditionally remove AD logo. This option can be set by the release, expressed DNSSEC level DNS query results are not reliable. And once established a good right environment can obtain reliable results, and then remove this option. Thus, although the problem has not been fully resolved, at least on the basis of the application has to evaluate the reliability obtained from glibc DNS query results.

A secure environment configuration should look like? This situation should be standard and not too bad: there is a local name server, through the loop (loopback) access interface, as the only access /etc/resolv.conf file entries. This domain name server should be configured to do the check, but the check fails after simply does not return any results. In most cases, the application will no longer need to be concerned about AD logo, if the results are not reliable, the application can not see. Some releases have tended to this model, but the situation is still not as some people imagine that simple.

One of the problems is that in this way the /etc/resolv.conf file into the center of the trustworthiness of the entire system. However, in a typical Linux system, there are numerous DHCP client, the network script and many more programs can modify this file. Like Paul Wouters pointed out, in a short time it is impossible to lock the file. Sometimes this change is necessary: ​​in a diskless system startup, before starting its own domain name server is a domain name service; a whole DNS system environment will be different according to the connected network and change; Runtime in the container is also preferably configured to use the host's domain name server; and so on.

So now generally believed that the existing system in the /etc/resolv.conf file and can not be trusted. So it was suggested to add another profile (/etc/secure-resolv.conf or whatever), but this did not solve the problem fundamentally. In addition, some participants feel that even if there is a run on the loop interface name servers are not really reliable, such as Zack Weinberg even suggested that the system administrator can intentionally disable DNSSEC confirmation (validation).

Since the current system configuration is insufficient trust, it can be inferred that, in the case of improvement can obtain reliable results after, glibc needs to have a way to notify the application. AD logo can be shielded manner discussed above (or "domain name server can trust this" option In contrast, adding a display); of course, this requires a locking system to a certain extent so as not to be subject to any non /etc/resolv.conf expected changes. Petr Spacek as recommended, there is a way the idea is to provide a way to allow applications to query glibc current communication is not a local domain name server.


In glibc, which handles?

Another way is regardless of the domain name server, but to do DNSSEC glibc itself confirmed. However, such a large lump of the encryption-related code into glibc also has great resistance. This will increase the size of the library itself, so that the feeling will increase the likelihood of attack using its application. Another extended look in this direction, by the recommendations made by Zack, can confirm the relevant code into the domain name service cache daemon (nscd) inside. Because the nscd is part of glibc, glibc maintained by the developer, so to some extent, can believe that we can confirm that the correct implementation of DNSSEC. And where the communication socket nscd is open, so it can not be considered /etc/resolv.conf problem. However, Carlos fear in this way can not let those who do not want to use nscd cache function accepted by users; in his opinion, can be ruled out nscd way.

So, at least in the near future, glibc unlikely fully implemented DNSSEC confirmed the entire inquiry process. This means that if there is a security application to be used to query the domain name glibc library, the library will need to provide an identity to evaluate the results from an independent domain name server returns to what extent reliability. This almost certainly need to release or system administrator to make some definite changes. Like Simo Sorce say:

If glibc does not use explicit configuration option to notify the application domain analysis with it is credible, there would be no use ...... not change it there is a great drawbacks, because application developers will immediately recognize that they can not be trusted any information obtained from glibc, so when dealing with DNSSEC related information is simply not it.

To configure a system to normal use DNSSEC requires changes to many components of the system - this is a release of a range of problems, take time to fully resolve. In this process of change glibc's role is likely to be relatively small, but very important part: if the application does not implement its own set of domain name parsing code, glibc DNS results are likely to be the only way to ensure credible. Running multiple DNSSEC implementation in a system does not look like a safe way, so it's better to do things right.

glibc project currently no way to determine what to do with this thing, although some tags /etc/resolv.conf file looks almost ready. Such changes should require a new release; take into account the development of glibc conservative nature, it may be too late to join in February is expected to release the 2.23 version. So there will not be glibc temporarily higher security DNSSEC, but in this direction, there are some of the progress.
- Brief Linux commands (Linux)
- Selection sort, insertion sort, and Shell sort (Programming)
- Hadoop vs spark (Server)
- Java by Spy Memcached to cache data (Programming)
- Du and df show disk space usage inconsistent Causes and Treatment (Linux)
- Manually compile Hadoop 2.6.0 under Ubuntu 14.04 (Server)
- Getting the Linux shell flow control statements (Programming)
- Java implementation chain store binary search tree (recursive method) (Programming)
- Ubuntu FAQ solutions (Linux)
- Install MATE desktop environment adjustment tools Mate Tweak 3.3.6 (Linux)
- Java semaphores (Programming)
- Configuring a Linux operating system security management services Explain (Linux)
- OpenSSL for secure transmission and use of skills of files between Windows and Linux (Linux)
- Java string intern constant pool resolution Introduction (Programming)
- Oracle Data Pump Example (Database)
- shell script: LVS start simple script (Server)
- Linux boot the system does not display a progress bar setting method (Linux)
- Hibernate learning introductory tutorial (Programming)
- Disk partition MBR (Linux)
- impdp error ORA-31631, ORA-39122 (Database)
  CopyRight 2002-2022 newfreesoft.com, All Rights Reserved.