Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 570
    • Issues 570
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 109
    • Merge requests 109
  • 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
  • #2528
Closed
Open
Issue created Feb 24, 2021 by Michał Kępień@michalOwner

named does not check RDATA of the SOA record ending an AXFR

While lib/dns/xfrin.c:xfr_rr() checks whether the last RR in the AXFR stream is an SOA record, it does not check its RDATA.

RFC 5936 section 2.2 says:

   An AXFR response that is transferring the zone's contents will
   consist of a series (which could be a series of length 1) of DNS
   messages.  In such a series, the first message MUST begin with the
   SOA resource record of the zone, and the last message MUST conclude
   with the same SOA resource record.

Meanwhile, named accepts the following AXFR stream as valid:

nil.      	300	SOA	localhost. root.nil. 3 300 300 604800 300
nil.      	300	NS	localhost.
nil.      	300	SOA	localhost. root.nil. 1 300 300 604800 300

This results in the following (rather confusing) set of log messages being generated (note the serial number discrepancies):

24-Feb-2021 22:36:49.732 zone nil/IN: transferred serial 1
24-Feb-2021 22:36:49.732 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer status: success
24-Feb-2021 22:36:49.732 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 3 records, 121 bytes, 0.001 secs (121000 bytes/sec) (serial 3)

After processing the above transfer, named puts the SOA record with serial number 1 into the zone database.

I do not think this problem poses a security threat, but I am reporting it in a confidential issue to rather be safe than sorry.

Edited Mar 09, 2021 by Michał Kępień
Assignee
Assign to
Time tracking