starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #351] server panics when responding to AXFR on zone with absurd number of records #458

New issue

Open

opened 2026-03-15 22:38:02 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 22:38:02 +03:00

Owner

Originally created by @iliana on GitHub (Feb 26, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/351

On 826f2c4195 I am able to panic named by loading a zone with ~10000 AAAA records and requesting an AXFR on that zone.

The panic is from the first assert here:

github.com/bluejekyll/trust-dns@826f2c4195/proto/src/serialize/binary/encoder.rs (L145-L152)

The current release version does not panic, but fails to serialize any records past a certain point (~650 AAAA records in size, it appears).

Log output and backtrace

    Finished release [optimized] target(s) in 0.0 secs
     Running `/home/ilianaw/git/trust-dns/target/release/named -c tests/named_test_configs/example.toml`
1519618614.726678:INFO:named:381:Trust-DNS 0.13.0 starting
1519618614.726719:INFO:named:385:loading configuration from: "tests/named_test_configs/example.toml"
1519618614.726991:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/localhost.zone"
1519618614.749084:INFO:named:161:zone file loaded: localhost.
1519618614.749125:INFO:named:207:zone successfully loaded: localhost.
1519618614.749181:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/127.0.0.1.zone"
1519618614.749397:INFO:named:161:zone file loaded: 0.0.127.in-addr.arpa.
1519618614.749419:INFO:named:207:zone successfully loaded: 0.0.127.in-addr.arpa.
1519618614.749514:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/ipv6_1.zone"
1519618614.749729:INFO:named:161:zone file loaded: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
1519618614.749781:INFO:named:207:zone successfully loaded: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
1519618614.749829:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/255.zone"
1519618614.749994:INFO:named:161:zone file loaded: 255.in-addr.arpa.
1519618614.750012:INFO:named:207:zone successfully loaded: 255.in-addr.arpa.
1519618614.750042:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/0.zone"
1519618614.750203:INFO:named:161:zone file loaded: 0.in-addr.arpa.
1519618614.750220:INFO:named:207:zone successfully loaded: 0.in-addr.arpa.
1519618614.750247:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/example.com.zone"
1519618615.757845:INFO:named:161:zone file loaded: example.com.
1519618615.757884:INFO:named:207:zone successfully loaded: example.com.
1519618615.758324:INFO:named:443:listening for UDP on UdpSocket { addr: V4(0.0.0.0:5335), fd: 3 }
1519618615.758365:INFO:named:449:listening for TCP on TcpListener { addr: V4(0.0.0.0:5335), fd: 4 }
1519618615.758384:INFO:named:532:
1519618615.758387:INFO:named:533:    o                      o            o
1519618615.758390:INFO:named:534:    |                      |            |
1519618615.758393:INFO:named:535:  --O--  o-o  o  o  o-o  --O--  o-o   o-O  o-o   o-o
1519618615.758396:INFO:named:536:    |    |    |  |   \     |         |  |  |  |   \
1519618615.758399:INFO:named:537:    o    o    o--o  o-o    o          o-o  o  o  o-o
1519618615.758402:INFO:named:538:
1519618615.758405:INFO:named:469:awaiting connections...
1519618615.758408:INFO:trust_dns_server::server::server_future:223:Server starting up
1519618627.009344:INFO:trust_dns_server::server::server_future:257:request: 32694 type: Query op_code: Query dnssec: false name: example.com. type: AXFR class: IN
1519618627.009365:INFO:trust_dns_server::authority::catalog:315:request: 32694 found authority: example.com.
1519618627.009464:INFO:trust_dns_server::server::response_handler:43:response: 32694 response_code: 0 answers: 10004 name_servers: 1 additionals: 0
thread 'main' panicked at 'assertion failed: start <= (u16::max_value() as usize)', proto/src/serialize/binary/encoder.rs:146:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:206
   3: std::panicking::default_hook
             at libstd/panicking.rs:222
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:400
   5: std::panicking::begin_panic
   6: trust_dns_proto::rr::domain::name::Name::emit_as_canonical
   7: <trust_dns_proto::rr::resource::Record as trust_dns_proto::serialize::binary::BinEncodable>::emit
   8: <trust_dns_server::authority::message_response::MessageResponse<'q, 'a> as trust_dns_proto::op::message::EncodableMessage>::emit_answers
   9: trust_dns_proto::op::message::<impl trust_dns_proto::serialize::binary::BinEncodable for M>::emit
  10: <trust_dns_server::server::response_handler::ResponseHandle as trust_dns_server::server::response_handler::ResponseHandler>::send
  11: trust_dns_server::authority::catalog::send_response
  12: <trust_dns_server::authority::catalog::Catalog as trust_dns_server::server::request_handler::RequestHandler>::handle_request
  13: <trust_dns_server::server::server_future::ServerFuture<T>>::handle_request
  14: <futures::stream::for_each::ForEach<S, F, U> as futures::future::Future>::poll
  15: <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll
  16: futures::task_impl::std::set
  17: <scoped_tls::ScopedKey<T>>::set
  18: tokio_core::reactor::Core::poll
  19: tokio_core::reactor::Core::run
  20: <trust_dns_server::server::server_future::ServerFuture<T>>::listen
  21: named::main
  22: std::rt::lang_start::{{closure}}
  23: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:305
  24: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  25: std::rt::lang_start_internal
             at libstd/panicking.rs:284
             at libstd/panic.rs:361
             at libstd/rt.rs:58
  26: main
  27: __libc_start_main
  28: _start

Originally created by @iliana on GitHub (Feb 26, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/351 On 826f2c41958ab3bfb0ba27bca8bf8e0e38be6e71 I am able to panic named by loading a zone with ~10000 AAAA records and requesting an AXFR on that zone. The panic is from the first assert here: https://github.com/bluejekyll/trust-dns/blob/826f2c41958ab3bfb0ba27bca8bf8e0e38be6e71/proto/src/serialize/binary/encoder.rs#L145-L152 The current release version does not panic, but fails to serialize any records past a certain point (~650 AAAA records in size, it appears). <details> <summary>Log output and backtrace</summary> ```plain Finished release [optimized] target(s) in 0.0 secs Running `/home/ilianaw/git/trust-dns/target/release/named -c tests/named_test_configs/example.toml` 1519618614.726678:INFO:named:381:Trust-DNS 0.13.0 starting 1519618614.726719:INFO:named:385:loading configuration from: "tests/named_test_configs/example.toml" 1519618614.726991:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/localhost.zone" 1519618614.749084:INFO:named:161:zone file loaded: localhost. 1519618614.749125:INFO:named:207:zone successfully loaded: localhost. 1519618614.749181:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/127.0.0.1.zone" 1519618614.749397:INFO:named:161:zone file loaded: 0.0.127.in-addr.arpa. 1519618614.749419:INFO:named:207:zone successfully loaded: 0.0.127.in-addr.arpa. 1519618614.749514:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/ipv6_1.zone" 1519618614.749729:INFO:named:161:zone file loaded: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 1519618614.749781:INFO:named:207:zone successfully loaded: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 1519618614.749829:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/255.zone" 1519618614.749994:INFO:named:161:zone file loaded: 255.in-addr.arpa. 1519618614.750012:INFO:named:207:zone successfully loaded: 255.in-addr.arpa. 1519618614.750042:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/default/0.zone" 1519618614.750203:INFO:named:161:zone file loaded: 0.in-addr.arpa. 1519618614.750220:INFO:named:207:zone successfully loaded: 0.in-addr.arpa. 1519618614.750247:INFO:named:132:loading zone file: "/home/ilianaw/git/trust-dns/server/tests/named_test_configs/example.com.zone" 1519618615.757845:INFO:named:161:zone file loaded: example.com. 1519618615.757884:INFO:named:207:zone successfully loaded: example.com. 1519618615.758324:INFO:named:443:listening for UDP on UdpSocket { addr: V4(0.0.0.0:5335), fd: 3 } 1519618615.758365:INFO:named:449:listening for TCP on TcpListener { addr: V4(0.0.0.0:5335), fd: 4 } 1519618615.758384:INFO:named:532: 1519618615.758387:INFO:named:533: o o o 1519618615.758390:INFO:named:534: | | | 1519618615.758393:INFO:named:535: --O-- o-o o o o-o --O-- o-o o-O o-o o-o 1519618615.758396:INFO:named:536: | | | | \ | | | | | \ 1519618615.758399:INFO:named:537: o o o--o o-o o o-o o o o-o 1519618615.758402:INFO:named:538: 1519618615.758405:INFO:named:469:awaiting connections... 1519618615.758408:INFO:trust_dns_server::server::server_future:223:Server starting up 1519618627.009344:INFO:trust_dns_server::server::server_future:257:request: 32694 type: Query op_code: Query dnssec: false name: example.com. type: AXFR class: IN 1519618627.009365:INFO:trust_dns_server::authority::catalog:315:request: 32694 found authority: example.com. 1519618627.009464:INFO:trust_dns_server::server::response_handler:43:response: 32694 response_code: 0 answers: 10004 name_servers: 1 additionals: 0 thread 'main' panicked at 'assertion failed: start <= (u16::max_value() as usize)', proto/src/serialize/binary/encoder.rs:146:9 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::_print at libstd/sys_common/backtrace.rs:71 2: std::panicking::default_hook::{{closure}} at libstd/sys_common/backtrace.rs:59 at libstd/panicking.rs:206 3: std::panicking::default_hook at libstd/panicking.rs:222 4: std::panicking::rust_panic_with_hook at libstd/panicking.rs:400 5: std::panicking::begin_panic 6: trust_dns_proto::rr::domain::name::Name::emit_as_canonical 7: <trust_dns_proto::rr::resource::Record as trust_dns_proto::serialize::binary::BinEncodable>::emit 8: <trust_dns_server::authority::message_response::MessageResponse<'q, 'a> as trust_dns_proto::op::message::EncodableMessage>::emit_answers 9: trust_dns_proto::op::message::<impl trust_dns_proto::serialize::binary::BinEncodable for M>::emit 10: <trust_dns_server::server::response_handler::ResponseHandle as trust_dns_server::server::response_handler::ResponseHandler>::send 11: trust_dns_server::authority::catalog::send_response 12: <trust_dns_server::authority::catalog::Catalog as trust_dns_server::server::request_handler::RequestHandler>::handle_request 13: <trust_dns_server::server::server_future::ServerFuture<T>>::handle_request 14: <futures::stream::for_each::ForEach<S, F, U> as futures::future::Future>::poll 15: <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll 16: futures::task_impl::std::set 17: <scoped_tls::ScopedKey<T>>::set 18: tokio_core::reactor::Core::poll 19: tokio_core::reactor::Core::run 20: <trust_dns_server::server::server_future::ServerFuture<T>>::listen 21: named::main 22: std::rt::lang_start::{{closure}} 23: std::panicking::try::do_call at libstd/rt.rs:59 at libstd/panicking.rs:305 24: __rust_maybe_catch_panic at libpanic_unwind/lib.rs:102 25: std::rt::lang_start_internal at libstd/panicking.rs:284 at libstd/panic.rs:361 at libstd/rt.rs:58 26: main 27: __libc_start_main 28: _start ``` </details>

kerem added the

bug

crate:server

crate:proto

labels

2026-03-15 22:38:02 +03:00

kerem commented

2026-03-15 22:38:13 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 26, 2018):

Thank you for the report. Out of curiosity, is this a stress test or is this a use case you want to support?

We definitely need some limits here, and need to break the axfr into multiple responses.

@bluejekyll commented on GitHub (Feb 26, 2018): Thank you for the report. Out of curiosity, is this a stress test or is this a use case you want to support? We definitely need some limits here, and need to break the axfr into multiple responses.

kerem commented

2026-03-15 22:38:18 +03:00

Author

Owner

@iliana commented on GitHub (Feb 26, 2018):

Stress test, although I'm primarily playing with internals (I have some code that serializes an entire zone using BinEncoder and decided to test it with a very large number of records). I figured if I'm seeing a panic there, I'd see a panic in the AXFR handler...

@iliana commented on GitHub (Feb 26, 2018): Stress test, although I'm primarily playing with internals (I have some code that serializes an entire zone using `BinEncoder` and decided to test it with a very large number of records). I figured if I'm seeing a panic there, I'd see a panic in the AXFR handler...

kerem commented

2026-03-15 22:38:24 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 26, 2018):

