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 603
    • Issues 603
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 87
    • Merge requests 87
  • 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
  • #2490
Closed
Open
Issue created Feb 13, 2021 by Jim Pirzyk@pirzyk

dig +tcp does not honor +tries=1 nor +retry=0

Summary

When using dig in a test suite and the resolver closes the TCP connection early in the process, due to being rate limited or on a blocked list, dig will retry the TCP connection even though +tries=1 and +retry=0 are on the command line. I believe this is due to 14afc8425b7e034b714ebff896a9b5aab9b0fe12

BIND version used

37>dig -v
DiG 9.16.1-Ubuntu

Steps to reproduce

Setup a DNS resolver that will drop the connection after the accept() call before any data is read. In my test I have 2 queries sent right after each other. The first query should succeed (and does) and the second one should be dropped.

dig @127.0.0.1 -p 5354 +time=1 +tries=1 -b 127.0.3.15 +tcp +nokeepopen example.com example.com

What is the current bug behavior?

20210213 184035.278 T     36738 ------ 6       - accept4(fd=8, sock.sa=127.0.3.15:33601, ss_len=16, SOCK_NONBLOCK){}
20210213 184035.278 T     36738 ------ 6       - CLIENT: accept4(sockfd=8, ...): tcp open 127.0.3.15:33601, using descriptor sockfd=14
20210213 184035.280 T     36738 ------ 6       - accept4(fd=8, sock.sa=127.0.3.15:40929, ss_len=16, SOCK_NONBLOCK){}
20210213 184035.280 T     36738 ------ 6         - ratelimit_ip4_bucket[00003678=hash(ip=127.0.3.15)].counts[7].item[0]: count=2 >= limit=2; dropping query
20210213 184035.280 T     36738 ------ 6       - accept4(fd=8, sock.sa=127.0.3.15:56039, ss_len=16, SOCK_NONBLOCK){}
20210213 184035.280 T     36738 ------ 6         - ratelimit_ip4_bucket[00003678=hash(ip=127.0.3.15)].counts[7].item[0]: count=3 >= limit=2; dropping query

What is the expected correct behavior?

20210213 184035.278 T     36738 ------ 6       - accept4(fd=8, sock.sa=127.0.3.15:33601, ss_len=16, SOCK_NONBLOCK){}
20210213 184035.278 T     36738 ------ 6       - CLIENT: accept4(sockfd=8, ...): tcp open 127.0.3.15:33601, using descriptor sockfd=14
20210213 184035.280 T     36738 ------ 6       - accept4(fd=8, sock.sa=127.0.3.15:40929, ss_len=16, SOCK_NONBLOCK){}
20210213 184035.280 T     36738 ------ 6         - ratelimit_ip4_bucket[00003678=hash(ip=127.0.3.15)].counts[7].item[0]: count=2 >= limit=2; dropping query
Edited Feb 13, 2021 by Jim Pirzyk
Assignee
Assign to
Time tracking