mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #1277] client: AXFR not return all records #642
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#642
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @visig9 on GitHub (Nov 9, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1277
Describe the bug
I'm try to use
trust_dns_clientin company internal network to fetch all records by AXFR request. But I found the returned records not the same as results ofdig.digversion (useexample.com.to replace real domain):The
trust-dns-clientaxfr-test program:I notice the result of
digindicated it has 660 records + 2 messages, but in my sample code only has 405 records + 1 message. It maybe a bug?To Reproduce
The code of
axfr-test:Expected behavior
axfr-testshould have the same results ofdig.System:
Version:
Crate: client
Version: 0.19.5
Additional context
N/A
Thanks help!
@djc commented on GitHub (Nov 9, 2020):
Since we don't have access to your DNS server, could you look at the resulting records and give some samples of responses that are in dig's responses, but not in the trust-dns reponses? My initial hunch is that dig is allowing multiple messages while this might need some extra setup on the trust-dns side.
@visig9 commented on GitHub (Nov 10, 2020):
If don't care how data produced, just scroll to
diff the two filessection.axfr-testrust source codeGet output
Then convert
dig-result.txttodig-result-modified.txtby remove data part from all line of records.diff the two files
diff.txt: (already mask some sensitive domain data)Look like AXFR answers already sorted by alphabet order. And it lost all domain names after some point of the whole list.
@djc commented on GitHub (Nov 10, 2020):
So it looks like that would indeed be due to not properly reading the second message.
@bluejekyll commented on GitHub (Nov 10, 2020):
It's entirely possible that we have a bug with AXFR. We may not be holding the client stream open for more than a single message. There is an existing bug for this in fact. I just haven't had time to consider how we'll fix this, as I think it means switching into a different mode for AXFR. Though, the async interface probably should change, and in fact, the way we process mDNS has similar issues, as well as Happy Eye Balls (ipv4 and ipv6 lookup). We should probably be returning an async Stream interface to read all the messages in the AXFR case (and the others). It may mean a refactor of a bunch of inner components.
See similar discussion here: #351 (edit: this is the server side, rather than the client, but similar issue, i.e. only a single message is being used for AXFR responses)
@trinity-1686a commented on GitHub (May 22, 2021):
this should be fixed by #1478
@csarn commented on GitHub (Jul 22, 2022):
I'm not sure if this ever was fixed, but currently (trust-dns-client 0.21.2) the problem still exists.
A DnsResponse to an AXFR query only contains roughly 550 records, probably depending on size of each record. This seems to be the content of only one Message, even if the server responds with multiple Messages.
Is there a way get all records since #1478 ?
While I came across this problem during stress-testing, I actually planned on using trust-dns-client AXFR for a live zone that exceeds a single message for transfer. This is not a large zone, but DNSSEC adds a lot of records (and quite large ones).
@trinity-1686a commented on GitHub (Jul 23, 2022):
Instead of
Client::query, you should useClient::zone_transfer, and hopefully it will work.@csarn commented on GitHub (Jul 23, 2022):
Thanks, it does indeed work!
@bluejekyll commented on GitHub (Jul 23, 2022):
Closing this with the above answer. And thank you for following up @trinity-1686a !