This doesn’t surprise me. I’ve been intending to revisit AXFR for a little bit now, mainly to figure out a good auth option for it.

What you’ve uncovered is a naive implementation where the entire zone is crammed into a single response. What needs to happen is that the records need to be broken up into multiple responses. This may require a bit of refactoring work to be efficient.

Also, with zones of that size there are some other issues. Currently the entire zone is cached in memory. This will pose an issue at some point. I’ve been thinking of playing around with memory mapping the zone files and putting a MRU read-through cache in front of the file. I think I have some issues filed for these issues.

Getting back to your specific issue: Messages have a bounded length of u16::max_value, this limit is due to the DNS over TCP spec. There should be an earlier error, or we should convert these to errors, so that additional records can’t be serialized into the message.

@bluejekyll commented on GitHub (Feb 26, 2018): This doesn’t surprise me. I’ve been intending to revisit AXFR for a little bit now, mainly to figure out a good auth option for it. What you’ve uncovered is a naive implementation where the entire zone is crammed into a single response. What needs to happen is that the records need to be broken up into multiple responses. This may require a bit of refactoring work to be efficient. Also, with zones of that size there are some other issues. Currently the entire zone is cached in memory. This will pose an issue at some point. I’ve been thinking of playing around with memory mapping the zone files and putting a MRU read-through cache in front of the file. I think I have some issues filed for these issues. Getting back to your specific issue: Messages have a bounded length of u16::max_value, this limit is due to the DNS over TCP spec. There should be an earlier error, or we should convert these to errors, so that additional records can’t be serialized into the message.

