[DNSOP] Secdir last call review of draft-ietf-dnsop-qdcount-is-one-03

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Ready

I am the assigned SECDIR reviewer for this draft. Please treat these comments
just like any other last call comments.

The document clarifies ambiguities in the DNS protocol specification,
particularly concerning the QDCOUNT parameter in query messages (OPCODE = 0).
By explicitly stating that the QDCOUNT value for query messages must not exceed
1. The document is short and clear.

Best Regards,
Linda Dunbar


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Has Nits

Reviewer: Linda Dunbar
Review result: Ready with some questions

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

Summary:
The document describes the procedure for in-band method for DNS operators to
publish arbitrary information about the zones. The description is very clear
and has a very clear description of the Security Consideration.

Here are some minor issues with the draft:
- What kind of "arbitrary information about the zones"? any examples?
- Section 3.2 (Page 6). The first step is not intuitive. does it mean nothing
needs to be performed if the child is "securely delegated"? How does the
"securely delegated" child publish information?

Thanks, Linda Dunbar



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Genart last call review of draft-ietf-dnsop-glue-is-not-optional-08

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-glue-is-not-optional-08
Reviewer: Linda Dunbar
Review Date: 2023-05-07
IETF LC End Date: 2023-05-10
IESG Telechat date: Not scheduled for a telechat

Summary:
This document specifies the detailed DNS Glue Requirements. The document is
written very clear. I think it is ready for publishing.

Major issues:
No.
Minor issues:
No

Nits/editorial comments:

No

Best regards, Linda Dunbar


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Secdir last call review of draft-ietf-dnsop-alt-tld-22

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

This draft is to reserve .alt as the Special-Use Domain Names. Section 1 says
that the technique is to address problems discussed in RFC8244. After reading
the RFC8244, I learned RFC8244 covers many more problems, not just the .alt
Special-Use Domain Names. Suggest adding the specific section of the RFC8244
for reference.

Question: Are the .local and  .onion part of the Special-use domain names
registered in IANA?

Thank you very much,
Linda Dunbar



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Genart last call review of draft-ietf-dnsop-dnssec-bcp-03

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-dnssec-bcp-03
Reviewer: Linda Dunbar
Review Date: 2022-10-03
IETF LC End Date: 2022-10-05
IESG Telechat date: Not scheduled for a telechat

Summary:
This draft is supposed to provide a comprehensive guideline and list of all the
RFCs for people interested in deploying DNSSEC.

Major issues:

Minor issues:

Nits/editorial comments:
Section 1.2 (Implementing DNSSEC) states that some of the DNSSEC-related RFCs
have significant errata.

Is it possible to have a link to list those errata? so that people can easily
access them.

I am not an expert in DNSSEC. It has been overwhelming going through so many
RFCs for different aspects of the DNSSEC. It will be nicer if someone can write
a deployment guideline in addition to this draft of listing all the RFCs. Thank
you very much Linda Dunbar



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Secdir last call review of draft-ietf-dnsop-7706bis-07

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Has Nits

Reviewer: Linda Dunbar
Review result: Ready with questions

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The Abstract of  This document claims that this document shows how to start and
maintain  a copy of the root zone in the Recursive Resolvers so that the
Resolvers don't need to send query to  another node. Two questions: - What if
the node is not authorized to have the entire records? It would desirable for
the Resolvers to have all the records of the root zone. Is there any scenario
that the Resolvers simply cannot get all the records of the root zone?

-  How to detect if any records stored in the Resolver are STALE?

Page 3, last sentence of the 3rd paragraph:  is it a typo? or miss a verb?
"... it would all responses from a remote root server"

Cheers,

Linda Dunbar


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop