Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
- The issue is observed on `aardvark-dns` package version 1.0.1-35, that no matter what QTYPE is specified in DNS request, it always returns both A and AAAA records.
Version-Release number of selected component (if applicable):
- aardvark-dns-1.0.1-35
How reproducible:
- 100%
Steps to Reproduce:
1. # Configuration
## Dual stack network
{
"name": "dual",
"id": "2697203bf4180da9e7a6d074e38cbafb2fad4c8a3436522bde4ac573c059caa6",
"driver": "bridge",
"network_interface": "podman1",
"created": "2022-08-24T04:03:37.236675178-05:00",
"subnets": [
{
"subnet": "192.168.227.0/24",
"gateway": "192.168.227.1"
},
{
"subnet": "fdf8:192:168:227::/120",
"gateway": "fdf8:192:168:227::1"
}
],
"ipv6_enabled": true,
"internal": false,
"dns_enabled": true,
"ipam_options": {
"driver": "host-local"
}
}
2.
## Two containers, foo and bar, both running Nginx, by following configuration, Nginx in foo forwards request to Nginx in bar.
location /bar {
resolver 192.168.227.1;
set $upstream bar.dns.podman;
proxy_pass http://$upstream;
}
# Issue observed
## The web request fails with 502 error.
[root@foo /]# curl -vvv http://localhost/bar
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 80 (#0)
> GET /bar HTTP/1.1
> Host: localhost
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 502 Bad Gateway
## It's because Nginx fails to resolve hostname of "bar.dns.podman".
We can see Nginx error.log is filled up with plenty of the following errors:
2022/08/26 09:54:58 [error] 88#0: unexpected AAAA record in DNS response
2022/08/26 09:54:58 [error] 88#0: unexpected A record in DNS response
3. nslookup A and AAAA record and observe
Actual results:
## The root cause is because aardvark-dns always returns both A and AAAA records no matter what QTYPE is specified in DNS request.
[root@foo /]# nslookup -type=A bar 192.168.227.1
Server: 192.168.227.1
Address: 192.168.227.1#53
Non-authoritative answer:
Name: bar.dns.podman
Address: 192.168.227.5
Name: bar.dns.podman
Address: fdf8:192:168:227::5
[root@foo /]# nslookup -type=AAAA bar 192.168.227.1
Server: 192.168.227.1
Address: 192.168.227.1#53
Non-authoritative answer:
Name: bar.dns.podman
Address: 192.168.227.5
Name: bar.dns.podman
Address: fdf8:192:168:227::5
[root@foo /]# nslookup bar 192.168.227.1
Server: 192.168.227.1
Address: 192.168.227.1#53
Non-authoritative answer:
Name: bar.dns.podman
Address: 192.168.227.5
Name: bar.dns.podman
Address: fdf8:192:168:227::5
Name: bar.dns.podman
Address: 192.168.227.5
Name: bar.dns.podman
Address: fdf8:192:168:227::5
Expected results:
- aardvark-dns should return correct result based on QTYPE is specified in DNS request
Additional info:
- Link to original issue - https://github.com/containers/aardvark-dns/issues/203
This is being worked upon and it's almost fixed there. it's almost fixed there.
Test with aardvark-dns-1.2.0-1.module+el8.8.0+16777+b77867ec.x86_64 and it works as expected. The nslook up command inside foo can get different output for -type=A and -type=AAAA. So move this to verified:
Details:
# podman exec -it foo sh
/ # nslookup -type=AAAA bar 192.168.227.1
Server: 192.168.227.1
Address: 192.168.227.1#53
Non-authoritative answer:
Name: bar.dns.podman
Address: fdf8:192:168:227::4
/ # nslookup -type=A bar 192.168.227.1
Server: 192.168.227.1
Address: 192.168.227.1#53
Non-authoritative answer:
Name: bar.dns.podman
Address: 192.168.227.4
/ # exit
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: container-tools:rhel8 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2023:2758
Description of problem: - The issue is observed on `aardvark-dns` package version 1.0.1-35, that no matter what QTYPE is specified in DNS request, it always returns both A and AAAA records. Version-Release number of selected component (if applicable): - aardvark-dns-1.0.1-35 How reproducible: - 100% Steps to Reproduce: 1. # Configuration ## Dual stack network { "name": "dual", "id": "2697203bf4180da9e7a6d074e38cbafb2fad4c8a3436522bde4ac573c059caa6", "driver": "bridge", "network_interface": "podman1", "created": "2022-08-24T04:03:37.236675178-05:00", "subnets": [ { "subnet": "192.168.227.0/24", "gateway": "192.168.227.1" }, { "subnet": "fdf8:192:168:227::/120", "gateway": "fdf8:192:168:227::1" } ], "ipv6_enabled": true, "internal": false, "dns_enabled": true, "ipam_options": { "driver": "host-local" } } 2. ## Two containers, foo and bar, both running Nginx, by following configuration, Nginx in foo forwards request to Nginx in bar. location /bar { resolver 192.168.227.1; set $upstream bar.dns.podman; proxy_pass http://$upstream; } # Issue observed ## The web request fails with 502 error. [root@foo /]# curl -vvv http://localhost/bar * Trying ::1... * TCP_NODELAY set * Connected to localhost (::1) port 80 (#0) > GET /bar HTTP/1.1 > Host: localhost > User-Agent: curl/7.61.1 > Accept: */* > < HTTP/1.1 502 Bad Gateway ## It's because Nginx fails to resolve hostname of "bar.dns.podman". We can see Nginx error.log is filled up with plenty of the following errors: 2022/08/26 09:54:58 [error] 88#0: unexpected AAAA record in DNS response 2022/08/26 09:54:58 [error] 88#0: unexpected A record in DNS response 3. nslookup A and AAAA record and observe Actual results: ## The root cause is because aardvark-dns always returns both A and AAAA records no matter what QTYPE is specified in DNS request. [root@foo /]# nslookup -type=A bar 192.168.227.1 Server: 192.168.227.1 Address: 192.168.227.1#53 Non-authoritative answer: Name: bar.dns.podman Address: 192.168.227.5 Name: bar.dns.podman Address: fdf8:192:168:227::5 [root@foo /]# nslookup -type=AAAA bar 192.168.227.1 Server: 192.168.227.1 Address: 192.168.227.1#53 Non-authoritative answer: Name: bar.dns.podman Address: 192.168.227.5 Name: bar.dns.podman Address: fdf8:192:168:227::5 [root@foo /]# nslookup bar 192.168.227.1 Server: 192.168.227.1 Address: 192.168.227.1#53 Non-authoritative answer: Name: bar.dns.podman Address: 192.168.227.5 Name: bar.dns.podman Address: fdf8:192:168:227::5 Name: bar.dns.podman Address: 192.168.227.5 Name: bar.dns.podman Address: fdf8:192:168:227::5 Expected results: - aardvark-dns should return correct result based on QTYPE is specified in DNS request Additional info: - Link to original issue - https://github.com/containers/aardvark-dns/issues/203 This is being worked upon and it's almost fixed there. it's almost fixed there.