Skip to content
GitLab
Projects Groups Topics 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
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 619
    • Issues 619
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 112
    • Merge requests 112
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • 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
  • #1059

Fix TCP failure handling

There are two issues with TCP failure handling in resolver code which are somewhat intertwined yet still distinct:

  • for servers which respond to EDNS queries but never send responses larger than 512 bytes and are unavailable over TCP, named may go into a pointless query loop which is only interrupted after the fetch context restart limit is hit; this cannot really be exploited, but is harmful to broken servers,

  • TCP connection failures affect EDNS timeout statistics while EDNS mechanisms only apply to DNS over UDP.

Both of these issues are exposed by the legacy system test, but they went under the radar so far because they do not cause test failures - I only noticed something was up because I was running that test with Wireshark in the background.

Assignee
Assign to
Time tracking