[GH-ISSUE #2559] Name instances with and without trailing dot are considered equal but hashes to different values #1013

New issue

Closed

opened 2026-03-16 01:16:56 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 01:16:56 +03:00

Owner

Originally created by @nresare on GitHub (Nov 8, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2559

Describe the bug
Two different instances of Name, built with and without trailing dot hashes to different values, yet they are considered equal by the PartialEq implementation. This makes for some surprising behaviour when using Name instances as keys in HashMap and HashSet

The documentation of the Hash trait states

When implementing both Hash and Eq, it is important that the following property holds:
k1 == k2 -> hash(k1) == hash(k2)
In other words, if two keys are equal, their hashes must also be equal. HashMap and HashSet both rely on this behavior.

To Reproduce

    fn test_hash() {
        // verify that two identical names with and without the trailing dot hashes to the same value
        let mut hasher = DefaultHasher::new();
        let with_dot = Name::from_utf8("com.").unwrap();
        with_dot.hash(&mut hasher);
        let hash_with_dot = hasher.finish();

        let mut hasher = DefaultHasher::new();
        let without_dot = Name::from_utf8("com").unwrap();
        without_dot.hash(&mut hasher);
        let hash_without_dot = hasher.finish();
        assert_eq!(with_dot, without_dot);
        assert_eq!(hash_with_dot, hash_without_dot);
    }

Expected behavior
One way or another, PartialEq and Hash should be consistent: either "com." and "com" should not be considered equal and hash to different values or they should both be equal and hash to the same value.

System:

OS: macOS
Architecture: aarch64
Version 15.1
rustc version: 1.82

Version:
Crate: proto
Version: main branch as of today, I checked commit fce8c57fa3eaa5395ed4caf0c32b7cade50154eb

Originally created by @nresare on GitHub (Nov 8, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2559 **Describe the bug** Two different instances of `Name`, built with and without trailing dot hashes to different values, yet they are considered equal by the PartialEq implementation. This makes for some surprising behaviour when using Name instances as keys in HashMap and HashSet The [documentation of the Hash trait](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) states > When implementing both Hash and [Eq](https://doc.rust-lang.org/std/cmp/trait.Eq.html), it is important that the following property holds: > `k1 == k2 -> hash(k1) == hash(k2)` > In other words, if two keys are equal, their hashes must also be equal. [HashMap](https://doc.rust-lang.org/std/collections/struct.HashMap.html) and [HashSet](https://doc.rust-lang.org/std/collections/struct.HashSet.html) both rely on this behavior. **To Reproduce** ``` fn test_hash() { // verify that two identical names with and without the trailing dot hashes to the same value let mut hasher = DefaultHasher::new(); let with_dot = Name::from_utf8("com.").unwrap(); with_dot.hash(&mut hasher); let hash_with_dot = hasher.finish(); let mut hasher = DefaultHasher::new(); let without_dot = Name::from_utf8("com").unwrap(); without_dot.hash(&mut hasher); let hash_without_dot = hasher.finish(); assert_eq!(with_dot, without_dot); assert_eq!(hash_with_dot, hash_without_dot); } ``` **Expected behavior** One way or another, PartialEq and Hash should be consistent: either "com." and "com" should not be considered equal and hash to different values or they should both be equal and hash to the same value. **System:** - OS: macOS - Architecture: aarch64 - Version 15.1 - rustc version: 1.82 **Version:** Crate: proto Version: main branch as of today, I checked commit `fce8c57fa3eaa5395ed4caf0c32b7cade50154eb`

kerem closed this issue

2026-03-16 01:17:02 +03:00

kerem commented

2026-03-16 01:17:08 +03:00

Author

Owner

@djc commented on GitHub (Nov 8, 2024):

Thanks for the report -- I imagine that might have taken some time to figure out... Submitted a PR with a fix in #2560.

@djc commented on GitHub (Nov 8, 2024): Thanks for the report -- I imagine that might have taken some time to figure out... Submitted a PR with a fix in #2560.

kerem referenced this issue

2026-03-16 02:52:03 +03:00

[PR #1013] [MERGED] Bump ring from 0.16.9 to 0.16.10 #1871