Bug 1027452 - [RFE] Provide mechanism to disable AAAA queries when using AF_UNSPEC on IPv4-only configurations. [NEEDINFO]
[RFE] Provide mechanism to disable AAAA queries when using AF_UNSPEC on IPv4-...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc (Show other bugs)
Unspecified Unspecified
high Severity high
: rc
: 7.6
Assigned To: glibc team
: FutureFeature, Reopened
Depends On:
Blocks: 1477664
  Show dependency treegraph
Reported: 2013-11-06 16:27 EST by Michal Bruncko
Modified: 2018-05-27 11:35 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-06-22 13:58:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rfreire: needinfo? (fweimer)
rfreire: needinfo? (codonell)

Attachments (Terms of Use)
Strace for telnet command (19.25 KB, text/plain)
2013-11-11 09:49 EST, Michal Bruncko
no flags Details
Packet capture from telnet command (1.68 KB, application/octet-stream)
2013-11-11 09:52 EST, Michal Bruncko
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 15863 None None None 2017-08-28 16:49 EDT

  None (edit)
Description Michal Bruncko 2013-11-06 16:27:34 EST
Description of problem:
Maybe this is stupid question and this bug will be closed immediately, but I need to ask/report. My system is completely IPv6 disabled* (I have no IPv6 address assigned to any NW interface at all). Why the resolver all the time requesting AAAA records? It seems that IPv6 address will not be used as the IPv6 is completely disabled. Is there any reason for that? 

in /etc/sysctl.conf  :  net.ipv6.conf.all.disable_ipv6 = 1
in /etc/sysconfig/network  : NETWORKING_IPV6=no
in /etc/sysconfig/network-scripts/ifcfg-eth0 : IPV6INIT=”no”

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. disable IPv6 completely within system
2. try to resolve any DNS name (or simply use ping toward some DNS name)

Actual results:
resolver will ask for both A and AAAA records

Expected results:
resolver will ask for both A record only

