mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-26 03:35:52 +03:00
[GH-ISSUE #1531] Reverse DNS Zone returns NS records instead of SOA #693
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#693
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 @williamdes on GitHub (Aug 5, 2021).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1531
Describe the bug
I am not a DNS expert bug this makes weeks since I am trying to setup my reverse IPV6 Zone.
Today my hosting provided hosted the zone on his server so we could compare DNS results.
To Reproduce
Other DNS server
My trust-dns server
Expected behavior
A clear and concise description of what you expected to happen.
Version:
Version: latest version in docker (0.20.3)
Additional context
Diff on other query
@williamdes commented on GitHub (Aug 5, 2021):
My question is: why AUTHORITY and ADDITIONAL differs on first query and why does ADDITIONAL differ on query 2
My bet is that ADDITIONAL differs because of the EDNS option. But for the authority I am not sure what it could be.
I have been stuck since weeks on
Nameserver ns01.dns.datacenters.network/2a10:4646:14::53 is a recursor.Nameserver ns01.dns.datacenters.network/2a10:4646:14::53 is a recursor.(https://dnscheck.ripe.net/test/da917744c53aac5b or https://dnscheck.ripe.net/test/a312ae64a1ef6bd9)and since the only diff I see is AUTHORITY well I go here to ask.
named.toml
ipv6_block.zone
Yes it says misconfigured in the file but I just copied what works on the other server
@bluejekyll commented on GitHub (Aug 6, 2021):
For the first one, the NS records are returned to the original spec in RFC 1034, which if I remember correctly (and if I read it corrected) is that NS records should be returned for authoritative answers, which this appears to be.
For the second I don't see an issue other than the EDNS isn't encluded (was trust-dns compiled with dnssec support?).
I'm not sure what the issue is that you're reporting. Is the recursive resolver rejecting the response from trust-dns? The answer sections of both look good, unless I'm missing something.
@bluejekyll commented on GitHub (Aug 6, 2021):
I think if we want, we can drop the NS records from the responses. It would have the benefit of reducing the response size.
@williamdes commented on GitHub (Aug 6, 2021):
I do not have enough DNS expertise to know what is exactly wrong
Maybe you can compare the dns servers
But I will probably fire up a bind9 server with the same zone file and check if the RIPE validator passes
It would need maybe more spec reading but there is something "wrong" between trust-dns and a regular dns server
I would be interested to try a new commit that brushes the difference out
@bluejekyll commented on GitHub (Aug 8, 2021):
Ok, for the authoritative response, this PR disables the inclusion of NS records: #1533 can you test with that?
@williamdes commented on GitHub (Aug 8, 2021):
Sure, this is the occasion for me to start working on the Docker repo :)
@williamdes commented on GitHub (Aug 8, 2021):
@bluejekyll I tested your PR in production and it works fine. The NS is indeed not returned like other regular DNS server does
I still have
Nameserver ns01.dns.datacenters.network/2a10:4646:14::53 is a recursor.on the RIPE interfaceAnd here is what they responded to me
I do not see what makes it think it is a recursor, nor they seem to know..
@bluejekyll commented on GitHub (Aug 11, 2021):
Ok, we must need to set the
rdflag to specifically call out recursion is desired in the second request?@williamdes commented on GitHub (Aug 11, 2021):
Probably, it's worth a try :)
@williamdes commented on GitHub (Aug 12, 2021):
Let me know if you need me to try out a new commit
@bluejekyll commented on GitHub (Aug 13, 2021):
@williamdes , I'm actually a little confused by the response you got. The reason is that it's not clear based on the response why they think that your trust-dns server is recursive. After reading https://datatracker.ietf.org/doc/html/rfc6895 again, I think we should be setting the
rdflag in the response. But from what I can tell trust-dns is properly returning the codes that they claim it is not, i.e. we are not returning thera(recursion available) flag in the response.I'll put in a fix for the
rdflag since it looks like were out of compliance with rfc6895. maybe that will make a difference for their test, we'll see.@williamdes commented on GitHub (Aug 13, 2021):
I agree with you this is more than confusing but we will find out after I deploy your future work
@williamdes commented on GitHub (Aug 15, 2021):
I deployed the last commit and .... the validator still thinks I am a recursor ...
A bit pissed of by their validator. That said all the changes in your PR for me are good and should be merged, thank you so much for doing them !
Next step will be trying to setup a "standard" bind9 server and see if it works, and then do more die and retry comparing until I find out what differs
@williamdes commented on GitHub (Aug 15, 2021):
In case it helps
here is the full log from start to end of queries
@bluejekyll commented on GitHub (Aug 15, 2021):
Ok, this is interesting, they are trying to do a zone transfer:
That response code (we should make that the txt so it’s clearer, is refused, ie we’re denying the zone xfer. There are some known issues with zone xfers in trust-dns, but I think you can enable it if you want.
allow_axfron the zone config set totrueshould do it. (But be warned there are issues)@williamdes commented on GitHub (Aug 15, 2021):
I enabled it but it still did not work, trying bind9 just now
Will try to report back in some minutes
here is the logs
@williamdes commented on GitHub (Aug 15, 2021):
This is what they queried when I asked for my domain object to be updated as I was trying since the start.
And, it works .. 🤔
Yay, but this is not a win for Rust, I would really like to use trust-dns
Let me know what to do, for now I switched the trust-dns port to 5353
You can have fun with the two servers:
dig 4.1.0.0.6.4.6.4.0.1.a.2.ip6.arpa @2a10:4646:14::53 -p 5353and port 53@bluejekyll commented on GitHub (Aug 15, 2021):
I see that your bind config is also denying AXFR:
zone transfer '4.1.0.0.6.4.6.4.0.1.a.2.ip6.arpa/AXFR/IN' deniedwhich implies that's not related to the issue. Without their test telling us exactly why they are rejecting the reverse domain host, there's not much for us to go on in regards to fixing this.Don't hold one random project against Rust as a whole. I think this is the first time I'm aware of that someone is trying to host reverse zones with trust-dns.
@Darkspirit have you ever tried to host reverse zones with trust-dns?
@bluejekyll commented on GitHub (Aug 15, 2021):
On some of these tests, it looks like we're returning 3 (NXDOMAIN), where as bind is returning 5 (REFUSED) see the queries for
.andxx--domain-cannot-exist.xx--illegal-syntax-tld.as examples in the logs you posted before. I suppose this could be an issue? We've had trouble in the past with the wrong error codes causing resolver issues.I've just pushed a new change that sets REFUSED instead on the response for authorities which are not registered with trust-dns.
@williamdes commented on GitHub (Aug 16, 2021):
Thank you for the fixes, I will try them after some sleep
And for zone transfers maye I did not understand what they are but I do not expect any zone transfer, just reply a fixed zone file
I agree for the holding on but my point is that if nobody reports bugs tools do not get better and there is only one tool that everybody uses because it just works. Leaving less space for innovations, new languages and ecosystems to build. Anyway this is only my opinion and maybe it is not everyone's truth 😆
@williamdes commented on GitHub (Aug 17, 2021):
IT WORKSSSSS !! 🎉
I am so happy !
(the first query was made by me, all the other ones where done by the detector)
logs
@bluejekyll commented on GitHub (Aug 17, 2021):
That’s great news! I’ll work on a patch to get the changes to get here in.