Apparently linux resolver can not resolve chained CNAME where one of the CNAME is using a wildcard / *. Or more precisely when a CNAME links to a * (star) CNAME that then resolv as a wildcard domain that links to another CNAME... (more clear in the example below) This behavior affects all the latest linux version I tested (CentOS 5.5 / Ubuntu) Reproduce the error : run dig to resolve a chained cname record : > dig @8.8.8.8 messenger.live.com > ... > ;; ANSWER SECTION: > messenger.live.com. 2343 IN CNAME get.live.com. > get.live.com. 3538 IN CNAME *.live.com. > *.live.com. 3538 IN CNAME rds.live.com.nsatc.net. > rds.live.com.nsatc.net. 103 IN A 65.55.60.123 Can not resolve messenger.live.com : > ping messenger.live.com > ping: unknown host messenger.live.com Resolving get.live.com is not working either. But using the wildcard domain is working : > ping random-domain.live.com > PING rds.live.com.nsatc.net (65.55.60.123) 56(84) bytes of data.
Quick discussion over IRC - with some of the extra tests performed ----------------------- [10:25pm] grawity: There are two separate rules for host names. [10:26pm] grawity: One is the DNS protocol: everything is allowed, except for null byte. * is an ordinary character. [10:26pm] grawity: (That's how Freenode cloaks could be spoofed; "/" is valid.) [10:26pm] grawity: The other is "hostnames" - those that point to actual machines. They are limited to A-Z a-z 0-9 and - _ [10:27pm] grawity: Since the function is called gethostbyname(), there's a chance it checks for the latter... [10:28pm] grawity: (Although I doubt it. gethostbyname() shouldn't even check immediate results, only final one) [10:28pm] balou_fr: ooh - so getting a * as a reply to a DNS request would be considered as invalid - since only a-zA-Z0-9_- are awaitend [10:29pm] grawity: actually, requesting * [10:29pm] grawity: But that's where I get confused. gethostbyname() does not request "*.live.com". [10:29pm] grawity: Microsoft's DNS server does the job of following CNAMEs. [10:31pm] balou_fr: it only appears to affect linux server - macos do not have this issue (didnt tested windows - none accessible) [10:32pm] balou_fr: well - it should request *.live.com -- it d fail but that s one of the issue of the Cnames [10:32pm] grawity: dig "*.live.com" [10:33pm] balou_fr: it does work [10:33pm] balou_fr: ;; ANSWER SECTION: [10:33pm] balou_fr: *.live.com.649INCNAMErds.live.com.nsatc.net. [10:33pm] balou_fr: rds.live.com.nsatc.net.132INA65.55.206.154 [10:33pm] grawity: Notice how both the CNAME and its target are under 'ANSWER' [10:33pm] balou_fr: but dig is pure DNS protocol [10:33pm] grawity: libc _shouldn't need_ to follow CNAMES -- it's alrady done by DNS server. [10:36pm] grawity: Testing 'dig chat.freenode.net' which is a CNAME: [10:36pm] grawity: 1.323094 snow.home -> fog.home DNS Standard query A irc.freenode.net [10:36pm] grawity: 1.425244 fog.home -> snow.home DNS Standard query response CNAME chat.freenode.net A 216.155.130.130 A 216.165.191.52 A 78.40.125.4 A 82.96.64.4 A 86.65.39.15 A 128.237.157.136 A 130.237.188.200 A 140.211.166.3 A 140.211.166.4 A 174.143.119.91 A 208.71.169.36 A 213.92.8.4 A 213.161.196.11 A 213.179.58.83 A 213.232.93.3 [10:37pm] balou_fr: non it s not - tcpdump show only 1 round trip [10:38pm] balou_fr: with all the CNAMEs in the reply [10:38pm] grawity: Testing with what - dig or...? [10:38pm] balou_fr: tcpdump on a terminal - ping (with failure) on another [10:40pm] grawity: Now just to make sure, I tested with the problematic domain [10:40pm] grawity: 88.389299 snow.home -> fog.home DNS Standard query A messenger.live.com [10:40pm] grawity: 88.489966 fog.home -> snow.home DNS Standard query response CNAME get.live.com CNAME *.live.com CNAME rds.live.com.nsatc.net A 65.55.60.123 [10:40pm] grawity: And now I really don't know why libc fails on it [10:40pm] grawity: Eh, they should react on that report soon. [10:43pm] balou_fr: also - do u mind if I attach part of this discussion in the Bug report ? [10:43pm] balou_fr: (filtered to only the relevant talk of course) [10:43pm] grawity: Sure.
c.f. http://www.cygwin.com/ml/libc-hacker/2010-10/msg00014.html
I wonder why this bug never got much attention in 5 years. $ dig mint.lc.intuit.com ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> mint.lc.intuit.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26611 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mint.lc.intuit.com. IN A ;; ANSWER SECTION: mint.lc.intuit.com. 299 IN CNAME app.shared-prod.lc.a.intuit.com. app.shared-prod.lc.a.intuit.com. 59 IN CNAME *.pod-2-prod-2.lc-shared-production.lc.a.intuit.com. *.pod-2-prod-2.lc-shared-production.lc.a.intuit.com. 59 IN CNAME lc-pod-2-prod-elb-1kic5vmf4eodj-1038427872.us-west-2.elb.amazonaws.com. lc-pod-2-prod-elb-1kic5vmf4eodj-1038427872.us-west-2.elb.amazonaws.com. 59 IN A 52.35.237.236 lc-pod-2-prod-elb-1kic5vmf4eodj-1038427872.us-west-2.elb.amazonaws.com. 59 IN A 52.35.104.45 lc-pod-2-prod-elb-1kic5vmf4eodj-1038427872.us-west-2.elb.amazonaws.com. 59 IN A 52.10.3.222 ;; Query time: 157 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jan 08 08:17:01 CST 2016 ;; MSG SIZE rcvd: 261 $ ping mint.lc.intuit.com ping: unknown host mint.lc.intuit.com
RFC 1034 is ambiguous whether this allowed or not. These are simply syntactically invalid labels. Wildcards are transmitted over the wire because they are a zone file concept. They are not expanded on the RHS of a CNAME record, which is why you see the “*” label here. I'm not sure if it is a good idea to remove the restriction entirely because aliases could now contain shell metacharacters. We could drop them from the return response and no longer fail the query, though.
imo if DNS resolvers does not fail this kind of wildcard recursive query, the client should not fail it either. What are the current restrictions (I am unable to find out where they are documented) on received dns response?
(In reply to Yang Yu from comment #5) > imo if DNS resolvers does not fail this kind of wildcard recursive query, > the client should not fail it either. I agree that failing the query is unnecessary. Not extracting syntactically questionable aliases should be sufficient. > What are the current restrictions (I > am unable to find out where they are documented) on received dns response? glibc follows the syntactical requirements of RFC 1123: http://tools.ietf.org/html/rfc1123#page-13 extended with support for underscores in 1998. The relevant function is res_hnok in resolv/res_comp.c.
(In reply to Florian Weimer from comment #6) > glibc follows the syntactical requirements of RFC 1123: > > http://tools.ietf.org/html/rfc1123#page-13 > > extended with support for underscores in 1998. rfc 4592 "The Role of Wildcards in the Domain Name System" (from 2006) needs to be considered. I found this issue when investigating lookup failures on the name 3d06bae3-cff4-43c6-825d-96175822a583.um.outlook.com. DNS is returning a valid response: Answers 3d06bae3-cff4-43c6-825d-96175822a583.um.outlook.com: type CNAME, class IN, cname *.um.outlook.com .glbdns2.microsoft.com Name: 3d06bae3-cff4-43c6-825d-96175822a583.um.outlook.com Type: CNAME (Canonical NAME for an alias) (5) Class: IN (0x0001) Time to live: 297 Data length: 37 CNAME: *.um.outlook.com.glbdns2.microsoft.com *.um.outlook.com.glbdns2.microsoft.com: type CNAME, class IN, cname wildcard-namnorth.um.outlook.com Name: *.um.outlook.com.glbdns2.microsoft.com Type: CNAME (Canonical NAME for an alias) (5) Class: IN (0x0001) Time to live: 300 Data length: 20 CNAME: wildcard-namnorth.um.outlook.com wildcard-namnorth.um.outlook.com: type A, class IN, addr 65.55.94.57 Name: wildcard-namnorth.um.outlook.com Type: A (Host Address) (1) Class: IN (0x0001) Time to live: 300 Data length: 4 Address: 65.55.94.57 (65.55.94.57) wildcard-namnorth.um.outlook.com: type A, class IN, addr 207.46.198.124 Name: wildcard-namnorth.um.outlook.com Type: A (Host Address) (1) Class: IN (0x0001) Time to live: 300 Data length: 4 Address: 207.46.198.124 (207.46.198.124) which glibc is discarding/ignoring.
(In reply to Yang Yu from comment #3) > I wonder why this bug never got much attention in 5 years. I wonder that too. Especially when someone from redhat.com provided a patch in 2010. And especially when big name providers such as amazon and microsoft are regularly using wildcard cnames in their infrastructure. Florian, can this be expedited please?
See also: https://en.wikipedia.org/wiki/Wildcard_DNS_record
See also: https://groups.google.com/forum/#!topic/comp.protocols.dns.bind/bVSyx6oLiAA
(In reply to Charlie Brady from comment #7) > (In reply to Florian Weimer from comment #6) > > > glibc follows the syntactical requirements of RFC 1123: > > > > http://tools.ietf.org/html/rfc1123#page-13 > > > > extended with support for underscores in 1998. > > rfc 4592 "The Role of Wildcards in the Domain Name System" (from 2006) needs > to be considered. Not really. I'll try to explain why, but this is somewhat tricky. Technically, no wildcard is involved here, because that's not a DNS feature which is visible on the interface between authoritative server and recursor. > I found this issue when investigating lookup failures on the name > 3d06bae3-cff4-43c6-825d-96175822a583.um.outlook.com. > > DNS is returning a valid response: > > Answers > 3d06bae3-cff4-43c6-825d-96175822a583.um.outlook.com: type CNAME, > class IN, cname *.um.outlook.com > .glbdns2.microsoft.com > Name: 3d06bae3-cff4-43c6-825d-96175822a583.um.outlook.com > Type: CNAME (Canonical NAME for an alias) (5) > Class: IN (0x0001) > Time to live: 297 > Data length: 37 > CNAME: *.um.outlook.com.glbdns2.microsoft.com That's the questionable bit. Wildcards cannot be used on the right hand side of a CNAME record because the server will not expand them. In this position, “*” is just a label label like any other which is not It happens to work without host name checks because “*” as a label is matched by the wildcard: > *.um.outlook.com.glbdns2.microsoft.com: type CNAME, class IN, cname > wildcard-namnorth.um.outlook.com > Name: *.um.outlook.com.glbdns2.microsoft.com > Type: CNAME (Canonical NAME for an alias) (5) > Class: IN (0x0001) > Time to live: 300 > Data length: 20 > CNAME: wildcard-namnorth.um.outlook.com “*” is both a valid DNS label (but not for host names), and used (in a form of in-band signaling) to mark DNS records for wildcard processing (on the left-hand side). But on the DNS query interface, you never see “*” in its wildcard role, it's always a regular label. > https://groups.google.com/forum/#!topic/comp.protocols.dns.bind/bVSyx6oLiAA The conclusion of this thread seems to be that the current glibc behavior is correct. I disagree to some extent; I think we should accept such responses and extract address information from them (but not all alias information).
(In reply to Florian Weimer from comment #11) > > https://groups.google.com/forum/#!topic/comp.protocols.dns.bind/bVSyx6oLiAA > > The conclusion of this thread seems to be that the current glibc behavior is > correct. I disagree to some extent; I think we should accept such responses > and extract address information from them (but not all alias information). I disagree also - glibc is broken - it is discarding completed successful DNS lookups. The resolver follows the CNAME chain to A records. This is a major interoperability problem. People are saying to me "Windows is working, linux is broken".
(In reply to Florian Weimer from comment #6) > I agree that failing the query is unnecessary. OK. So let's fix that. Notice that the patch supplied here (so long ago): http://www.cygwin.com/ml/libc-hacker/2010-10/msg00014.html is called "Don't require DNS labels to be host names". Requiring DNS labels to be hostnames is the bug, right? And it is still a problem.
Patches posted: [PATCH 00/13] nss_dns: Fix handling of non-host CNAMEs (bug 12154) https://sourceware.org/pipermail/libc-alpha/2022-August/141338.html
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d101d836e7e4bd1d4e4972b0e0bd0a55c9b650fa commit d101d836e7e4bd1d4e4972b0e0bd0a55c9b650fa Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: Rewrite getanswer_r to match getanswer_ptr (bug 12154, bug 29305) Allocate the pointer arrays only at the end, when their sizes are known. This addresses bug 29305. Skip over invalid names instead of failing lookups. This partially fixes bug 12154 (for gethostbyname, fixing getaddrinfo requires different changes). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=32b599ac8c21c4c332cc3900a792a1395bca79c7 commit 32b599ac8c21c4c332cc3900a792a1395bca79c7 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: In gaih_getanswer_slice, skip strange aliases (bug 12154) If the name is not a host name, skip adding it to the result, instead of reporting query failure. This fixes bug 12154 for getaddrinfo. This commit still keeps the old parsing code, and only adjusts when a host name is copied. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Fixed for glibc 2.37.
:') Thanks guys!
The release/2.36/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=78c8ef21fa54e994451d5b42ead6080d99a88a49 commit 78c8ef21fa54e994451d5b42ead6080d99a88a49 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: Rewrite getanswer_r to match getanswer_ptr (bug 12154, bug 29305) Allocate the pointer arrays only at the end, when their sizes are known. This addresses bug 29305. Skip over invalid names instead of failing lookups. This partially fixes bug 12154 (for gethostbyname, fixing getaddrinfo requires different changes). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit d101d836e7e4bd1d4e4972b0e0bd0a55c9b650fa)
The release/2.36/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7a236dc44a22dc4252e803d1ee1d3b970ec43805 commit 7a236dc44a22dc4252e803d1ee1d3b970ec43805 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: In gaih_getanswer_slice, skip strange aliases (bug 12154) If the name is not a host name, skip adding it to the result, instead of reporting query failure. This fixes bug 12154 for getaddrinfo. This commit still keeps the old parsing code, and only adjusts when a host name is copied. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 32b599ac8c21c4c332cc3900a792a1395bca79c7)
The release/2.36/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5d885617cec5713fdde42177398fe98acb66b7a2 commit 5d885617cec5713fdde42177398fe98acb66b7a2 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Sep 13 13:22:27 2022 +0200 NEWS: Note bug 12154 and bug 29305 as fixed
The release/2.35/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ee74c14325a1d6577dd55cc314832d684ddecf68 commit ee74c14325a1d6577dd55cc314832d684ddecf68 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: Rewrite getanswer_r to match getanswer_ptr (bug 12154, bug 29305) Allocate the pointer arrays only at the end, when their sizes are known. This addresses bug 29305. Skip over invalid names instead of failing lookups. This partially fixes bug 12154 (for gethostbyname, fixing getaddrinfo requires different changes). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit d101d836e7e4bd1d4e4972b0e0bd0a55c9b650fa)
The release/2.35/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=519e1b025113c338852933d71acfc9d163658cfe commit 519e1b025113c338852933d71acfc9d163658cfe Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: In gaih_getanswer_slice, skip strange aliases (bug 12154) If the name is not a host name, skip adding it to the result, instead of reporting query failure. This fixes bug 12154 for getaddrinfo. This commit still keeps the old parsing code, and only adjusts when a host name is copied. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 32b599ac8c21c4c332cc3900a792a1395bca79c7)
The release/2.34/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9abc40d9b514fc51cd1a052d32d092a827c6e21a commit 9abc40d9b514fc51cd1a052d32d092a827c6e21a Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: Rewrite getanswer_r to match getanswer_ptr (bug 12154, bug 29305) Allocate the pointer arrays only at the end, when their sizes are known. This addresses bug 29305. Skip over invalid names instead of failing lookups. This partially fixes bug 12154 (for gethostbyname, fixing getaddrinfo requires different changes). Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit d101d836e7e4bd1d4e4972b0e0bd0a55c9b650fa)
The release/2.34/master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c36e7cca3571b0c92b09409c1df86a142596c210 commit c36e7cca3571b0c92b09409c1df86a142596c210 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Aug 30 10:02:49 2022 +0200 nss_dns: In gaih_getanswer_slice, skip strange aliases (bug 12154) If the name is not a host name, skip adding it to the result, instead of reporting query failure. This fixes bug 12154 for getaddrinfo. This commit still keeps the old parsing code, and only adjusts when a host name is copied. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> (cherry picked from commit 32b599ac8c21c4c332cc3900a792a1395bca79c7)
*** Bug 31413 has been marked as a duplicate of this bug. ***