mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 19:25:56 +03:00
[GH-ISSUE #631] AXFR doesn't work due to additional www. lookup #254
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#254
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 @kpcyrd on GitHub (Nov 27, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/631
Describe the bug
I was trying to implement a zone transfer for a zone that I can transfer with dig, but can't transfer with trust-dns.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Successful AXFR reply
Actual behavior
This log indicates there are actually two lookups
AXFR zonetransfer.meandAXFR www.zonetransfer.me. The 2nd one is incorrect, should not happen and causes this function call to fail. I might be missing an option here to disablewww.lookups, if there is one, please point me to it. :)Version:
Crate: resolver
Version: 0.10.0
@bluejekyll commented on GitHub (Nov 27, 2018):
hm, I've never thought of the resolver being used for AXFR. The client,
trust_dnscrate, will support this, and is more intended for direct connections to DNS servers to perform actions like this.The Resolver on the other hand is meant to resolve single records only, and probably should reject AXFR as a RecordType that can be queried. If there's a bug here, it's probably that the Resolver should just error out on AXFR requests.
As an addendum to this, we may have some edge cases around large zones in the current AXFR implementation in the library, there's an existing bug open on the server for large AXFR's, not sure how that applies to the client.
@kpcyrd commented on GitHub (Nov 28, 2018):
@bluejekyll thanks for the pointer, the client in the trust-dns crate is a lot closer to what I was looking for! I refactored my code from trust-dns-resolver to trust-dns and got AXFR to work that way.
Regardless, is there a reason why the resolver is doing an automatic
www.lookup? I can't think of a scenario in which that would be desired.@bluejekyll commented on GitHub (Nov 28, 2018):
Well, my assumption is that because AXFR isn’t intentionally supported by the resolver, some cname or srv logic was inadvertently triggered. But I didnt look to confirm this.