Bug 2014019
Summary: | dnsmasq-2.86-2.fc34.x86_64 breaks kinit | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Viktor Ashirov <vashirov> | ||||
Component: | dnsmasq | Assignee: | Petr Menšík <pemensik> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 34 | CC: | aegorenk, akostadi, code, dns-sig, dougsland, fweimer, laine, pemensik, veillard | ||||
Target Milestone: | --- | Keywords: | Regression, Triaged | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | dnsmasq-2.86-3.fc36 dnsmasq-2.86-3.fc35 dnsmasq-2.86-3.fc34 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2021-10-31 01:08:43 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Viktor Ashirov
2021-10-14 09:48:02 UTC
I've reproduced this on a clean F34 install with the latest updates. systemd-resolved has to be disabled: $ systemctl disable --now systemd-resolved And NetworkManager uses dnsmasq: $ cat /etc/NetworkManager/conf.d/50-dns.conf [main] dns=dnsmasq It seems that the problematic patch is this one https://src.fedoraproject.org/rpms/dnsmasq/blob/rawhide/f/dnsmasq-2.86-domain-match-local.patch I did a mockbuild without it and dnsmasq now returns entries when an uppercase domain is used. Here's a copr build that has the patch above commented out: https://copr.fedorainfracloud.org/coprs/vashirov/dnsmasq-bz2014019/ I tested it on my second laptop and confirm kinit *@REDHAT.COM on our VPN does not work as it should. But it does not seem to be better even with dnsmasq-2.86-1.fc34.x86_64, where patch mentioned in comment #2 were not yet present. Their behavior is different, but both seems to be broken. According to log-queries output, it mangles case of sent query to lowercase. Then it sends it to redhat.com domain specific resolvers. It seems though reply from them is NOT accepted because of mismatching case. Then there is a new regression, it sends redhat.com query to normal nameservers without domain specified. This time without mangled case, which makes these queries successful. But public resolvers does not know internal kerberos servers, so the response is NXDOMAIN. Which makes three problems: 1) original query is mangled to lower case. It would not be usually a problem, but it would break 0x20 bit randomization [1]. Not important. 2) reply with mangled case name is not accepted as a valid response. This is important. 3) non-domain specific resolvers are tried on domain, which has domain-specific resolvers defined. This means privacy issue regression. It did not leak domain specific before. [1] https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00 Reported upstream in thread: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015854.html Even latest 2.87test4 prerelease has still the same issue. Tested my build at COPR, with log-queries added to /etc/NetworkManager/dnsmasq.d/log.conf https://copr.fedorainfracloud.org/coprs/pemensik/dnsmasq/ Oh, I think have I missed important detail. Our dig +tcp SRV _kerberos-master._tcp.*.REDHAT.COM gives response of size 1454. Because kinit does not use EDNS0 extension, it receives truncated UDP packet. TCP request is retried, that is a reason for changed PID in log. But that TCP query selects WRONG server to query. It receives different response than it would via UDP, because different server is queried. TCP query result is NXDOMAIN, because that name is not defined on public internet. Primary issue is therefore TCP query selects server different way than UDP would. Found simple way to reproduce it: dnsmasq -d --conf-file=/dev/null --port 2053 --server=127.0.0.1 --no-resolv --server='/test/::1' --log-queries & dig +tcp @localhost -p 2053 srv _tcp.TEST dig @localhost -p 2053 srv _udp.TEST Results in log: dnsmasq: started, version 2.87test4-11-g80fae3c cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile dnsmasq: using nameserver 127.0.0.1#53 dnsmasq: using nameserver ::1#53 for domain test dnsmasq: read /etc/hosts - 16 addresses dnsmasq: query[SRV] _udp.TEST from ::1 dnsmasq: forwarded _udp.test to ::1 dnsmasq: reply _udp.TEST is NXDOMAIN dnsmasq: query[SRV] _tcp.TEST from ::1 dnsmasq: forwarded _tcp.TEST to ::1 dnsmasq: reply _tcp.TEST is NXDOMAIN Note forwarded name differs in case, UDP is forwarded lowercase. But TCP query is forwarded as received without modified case. It then requires case insensitive comparison strcasecmp in order() function in domain-match.c, where strcmp is used now. Without a patch, previous version would forward it to 127.0.0.1. Created attachment 1833100 [details]
candidate-patch
Hi folks! Is this the same issue: $ KRB5_TRACE=/dev/stdout kinit -V dtantsur.COM ... [2508625] 1635256242.418026: Response was from primary KDC [2508625] 1635256242.418027: Received error from KDC: -1765328359/Additional pre-authentication required [2508625] 1635256242.418030: Preauthenticating using KDC method data [2508625] 1635256242.418031: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136), PA-PKINIT-KX (147), PA-FX-COOKIE (133) [2508625] 1635256242.418032: Received cookie: MIT [2508625] 1635256242.418033: PKINIT client has no configured identity; giving up [2508625] 1635256242.418034: Preauth module pkinit (147) (info) returned: 0/Success [2508625] 1635256242.418035: PKINIT client has no configured identity; giving up [2508625] 1635256242.418036: Preauth module pkinit (16) (real) returned: 22/Invalid argument kinit: Pre-authentication failed: Invalid argument while getting initial credentials There seem to be DNS records above that, so maybe it's another problem? FEDORA-2021-bfb01154ce has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-bfb01154ce FEDORA-2021-83554ef1c7 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-83554ef1c7 FEDORA-2021-bfb01154ce has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-bfb01154ce` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-bfb01154ce See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. (In reply to Dmitry Tantsur from comment #11) > Hi folks! Is this the same issue: > > $ KRB5_TRACE=/dev/stdout kinit -V dtantsur.COM > ... > [2508625] 1635256242.418026: Response was from primary KDC > [2508625] 1635256242.418027: Received error from KDC: -1765328359/Additional > pre-authentication required > [2508625] 1635256242.418030: Preauthenticating using KDC method data > [2508625] 1635256242.418031: Processing preauth types: PA-PK-AS-REQ (16), > PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136), PA-PKINIT-KX > (147), PA-FX-COOKIE (133) > [2508625] 1635256242.418032: Received cookie: MIT > [2508625] 1635256242.418033: PKINIT client has no configured identity; > giving up > [2508625] 1635256242.418034: Preauth module pkinit (147) (info) returned: > 0/Success > [2508625] 1635256242.418035: PKINIT client has no configured identity; > giving up > [2508625] 1635256242.418036: Preauth module pkinit (16) (real) returned: > 22/Invalid argument > kinit: Pre-authentication failed: Invalid argument while getting initial > credentials > > There seem to be DNS records above that, so maybe it's another problem? It seems this is different error. This bug is only about inability to find master server. If kerberos fail in pre-authentication, if is already past this test. This error would report Cannot find KDC for realm "IPA.REDHAT.COM", stopping before it. I only guess some parameters or password are wrong. FEDORA-2021-83554ef1c7 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-83554ef1c7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-83554ef1c7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-bfb01154ce has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. Wrorks for me, thanks! FEDORA-2021-83554ef1c7 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. |