Repository navigation
Include DNSSEC status in --whois output - #58
Conversation
Add DNSSEC status handling to response output in whois style
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review. 📝 WalkthroughWalkthroughToWhoisStyleResponse adds DNSSEC after the name-server fields. A non-nil DelegationSigned value sets “signedDelegation” or “unsigned.” If DelegationSigned is nil, non-empty DS records set “signedDelegation.” Keys alone do not add a DNSSEC field. Tests cover these cases and confirm field order. Merge Risk: ⚪ Minimal · up to No actionable merge-blocking risk is established from the supplied evidence. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: dae5cd06-423c-46c1-ab0f-00735b99d9eb
📒 Files selected for processing (1)
response.go
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.
Match ICANN WHOIS field order, fall back to dsData/keyData presence when delegationSigned is omitted, and add tests.
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: 5aaeaf3a-bd80-49e9-92d7-8b304fa85dad
📒 Files selected for processing (2)
response.goresponse_test.go
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.
keyData is child DNSKEY data; only DS records prove the parent delegation is signed (RFC 9083).
|
Great stuff, thanks @bessone! |
Problem
The
-w/--whoisoutput format goes throughResponse.ToWhoisStyleResponse()in
response.go, which builds the WHOIS-style key/value list field by field.Unlike the default text
Printer(print.go), which does printSecureDNSvia
printSecureDNS,ToWhoisStyleResponse()never readsd.SecureDNSatall, so DNSSEC status is silently dropped when using
--whois.Fix
Add a
DNSSECfield to the WHOIS-style output, derived fromSecureDNS.DelegationSigned, matching the convention used byICANN/Verisign-style WHOIS output (
signedDelegation/unsigned).DelegationSigned(rather thanZoneSigned) was chosen because it reflectswhether the parent zone has published the DS record(s) needed to complete
the DNSSEC chain of trust — i.e. whether DNSSEC validation is actually
operative for the domain, which is what WHOIS consumers expect from this
field.
ZoneSignedonly indicates the domain's own zone is internallysigned, independent of delegation, and isn't shown in standard WHOIS output.
DS record data (key tag, algorithm, digest, etc.) is intentionally left out
of
--whoisoutput, consistent with the terse style of real-world WHOISresponses; it remains available via the default
--textand--jsonformats.
Change
Added a
DNSSECfield inToWhoisStyleResponse(), populated right afterName Server, using the same ordering position it typically has inproduction TLD WHOIS output.
Testing
rdap --whois example.comagainst a signed domain and confirmedDNSSEC: signedDelegationnow appears.DNSSEC: unsignedappears.SecureDNSobject at all and confirmed noDNSSECline is emitted (unchanged behavior — field is simply omitted,same as the other
w.add()calls when data isn't present).Summary by CodeRabbit