kerem commented

2026-03-15 22:38:29 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 26, 2018):

Grr... I thought I had some logic to enforce the size of the serialized stream, but it doesn't look that way. There are a few places that should be checking the size that currently aren't. The assertion that's currently panicking was written with the assumption that something else was enforcing the maximum length of the buffer.

TcpStream will blindly truncate the message:

https://github.com/bluejekyll/trust-dns/blob/master/proto/src/tcp/tcp_stream.rs#L311-L314

In the encoder, none of the emit functions are currently guarded to enforce a size less than u16:

https://github.com/bluejekyll/trust-dns/blob/master/proto/src/serialize/binary/encoder.rs#L122

When fixing the encoder, we should make it's enforcement variable, based on say EDNS max length options. Each emit method (perhaps a macro for this?) should attempt to write, and on failure, revert the write, and return an Error (something cheap and recoverable).

This can be used to also better truncate response records, rather than the very aggressive method available now.

@bluejekyll commented on GitHub (Feb 26, 2018): Grr... I *thought* I had some logic to enforce the size of the serialized stream, but it doesn't look that way. There are a few places that should be checking the size that currently aren't. The assertion that's currently panicking was written with the assumption that something else was enforcing the maximum length of the buffer. `TcpStream` will blindly truncate the message: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/tcp/tcp_stream.rs#L311-L314 In the encoder, none of the emit functions are currently guarded to enforce a size less than u16: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/serialize/binary/encoder.rs#L122 When fixing the encoder, we should make it's enforcement variable, based on say EDNS max length options. Each emit method (perhaps a macro for this?) should attempt to write, and on failure, revert the write, and return an Error (something cheap and recoverable). This can be used to also better truncate response records, rather than the very aggressive method available now.

kerem referenced this issue

2026-03-15 23:02:11 +03:00

[GH-ISSUE #604] Please consider committing and publishing Cargo.lock #542

kerem referenced this issue

2026-03-15 23:02:16 +03:00

[GH-ISSUE #604] Please consider committing and publishing Cargo.lock #542

kerem referenced this issue

2026-03-16 02:07:18 +03:00

[PR #458] [MERGED] remove Cargo.lock to reduce dependency churn #1452