Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS nits #1177

Closed
abrunstrom opened this issue Jun 3, 2023 · 1 comment · Fixed by #1178
Closed

DNS nits #1177

abrunstrom opened this issue Jun 3, 2023 · 1 comment · Fixed by #1178
Assignees

Comments

@abrunstrom
Copy link
Contributor

From DNSdir review (Reviewer: Peter van Dijk):

In 4.1.1.1, "... send DNS queries for both A (IPv4) and AAAA (IPv6) records
...", this assumes no other address types will exist in the future. RFC8499
uses "address records" to refer to A/AAAA and any future variants implicitly,
pointing out that RFC2181 informally says "(A, AAAA, etc)". I'm not aware of a
more useful formal reference than 8499, so perhaps something like ".. send DNS
queries for address records, which currently means sending A (IPv4) and AAAA
(IPv6) queries ..."?

While ietf-taps-interface mentions SRV records briefly, this document does not.
An SRV record set could cause a single RemoteSpecifier to map to multiple
names. HTTPS and SVCB records can also cause indirection to multiple names (and
even transport indications). I do not think the document should go into detail
on all of these, but, as with address records, perhaps it can mention that DNS
lookups can involve an extra layer of indirection, and provide SRV, HTTPS and
SVCB as current examples.

In 4.3.2, "should follow the Happy Eyeballs algorithm described in [RFC8305]."

  • should this be a "SHOULD"? (I noticed a few other lowercase "should"s as
    well.)

In 9.1, ".. resolution answers (A and AAAA queries, for example)" - the queries
are not cached, (part of) their responses is cached. Perhaps ".. resolution
answers (from A and AAAA queries, for example"

Should 12.2 mention DNSSEC? I can very much understand it if you say no :-)

@tfpauly tfpauly self-assigned this Jun 4, 2023
@tfpauly
Copy link
Contributor

tfpauly commented Jun 4, 2023

I can take this one. It think we should make it clear that this can expand to cover SVCB / SRV / etc.

We don't want to add any normative language, so we can leave that.

The text suggestion in 9.1 is good!

I also think we should not go too much into DNSSEC.

tfpauly added a commit that referenced this issue Jun 4, 2023
@tfpauly tfpauly mentioned this issue Jun 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants