[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <bca0b9302a2485a52ee69d4bd7d26ecc@nixaid.com>
Date: Fri, 13 Sep 2019 07:43:28 +0000
From: "Andrey Arapov" <andrey.arapov@...aid.com>
To: musl@...ts.openwall.com
Subject: DNS FQDN query issue in musl starting 1.1.13
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I've noticed that musl C lib starting 1.1.13 isn't trying to resolve the FQDN in the first place,
it rather tries <FQDN>.<search_domain_found_in_/etc/resolv.conf_file> first which is different to how GNU
C library is working.
Also, since musl C library is "never falling back to search, which glibc would do" according to
https://wiki.musl-libc.org/functional-differences-from-glibc.html#Name-Resolver/DNS
this poses an issue when DNS server is misconfigured.
For example, when DNS server is returning SERVFAIL (no SOA), the musl C is simply stopping from
attempting the FQDN.
So having a wrong record in the /etc/resolv.conf will cause musl C resolver to break way too fast.
I was wondering whether this is an expected behavior or not? And can this be changed in a way so musl C lib is trying the FQDN first?
This behavior is making some people resort to using short hostnames instead of FQDNs, such as
ad-hoc patching ucp-metrics (Alpine based container) --
https://forums.docker.com/t/ucp-dashboard-shows-no-data/72337/4
To expand the issue with the ucp-metrics:
So when resolv.conf is set to the following configuration:
nameserver 10.96.0.10
search kube-system.svc.cluster.local svc.cluster.local cluster.local some.brokendnsserver.com
options ndots:5
An attempt to resolve the ucp-controller.kube-system.svc.cluster.local will be rendered into attempt to resolve the ucp-controller.kube-system.svc.cluster.local.some.brokendnsserver.com in the first place.
Workaround people use in the wild is: ucp-controller.kube-system.svc.cluster.local => ucp-controller
I've already informed the Docker Support about this issue, they are working on the knowledge base article regarding this issue, so people are aware of this and can decide to rather fix their domain search server (should they have an access/rights to) or resolv.conf record.
I think that this should be fixed since even having the good domain search server is making the system prone to an error should the domain search server fail (or partially fail, returning SERVFAIL/[no SOA]) at any point of time.
Please kindly Cc me on replies.
Kind Regards,
Andrey Arapov
-----BEGIN PGP SIGNATURE-----
iI8EARYIADcWIQRDMZ/b1AtG/U4LjuKQdtXmsxrpnAUCXXtIjhkcYW5kcmV5LmFy
YXBvdkBuaXhhaWQuY29tAAoJEJB21eazGumcHjMBAP5Y6ZsoVCVd2VHN+Vf09+B7
SQRPtH3O5++Vu5R5vTDdAQCABCZVzZcl3R+KuZqHX0suZY6ddfYwTjZHtzensR7u
CQ==
=CCbe
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
