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 604
    • Issues 604
    • 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
  • #2503
Closed
Open
Issue created Feb 19, 2021 by Ondřej Surý@ondrejOwner

New stale-answer-client-timeout crashes BIND 9.16 and 9.17

From Support ticket #17781

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f3c7bda4859 in __GI_abort () at abort.c:79
#2  0x000055cc6a31dd0a in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:261
#3  0x000055cc6a52ed20 in isc_assertion_failed (file=file@entry=0x55cc6a5a3863 "query.c", line=line@entry=6282, type=type@entry=isc_assertiontype_require, 
    cond=cond@entry=0x55cc6a5a42c0 "client->query.fetch == ((void *)0)") at assertions.c:46
#4  0x000055cc6a37ba6a in ns_query_recurse (client=0x7f3c540104c8, qtype=<optimized out>, qname=qname@entry=0x7f3c45331380, qdomain=0x7f3c453312e0, nameservers=0x7f3c45335bc8, 
    resuming=<optimized out>) at query.c:6258
#5  0x000055cc6a385e71 in query_delegation_recurse (qctx=0x7f3c721fa920) at query.c:8513
#6  query_delegation (qctx=qctx@entry=0x7f3c721fa920) at query.c:8459
#7  0x000055cc6a381f0e in query_gotanswer (qctx=qctx@entry=0x7f3c721fa920, res=res@entry=65565) at query.c:7220
#8  0x000055cc6a383e14 in query_lookup (qctx=qctx@entry=0x7f3c721fa920) at query.c:5925
#9  0x000055cc6a387e90 in query_lookup_staleonly (client=0x7f3c540104c8) at query.c:5956
#10 fetch_callback (task=<optimized out>, event=<optimized out>) at query.c:5995
#11 0x000055cc6a564131 in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1152
#12 run (queuep=<optimized out>) at task.c:1344
#13 0x00007f3c7bf8b609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#14 0x00007f3c7bea1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

The problem case here is that when we are handling a client request, and stale-answer-client-timeout is triggered, a separate stale only request is made, while the already started resolver fetch continues to wait for a response.

This is fine if there is a stale answer in cache, but if nothing is found, the stale only query will also start recursion.

Now we hit the client->query.fetch == ((void *)0) assertion.

Fix by disabling recursion on staleonly lookups.

Edited Feb 19, 2021 by Support RT
Assignee
Assign to
Time tracking