RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2121839 - ipv6 ANY queries are taking too long
Summary: ipv6 ANY queries are taking too long
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnsmasq
Version: 8.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Petr Menšík
QA Contact: rhel-cs-infra-services-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-08-26 18:56 UTC by Alex Krzos
Modified: 2022-11-11 14:49 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-11 14:49:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-132496 0 None None None 2022-08-26 19:06:15 UTC

Description Alex Krzos 2022-08-26 18:56:15 UTC 
Description of problem:
Running dnsmasq to answer dns requests in a disconnected ipv6 environment, ANY requests hang for upwards of 7s.


Version-Release number of selected component (if applicable):
RHEL 8.6 4.18.0-372.9.1.el8.x86_64
Dnsmasq version 2.79 

How reproducible:
Always in this testbed

Steps to Reproduce:
# time dig +short @fc00:1001::1 ANY e38-h03-000-r650.rdu2.scalelab.redhat.com                                                                       
fc00:1001::1

real    0m7.698s
user    0m0.003s
sys     0m0.004s

For comparison an ipv6 query is super fast:
# time dig +short @fc00:1001::1 AAAA e38-h03-000-r650.rdu2.scalelab.redhat.com
fc00:1001::1                                               
                                                          
real    0m0.008s                                                                                                                                                                             
user    0m0.003s
sys     0m0.004s


Actual results:
The lagging request will actually block other dns requests to the point I can see the recv-q grow on the dnsmasq process via netstat:


# netstat -tulpn                                                    
Active Internet connections (only servers)                                                     
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
....
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      3038113/dnsmasq
tcp6       0      0 :::53                   :::*                    LISTEN      3038113/dnsmasq
udp        0      0 0.0.0.0:53              0.0.0.0:*                           3038113/dnsmasq
udp6    6144      0 :::53                   :::*                                3038113/dnsmasq



Expected results:
The request to be answered quickly

Additional info:
Comment 2 Petr Menšík 2022-11-11 14:49:05 UTC 
The configuration reported uses similar entries to provide all records:

address=/api.domain00620.example.net/fc00:1001::653
address=/apps.domain00620.example.net/fc00:1001::653

I think the primary reason for delays is forwarding A queries further, where it does not respond with negative response immediately.

I think there are two problems.

1) those records should be ideally in separate (sub)zone, for which the dnsmasq would be authoritative. It might then use auth-zone or at least local=/example.net/, which would prevent forwarding for any named under example.net. If such address were not defined, then it does not exist. Default mode in dnsmasq makes it possible to serve one record for some name, but for other records of the same name to forward it to upstream servers. More mature implementations cannot do it like this and either forward or serve a zone. But never both.

2) It would be possible to add additional local records for each name. That is less efficient, because dnsmasq has to check much more records. But would produce desired results even when there is not common subzone, which can have just single entry. 

# generate for each name similar record in addition to address= entries.
local=/api.domain00620.example.net/
local=/apps.domain00620.example.net/

I think this is just configuration issue in dnsmasq. There is clearly some timeout in forwarding it further. If dnsmasq had not any forwarders configured, it would respond with REFUSED. There should be some authoritative server, which would say NXDOMAIN for those records. Because it does not work well, there is timeout. That is just configuration issue, therefore I am closing this bug. Reopen if any proposed solution does not for you.
Note You need to log in before you can comment on or make changes to this bug.