Opened 10 years ago

Closed 10 years ago

#76 closed defect (fixed)

loadzone broken? DS rdata doesn't match

Reported by: jinmei Owned by: each
Priority: high Milestone: 03. 1st Incremental Release
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: Add Hours to Ticket:
Total Hours: Internal?:

Description

If you run BIND10 auth server with rev 1163 of src/lib/auth/testdata/test.sqlite3 (which should be copied to tmp/zone.sqlite3) and ask for sql1.example.com/DS, the server returns this:

;; ANSWER SECTION:
sql1.example.com. 3600 IN DS 33313 5 1 0FDD7A2C11AA7F55D50FBF9B7EDDA2322C541A8D
sql1.example.com. 3600 IN DS 33313 5 2 00B99B7006F496D135B01AB17EDB469B4BE9E1973884DEA757BC4E30 15A8C3AB

The RDATA is broken. These should be

3600 DS 33313 5 1 (

FDD7A2C11AA7F55D50FBF9B7EDDA2322C541
A8DE )

3600 DS 33313 5 2 (

0B99B7006F496D135B01AB17EDB469B4BE9E
1973884DEA757BC4E3015A8C3AB3 )

(there are garbage 0's in the returned data)

Not fully inspected, but it doesn't seem to be a data source problem, but I suspect the database file itself is broken.

Subtickets

Change History (2)

comment:1 Changed 10 years ago by each

  • Status changed from new to accepted

The problem was that the rdata contained spaces:

33313 5 1 FDD7A2C11AA7F55D50FBF9B7EDDA2322C541 A8DE

...which is legal, but decodeHex() didn't know about it. Since that string is 41 characters long, it read the first byte as 0F, not FD. Fixed in r1315, and a unit test added.

comment:2 Changed 10 years ago by each

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.