Additional info:
Yes, I understand that IPv6 is the feature protocol and soon or later will replace IPv4 completely. I personally implemented and use IPv6 in one organziation and I am happy with it. Please consider this report as pure explanational for me and for all other people with same question.
Comment 2 Carlos O'Donell 2013-11-07 22:33:21 EST
Thanks for the report. Which application is making the request, and how did you determine that it was the glibc resolver that made the request? Can you provide a step-by-step set of actions to reproduce the issue including any tcpdump logs?
Comment 3 Michal Bruncko 2013-11-11 09:46:32 EST
The original problem was that the webpage "www.shellcardonline.shell.com" was not reachable via Squid proxy server - the loading stucked on "https://www.shellcardonline.shell.com/authenticateusertoken.aspx". When the computer reach the site directly without proxy. So I started to investigate why this happen and I found, that AAAA name resolution is timing out for "www.shellcardonline.extha.shell.com" - which is CNAME of "www.shellcardonline.shell.com" and for "www-cardauth-services-prd.extha.shell.com" which is CNAME of "www.shellcardonline.extha.shell.com" (example: http://www.dnswatch.info/dns/dnslookup?la=en&host=www-cardauth-services-prd.extha.shell.com&type=AAAA&submit=Resolve).

So I have disabled IPv6 completely as this Proxy server does not have IPv6 connectivity and I hoped that AAAA requets will stop raising at all. But AAAA resolving remains same even if I disabled IPv6 on the host. 

> Which application is making the request?
It is squid (as proxy server) and telnet (wanted to replicate connection establishing). For both cases both records where requested A and AAAA. 

> how did you determine that it was the glibc resolver that made the request?
Attaching strace of telnet output. As I can see the "/lib64/libresolv.so.2" is loaded to handle DNS reqests. I think this is same for Squid process as well.
Comment 4 Michal Bruncko 2013-11-11 09:49:54 EST
Created attachment 822445 [details]
Strace for telnet command
Comment 5 Michal Bruncko 2013-11-11 09:52:41 EST
Created attachment 822446 [details]
Packet capture from telnet command

it was provided from different computer, please ignore IP address differences from previous strace output. 
As you can see here the delay between executing "telnet www.shellcardonline.shell.com 443" and getting "Connected..." response is 15 seconds.
Comment 6 Siddhesh Poyarekar 2013-11-18 04:42:56 EST
(In reply to Michal Bruncko from comment #3)
> So I have disabled IPv6 completely as this Proxy server does not have IPv6
> connectivity and I hoped that AAAA requets will stop raising at all. But
> AAAA resolving remains same even if I disabled IPv6 on the host. 

I don't think we have a mechanism in place to disable AAAA lookups in glibc via a configuration - a program that makes an AF_UNSPEC or AF_INET6 request will get IPv6 results if the nameserver supports it.  Disabling IPv6 networking is something very different - it simply disables IPv6 support in the kernel and prevents the relevant network interfaces from being created.  It does not result in disabling IPv6 name lookups.  Maybe there should be a feature request for this.  This is probably another good use case for tunables.
Comment 7 Michal Bruncko 2013-11-20 07:33:51 EST
Hi Siddesh,
yes exactly, such option ("inet4only") is missing in this situation. in current case resolver is asking for both records (==two queries) even if there are scenarios where the AAAA records are not necessary and this doubles every name resolution which also can increase delay for waiting for responses from both requests (like in reported example). 
and this is what I have tried to discuss here. this option will not be "feature", but desired option for "legacy" servers on IPv4 networks only.
Comment 11 Carlos O'Donell 2014-06-04 00:30:42 EDT
Unfortunately the solution we were expecting to use to solve this issue has been shown to violate the POSIX standard wording for getaddrinfo. Therefore we have had to change the implementation plan. That places this solution outside the scope of rhel-6.6. I have moved this bug to rhel-6.7. In the meantime we will be working on an upstream solution to attempt to provide a glibc tunnable to completely disable the ipv6 queries (orthogonal to the usage of AI_ADDRCONFIG). Such a tunable could be used to prevent AAAA queries from being issued by the glibc stub resolver when AF_UNSPEC queries are made, regardless of the state of the interfaces.
Comment 13 ozzzo 2016-06-04 22:41:48 EDT
Was this bug ever fixed? I am still seeing the unwanted AAAA queries in Centos 6.7 and 7.2 even after disabling ipv6.
Comment 14 Carlos O'Donell 2016-06-06 11:08:05 EDT
(In reply to ozzzo from comment #13)
> Was this bug ever fixed? I am still seeing the unwanted AAAA queries in
> Centos 6.7 and 7.2 even after disabling ipv6.

Thank you for your inquiry. This bug is not fixed in upstream, and is not fixed in RHEL6 or RHEL7 yet.
Comment 15 Chris Williams 2016-08-08 17:19:11 EDT
When Red Hat shipped 6.8 on May 10, 2016 RHEL 6 entered Production Phase 2. 
That means only "Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released"
That also means no new RFEs so this BZ is being moved to RHEL 7 which is still in Production Phase 1.
Comment 18 Rodrigo A B Freire 2017-08-28 16:43:47 EDT
1. Proposed title of this feature request
  * [RFE] glibc: implement GAI modifier for AAAA? DNS queries

2. Who is the customer behind the request?
Account name: Confidential
SRM customer: Confidential
TAM customer: Confidential
Strategic Customer: Confidential
3. What is the nature and description of the request?
  * Currently, in order to be fully adherent with RFC 2553, getaddrinfo() performs both a AAAA (IPv6 address query) query and a A (IPv4 address query) query to its DNS server.
  * getaddrinfo() is full-blocking, meaning: the getaddrinfo() function will not return before it gets either a reply or a timeout for each of the A and AAAA queries.
  * This request aims to add a new glibc functionality, mitigating potential problem scenarios where the RFC 2553 adherence cause problems.
4. Why does the customer need this? (List the business requirements here)
  * There are scenarios where in a AAAA lookup is not wanted / desired and may cause problems. For example:
    - IPv6 stack for local-only traffic
      In this scenario, the client would be connecting to sites that resolves AAAA addresses, but that is not desired
    - DNS servers that does not replies AAAA queries
      In this scenario, we have long getaddrinfo() calls, that returns only after the resolver timeout.  
  * There might exist other non-envisioned scenarios here, benefitting them all.

5. How would the customer like to achieve this? (List the functional requirements here)
  * We would suggest adding a configuration clause to /etc/gai.conf. This flag would change getaddrinfo() behavior and if present, would NOT perform the AAAA queries.

6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
  * getaddrinfo() resolves BY DEFAULT both A and AAAA for a host name
  * IF present /etc/gai.conf and getaddrinfo() AAAA modifier clause ; THEN
    * DO NOT try AAAA name resolution
  * FI

7. Is there already an existing RFE upstream or in Red Hat bugzilla?
  * None known.

8. Does the customer have any specific timeline dependencies?
  * Desirable: RHEL 7.6
9. Is the sales team involved in this request and do they have any additional input?
  * No Sales knowledge.

10. List any affected packages or components.
  * glibc

11. Would the customer be able to assist in testing this functionality if implemented?
  * Yes.

Note You need to log in before you can comment on or make changes to this bug.