[GH-ISSUE #1217] Intermittent test failure in test_https_google #630

New issue

Closed

opened 2026-03-15 23:32:36 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 23:32:36 +03:00

Owner

Originally created by @djc on GitHub (Sep 28, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1217

I've seen this happen quite a bit in CI (example), and I also see it happen locally on my macOS laptop (incidence rate about 5-10%?). I don't know enough about DNS (over HTTPS) to know whether this is valid and what the test could do in order to not fail -- it seems like trust-dns is functioning correctly even when the test fails like this.

Bad response:

DnsResponse(
    [
        Message {
            header: Header {
                id: 0,
                message_type: Response,
                op_code: Query,
                authoritative: false,
                truncation: false,
                recursion_desired: false,
                recursion_available: true,
                authentic_data: false,
                checking_disabled: false,
                response_code: 2,
                query_count: 1,
                answer_count: 0,
                name_server_count: 0,
                additional_count: 0,
            },
            queries: [
                Query {
                    name: Name {
                        is_fqdn: true,
                        labels: [
                            www,
                            example,
                            com,
                        ],
                    },
                    query_type: AAAA,
                    query_class: IN,
                },
            ],
            answers: [],
            name_servers: [],
            additionals: [],
            sig0: [],
            edns: None,
        },
    ],
)

Good response:

DnsResponse(
    [
        Message {
            header: Header {
                id: 0,
                message_type: Response,
                op_code: Query,
                authoritative: false,
                truncation: false,
                recursion_desired: false,
                recursion_available: true,
                authentic_data: false,
                checking_disabled: false,
                response_code: 0,
                query_count: 1,
                answer_count: 1,
                name_server_count: 0,
                additional_count: 0,
            },
            queries: [
                Query {
                    name: Name {
                        is_fqdn: true,
                        labels: [
                            www,
                            example,
                            com,
                        ],
                    },
                    query_type: AAAA,
                    query_class: IN,
                },
            ],
            answers: [
                Record {
                    name_labels: Name {
                        is_fqdn: true,
                        labels: [
                            www,
                            example,
                            com,
                        ],
                    },
                    rr_type: AAAA,
                    dns_class: IN,
                    ttl: 21000,
                    rdata: AAAA(
                        0x2606:0x2800:0x220:0x1:0x248:0x1893:0x25c8:0x1946,
                    ),
                },
            ],
            name_servers: [],
            additionals: [],
            sig0: [],
            edns: None,
        },
    ],
)

Originally created by @djc on GitHub (Sep 28, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1217 I've seen this happen quite a bit in CI ([example](https://github.com/bluejekyll/trust-dns/pull/1215/checks?check_run_id=1175301410)), and I also see it happen locally on my macOS laptop (incidence rate about 5-10%?). I don't know enough about DNS (over HTTPS) to know whether this is valid and what the test could do in order to not fail -- it seems like trust-dns is functioning correctly even when the test fails like this. Bad response: ``` DnsResponse( [ Message { header: Header { id: 0, message_type: Response, op_code: Query, authoritative: false, truncation: false, recursion_desired: false, recursion_available: true, authentic_data: false, checking_disabled: false, response_code: 2, query_count: 1, answer_count: 0, name_server_count: 0, additional_count: 0, }, queries: [ Query { name: Name { is_fqdn: true, labels: [ www, example, com, ], }, query_type: AAAA, query_class: IN, }, ], answers: [], name_servers: [], additionals: [], sig0: [], edns: None, }, ], ) ``` Good response: ``` DnsResponse( [ Message { header: Header { id: 0, message_type: Response, op_code: Query, authoritative: false, truncation: false, recursion_desired: false, recursion_available: true, authentic_data: false, checking_disabled: false, response_code: 0, query_count: 1, answer_count: 1, name_server_count: 0, additional_count: 0, }, queries: [ Query { name: Name { is_fqdn: true, labels: [ www, example, com, ], }, query_type: AAAA, query_class: IN, }, ], answers: [ Record { name_labels: Name { is_fqdn: true, labels: [ www, example, com, ], }, rr_type: AAAA, dns_class: IN, ttl: 21000, rdata: AAAA( 0x2606:0x2800:0x220:0x1:0x248:0x1893:0x25c8:0x1946, ), }, ], name_servers: [], additionals: [], sig0: [], edns: None, }, ], ) ```

kerem

2026-03-15 23:32:36 +03:00

closed this issue
added the
bug:tests

crate:resolver
labels

kerem commented

2026-03-15 23:32:52 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 28, 2020):

Yeah, I don't know what to do about this... Cloudflare's HTTPS DNS also does this for some reason.

@bluejekyll commented on GitHub (Sep 28, 2020): Yeah, I don't know what to do about this... Cloudflare's HTTPS DNS also does this for some reason.

kerem commented

2026-03-15 23:32:57 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 28, 2020):

I suppose that since it's happening to both, maybe we actually have a spurious failure related to how we treat the HTTP/2 streams? That is somewhat complex logic...

@bluejekyll commented on GitHub (Sep 28, 2020): I suppose that since it's happening to both, maybe we actually have a spurious failure related to how we treat the HTTP/2 streams? That is somewhat complex logic...

kerem referenced this issue

2026-03-16 02:13:32 +03:00

[PR #630] [CLOSED] restrict udp responses to known hosts #1566

kerem referenced this issue

2026-03-16 02:13:32 +03:00

[PR #632] [MERGED] restrict udp responses to known hosts #1570