hickory-dns/hickory-dns

CNAME loops throws off the server

Closed this issue · 4 comments

Hi again,

If the zone file has a CNAME loop, the server does not respond to the later queries if a query related to the loop is asked.

Please, feel free to put this one also under the compliance tag or even ignore it, considering the zone file is not proper.

Consider the following example zone file: (I just picked a loop of length 2, but it could be longer)

example.com. 500 SOA ns1.outside.com. root.example.com. 3 604800 86400 2419200 604800
example.com. 500 NS ns1.outside.com.
b.c.example.com. 500 CNAME l.c.example.com.
l.c.example.com 500 CNAME b.c.example.com

The server responds to the queries normally if the query is not either of b.c.example.com. or l.c.example.com.. The debug log looks normal like

1605133463.060458:DEBUG:trust_dns_server::server::server_future:79:received udp request from: 127.0.0.1:41046
1605133463.060528:INFO:trust_dns_server::server::server_future:600:request: 52635 type: Query op_code: Query dnssec: false name: a.campus.edu. type: A class: IN
1605133463.060557:DEBUG:trust_dns_server::authority::catalog:133:query received: 52635
1605133463.060592:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: a.campus.edu.
1605133463.060600:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: campus.edu.
1605133463.060605:INFO:trust_dns_server::authority::catalog:527:request: 52635 found authority: campus.edu.
1605133463.060608:DEBUG:trust_dns_server::authority::catalog:547:no DAU in request, used default SupportAlgorithms
1605133463.060609:DEBUG:trust_dns_server::authority::catalog:563:performing name: a.campus.edu. type: A class: IN on campus.edu.
1605133463.060612:DEBUG:trust_dns_server::store::in_memory::authority:968:searching InMemoryAuthority for: name: a.campus.edu. type: A class: IN
1605133463.060623:DEBUG:trust_dns_server::authority::catalog:633:handling authoritative request: 52635
1605133463.060644:DEBUG:trust_dns_server::authority::catalog:872:request: 52635 non-existent
1605133463.060659:INFO:trust_dns_server::server::response_handler:49:response: 52635 response_code: 3

When the query b.c.example.com. is asked for the first time, the logs are as follows:

1605133487.804866:DEBUG:trust_dns_server::server::server_future:79:received udp request from: 127.0.0.1:38536
1605133487.804955:INFO:trust_dns_server::server::server_future:600:request: 55991 type: Query op_code: Query dnssec: false name: b.c.campus.edu. type: A class: IN
1605133487.804962:DEBUG:trust_dns_server::authority::catalog:133:query received: 55991
1605133487.804964:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: b.c.campus.edu.
1605133487.805018:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: c.campus.edu.
1605133487.805076:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: campus.edu.
1605133487.805084:INFO:trust_dns_server::authority::catalog:527:request: 55991 found authority: campus.edu.
1605133487.805110:DEBUG:trust_dns_server::authority::catalog:547:no DAU in request, used default SupportAlgorithms
1605133487.805114:DEBUG:trust_dns_server::authority::catalog:563:performing name: b.c.campus.edu. type: A class: IN on campus.edu.
1605133487.805118:DEBUG:trust_dns_server::store::in_memory::authority:968:searching InMemoryAuthority for: name: b.c.campus.edu. type: A class: IN

1605133492.805057:DEBUG:trust_dns_server::server::server_future:79:received udp request from: 127.0.0.1:38536
1605133492.805119:INFO:trust_dns_server::server::server_future:600:request: 55991 type: Query op_code: Query dnssec: false name: b.c.campus.edu. type: A class: IN
1605133492.805126:DEBUG:trust_dns_server::authority::catalog:133:query received: 55991
1605133492.805129:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: b.c.campus.edu.
1605133492.805133:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: c.campus.edu.
1605133492.805135:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: campus.edu.
1605133492.805149:INFO:trust_dns_server::authority::catalog:527:request: 55991 found authority: campus.edu.
1605133492.805176:DEBUG:trust_dns_server::authority::catalog:547:no DAU in request, used default SupportAlgorithms
1605133492.805181:DEBUG:trust_dns_server::authority::catalog:563:performing name: b.c.campus.edu. type: A class: IN on campus.edu.
1605133492.805186:DEBUG:trust_dns_server::store::in_memory::authority:968:searching InMemoryAuthority for: name: b.c.campus.edu. type: A class: IN

1605133497.805199:DEBUG:trust_dns_server::server::server_future:79:received udp request from: 127.0.0.1:38536
1605133497.805284:INFO:trust_dns_server::server::server_future:600:request: 55991 type: Query op_code: Query dnssec: false name: b.c.campus.edu. type: A class: IN
1605133497.805293:DEBUG:trust_dns_server::authority::catalog:133:query received: 55991
1605133497.805297:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: b.c.campus.edu.
1605133497.805302:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: c.campus.edu.
1605133497.805328:DEBUG:trust_dns_server::authority::catalog:454:searching authorities for: campus.edu.
1605133497.805336:INFO:trust_dns_server::authority::catalog:527:request: 55991 found authority: campus.edu.
1605133497.805343:DEBUG:trust_dns_server::authority::catalog:547:no DAU in request, used default SupportAlgorithms
1605133497.805346:DEBUG:trust_dns_server::authority::catalog:563:performing name: b.c.campus.edu. type: A class: IN on campus.edu.
1605133497.805370:DEBUG:trust_dns_server::store::in_memory::authority:968:searching InMemoryAuthority for: name: b.c.campus.edu. type: A class: IN

It looks like the same message is processed thrice. After that, the server hangs up (sometimes after responding to one or two more other queries). The debug logs do not show any error message, but a dig query returns connection timed out; no servers could be reached.

System:

  • OS: Ubuntu
  • Architecture: x86_64
  • Version: 18
  • rustc version: cargo 1.47.0

Hmm. This sounds like we’re not detecting loops in the zone. Ideally we’d reject the zone on startup. The server should definitely not crash though. My guess is we’re losing threads to stack overflows or similar.

I just tripped over this. After a bit of debugging it looks like the server ends up infinite looping in InnerInMemory::additional_search. I wonder if the loop should bail out when a found additional has already been encountered here: https://cs.github.com/bluejekyll/trust-dns/blob/8515a4321f796aaccc84ed1c3954e3f302941d9f/crates/server/src/store/in_memory/authority.rs#L496

djc commented

@Mossop that sounds like a sensible strategy. Would you be able to submit a PR?

(Out of curiosity, are you using trust-dns for a Mozilla project or for something else/personal?)

(Out of curiosity, are you using trust-dns for a Mozilla project or for something else/personal?)

Something personal: https://github.com/Mossop/localns/ (quite experimental right now!)