This still occurs in Focal.
nslookup "respects the dots" as it calls the systemd resolver, and as per man
resolved.conf(5)
Domains=
A space-separated list of domains. These domains are used as search
suffixes when resolving single-label host names (domain names which contain no
dot)
** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
** Changed in: linux (Ubuntu Xenial)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/16
** Changed in: glibc (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: glibc (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1674
For some strange reason, nslookup seems to respect ndots whereas ping
does not.
With ndots:2
$ ping host.name
ping: host.name: Name or service not known
$ nslookup host.name
Server: 127.0.1.1
Address:127.0.1.1#53
Name: host.name.mycompany.com
Address: 10.174.2.192
--
You rec
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: glibc (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/16
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: glibc (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1674273
Yaketty has either broken ndots or enforced it to 1.
ndots:1
ping host => search is appended. Never tried as fqdn.
ping host.name => search is not appended, even if nxdomain
ndots:2
ping host => search is appended. Never tried as fqdn.
ping host.name => search is not appended, even if nxdomain. T
It seems like the behaviour has changed in yaketty.
- queries with fewer than ndots are only tried with search list appended, never
tried as fqdn
- queries with ndots ore more are tried as fqdn directly and search list is
never tried
However, in yaketty, ndots option seems to be completely igno
Yeah the man is quite unclear on how local domain / search list is
managed when resolving.
I thought dnsmasq was configured with caching disabled on ubuntu ?
I'm understanding your point of view but it needs some digging (is
ubuntu even patching glibc ?).
--
You received this bug notification b
Interesting. At the very least then the man page is inconsistent since
>From man resolv.conf, search option:
Resolver queries having fewer than ndots dots (default is 1) in them
will be attempted using each component of the search path in turn until
a match is found.
However, I believe the subse
I think you are not hitting any bug at all ?
According to the man, ndots has nothing to do with adding or not adding search
list to the query, it only determines if you need to try absolute request first
OR with search list first. The first non-error result is returned to the client.
resolv.conf
apport information
** Tags added: apport-collected xenial
** Description changed:
This is a re-report of
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/401202 since that
one was apparently closed as no-fix simply because it was too old.
This still occurs in xenial.
Original
I don't think this is a recent regression. I have seen the symptoms for
a while and have only gotten around to investigating it yesterday. Also
see the linked bug which describes exactly this issue and which was
raised in 2009.
However, I am inclined to believe that this is more a glibc rather tha
Did this issue start happening after an update/upgrade? Was there a
prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.11 kernel[
14 matches
Mail list logo