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.

Sign up for GitHub

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

Jump to bottom

backport zero TTL system-resolved fix to 252 #336

Closed
benjaminp opened this issue Oct 21, 2023 · 3 comments
Closed

backport zero TTL system-resolved fix to 252 #336

benjaminp opened this issue Oct 21, 2023 · 3 comments

Comments

@benjaminp
Copy link
Contributor

Please consider backporting systemd/systemd#29307 to the 252 stable branch, so Debian stable can get the fix. Thank you.
@Yannik
Copy link

Yannik commented Nov 15, 2023

@poettering Any chance in getting this backported to 252/253/254? That would be great.

The reason I'm personally asking for this is that this also fixes systemd/systemd#19394 and systemd/systemd#22575 (comment).

How so?
systemd-resolved does two queries when resolving a name, for both the A and AAAA record. When doing this against a bind RPZ which only has an A record for a name, the following happens: Bind always returns the RPZ SOA in the additional section. However, it returns the RPZ SOA with TTL 1 for the a record request, and TTL 0 for the AAAA request.

As such, the ttl zero/non-zero merging bug is triggered and systemd-resolved returns errno 22 / Lookup failed due to system error: Invalid argument.

keszybz pushed a commit that referenced this issue Mar 1, 2024
@benjaminp @keszybz
resolve: tolerate merging a zero-ttl RR and a nonzero-ttl RR if not mDNS
a3f3d47 
resolved rejected RRsets containing a RR with a zero TTL and a RR with a nonzero TTL. In practice—see the linked issues—, this case triggered when an AF_UNSPEC query to a CNAMEd domain returned a zero TTL for the CNAME on one address family and a nonzero TTL for the CNAME on the other address family.

The zero-nonzero TTL check cites RFC 2181 § 5.2 in a comment. That section says DNS clients should reject any RRset containing differing TTLs, which the check only implements a very special case of. That the old behavior caused real-world false NXDOMAIN results is reason enough to completely ignore the RFC's recommendation. However, mDNS treats zero TTLs specially, so the error case needs to be kept for mDNS.

Fixes systemd/systemd#22177
Fixes systemd/systemd#20617
Fixes systemd/systemd#19118

(cherry picked from commit 8ec951e)

Related to #336
bluca pushed a commit to bluca/systemd-stable that referenced this issue Apr 25, 2024
@benjaminp @bluca
resolve: tolerate merging a zero-ttl RR and a nonzero-ttl RR if not mDNS
4bb768d 
resolved rejected RRsets containing a RR with a zero TTL and a RR with a nonzero TTL. In practice—see the linked issues—, this case triggered when an AF_UNSPEC query to a CNAMEd domain returned a zero TTL for the CNAME on one address family and a nonzero TTL for the CNAME on the other address family.

The zero-nonzero TTL check cites RFC 2181 § 5.2 in a comment. That section says DNS clients should reject any RRset containing differing TTLs, which the check only implements a very special case of. That the old behavior caused real-world false NXDOMAIN results is reason enough to completely ignore the RFC's recommendation. However, mDNS treats zero TTLs specially, so the error case needs to be kept for mDNS.

Fixes systemd/systemd#22177
Fixes systemd/systemd#20617
Fixes systemd/systemd#19118

(cherry picked from commit 8ec951e)

Related to systemd#336

(cherry picked from commit a3f3d47)
bluca pushed a commit that referenced this issue Apr 25, 2024
@benjaminp @bluca
resolve: tolerate merging a zero-ttl RR and a nonzero-ttl RR if not mDNS
038effc 
resolved rejected RRsets containing a RR with a zero TTL and a RR with a nonzero TTL. In practice—see the linked issues—, this case triggered when an AF_UNSPEC query to a CNAMEd domain returned a zero TTL for the CNAME on one address family and a nonzero TTL for the CNAME on the other address family.

The zero-nonzero TTL check cites RFC 2181 § 5.2 in a comment. That section says DNS clients should reject any RRset containing differing TTLs, which the check only implements a very special case of. That the old behavior caused real-world false NXDOMAIN results is reason enough to completely ignore the RFC's recommendation. However, mDNS treats zero TTLs specially, so the error case needs to be kept for mDNS.

Fixes systemd/systemd#22177
Fixes systemd/systemd#20617
Fixes systemd/systemd#19118

(cherry picked from commit 8ec951e)

Related to #336

(cherry picked from commit a3f3d47)
bluca pushed a commit to bluca/systemd-stable that referenced this issue Apr 25, 2024
@benjaminp @bluca
resolve: tolerate merging a zero-ttl RR and a nonzero-ttl RR if not mDNS
d44a70d 
resolved rejected RRsets containing a RR with a zero TTL and a RR with a nonzero TTL. In practice—see the linked issues—, this case triggered when an AF_UNSPEC query to a CNAMEd domain returned a zero TTL for the CNAME on one address family and a nonzero TTL for the CNAME on the other address family.

The zero-nonzero TTL check cites RFC 2181 § 5.2 in a comment. That section says DNS clients should reject any RRset containing differing TTLs, which the check only implements a very special case of. That the old behavior caused real-world false NXDOMAIN results is reason enough to completely ignore the RFC's recommendation. However, mDNS treats zero TTLs specially, so the error case needs to be kept for mDNS.

Fixes systemd/systemd#22177
Fixes systemd/systemd#20617
Fixes systemd/systemd#19118

(cherry picked from commit 8ec951e)

Related to systemd#336

(cherry picked from commit a3f3d47)
(cherry picked from commit 038effc)
bluca pushed a commit that referenced this issue Apr 26, 2024
@benjaminp @bluca
resolve: tolerate merging a zero-ttl RR and a nonzero-ttl RR if not mDNS
05bc388 
resolved rejected RRsets containing a RR with a zero TTL and a RR with a nonzero TTL. In practice—see the linked issues—, this case triggered when an AF_UNSPEC query to a CNAMEd domain returned a zero TTL for the CNAME on one address family and a nonzero TTL for the CNAME on the other address family.

The zero-nonzero TTL check cites RFC 2181 § 5.2 in a comment. That section says DNS clients should reject any RRset containing differing TTLs, which the check only implements a very special case of. That the old behavior caused real-world false NXDOMAIN results is reason enough to completely ignore the RFC's recommendation. However, mDNS treats zero TTLs specially, so the error case needs to be kept for mDNS.

Fixes systemd/systemd#22177
Fixes systemd/systemd#20617
Fixes systemd/systemd#19118

(cherry picked from commit 8ec951e)

Related to #336

(cherry picked from commit a3f3d47)
(cherry picked from commit 038effc)
@Yannik
Copy link

Yannik commented Jul 2, 2024

@benjaminp As far as I can see, this can be closed since the backports have been done.
It should be in systemd 252.24, debian already has 252.26, so feel free to check if this works for you. For me all looks good on fedora 39 / systemd 254.13.

@benjaminp
Copy link
Contributor Author

benjaminp commented Jul 3, 2024 •
edited
Loading

Yeah, bookworm-updates has 254.14, which is good enough for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@benjaminp @Yannik