Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 613
    • Issues 613
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 90
    • Merge requests 90
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #1259
Closed
Open
Issue created Oct 04, 2019 by Petr Menšík@pemensikContributor

resolv.conf search parsing has artificial limit

Summary

libirs support only 8 search domains

BIND version used

master branch

Steps to reproduce

  1. sed -i 's/^search .*/search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org openstacklocal redhat.com/' /etc/resolv.conf
  2. [ "$(host access)" == "$(getent host access.redhat.com.)" ] && echo matches
  3. sed -i 's/^search .*/search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org non-existent7.very-long-domain.fedoraproject.org non-existent8.very-long-domain.fedoraproject.org openstacklocal redhat.com/' /etc/resolv.conf
  4. [ "$(host access)" == "$(getent host access.redhat.com.)" ] && echo still matches

What is the current bug behavior?

  1. does not match

What is the expected correct behavior?

  1. does match

Relevant configuration files

# resolv.conf
search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org non-existent7.very-long-domain.fedoraproject.org non-existent8.very-long-domain.fedoraproject.org openstacklocal redhat.com
nameserver 9.9.9.9

Relevant logs and/or screenshots

(none.)

Possible fixes

I know using such high number domains would cause too many queries to resolve. I know it is a bad idea. But I think there should not be such hard limit preventing this. It was updated in glibc to accept unlimited domains. It is not good idea, but I think it is better than simply ignoring what user wishes. We have some customers hitting limits on it.

I think it should be discouraged but possible.

RH Bug for glibc, RH Bug of nslookup

Edited Oct 04, 2019 by Petr Menšík
Assignee
Assign to
Time tracking