Good day! During testing of my setup with different tools available on the internet, I mostly got good ratings. There is a specific tool however (which is loaded with a ton of checks for diverse best-practices and recommendations) where my setup is shown as complete failure. =) I am talking about https://check-your-website.server-daten.de/
Here, my DNS-servers (provided by deSEC) are the culprit for failing, as they don’t work via TCP. I was wondering why this could be such a problem, if the setup validates with all other tests I found.
I wrote to the developer, who informed me that TCP is an IANA-Requirement:
You’re right. After some digging (pun intended) in the report of the tool it seems that it complains about the NS get.desec.io, which is for me reachable via TCP as well. But I can only test IPv4. The tool complains it’s not reachable via its IPv6 adress.
I don’t know. Perhaps it’s just an academic problem, as it’s working in the real world for all of us. But perhaps you are interested in the finding. I’ll ignore the outcome with this test-suite for now.
dig -6 @ns1.desec.io +tcp fails as does dig -6 @get.desec.io +tcp but dig -6 @ns2.desec.org +tcp works for me. That would seem to be a bug, i.e. all servers should respond to port 53 tcp on IPv4 and IPv6 I think.
$ host ns1.desec.io
ns1.desec.io has address 45.54.76.1
ns1.desec.io has IPv6 address 2607:f740:e633:deec::2
$ host ns2.desec.org
ns2.desec.org has address 157.53.224.1
ns2.desec.org has IPv6 address 2607:f740:e00a:deec::2
$ host get.desec.io
get.desec.io has address 88.99.64.5
get.desec.io has IPv6 address 2a01:4f8:10a:1044:deec:642:ac10:80
$
So if I read correctly, the behaviour across the different nameservers of deSEC is inconsistant? And some are indeed not reponsive for TCP connection with IPv6?
You write this seems to be a bug - you mean misconfiguration? Is this going to be fixed? Should I notify support?
get.desec.io is not a public nameserver. It is not listed in the domain’s NS record set, but only in the SOA record’s MNAME field. According to RFC 2136 Section 4.3, it is not required for it to be reachable:
the primary master will in some cases not be reachable by all requestors, due to firewalls or network partitioning
Properties or the lack of the DNS service provided at the SOA MNAME hostname are not relevant for the public part of DNS, and should not be commented on by zone checkers.
This indicates a routing problem from your vantage point. Please reach out to support with an IPv6 traceroute so that we can address the problem.
$ dig -6 @ns1.desec.io +tcp update.dedyn.io a
;; Connection to 2607:f740:e633:deec::2#53(2607:f740:e633:deec::2) for update.dedyn.io failed: timed out.
;; Connection to 2607:f740:e633:deec::2#53(2607:f740:e633:deec::2) for update.dedyn.io failed: timed out.
; <<>> dig 9.10.8-P1 <<>> -6 @ns1.desec.io +tcp update.dedyn.io a
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to 2607:f740:e633:deec::2#53(2607:f740:e633:deec::2) for update.dedyn.io failed: timed out.
$ traceroute6 ns1.desec.io
traceroute6 to ns1.desec.io (2607:f740:e633:deec::2), 64 hops max, 60 byte packets
1 fritz.box (2003:e4:yyyy:xx00:2e3a:vvvv:fe92:zzzz) 1.922 ms 1.249 ms 2.475 ms
2 2003:0:8404:3800::1 (2003:0:8404:3800::1) 11.477 ms !N 11.378 ms !N 12.462 ms !N
$
(Anonymised as the exact IP of my router does not seem relevant.)
However, running dig -6 @2607:f740:e633:deec::2 avm99963.com a from my PC seems to be working correctly. Thus, could it also be due to a routing issue from dnsviz’s side?
This appears to be a recent routing issue, and our network provider is already investigating.
As for the issue upthread, this has been determined to be a DTAG (Deutsche Telekom) issue, and our network provider is working with them to get it resolved.
Great. Last night, our network provider sent this:
After being unable to resolve with DTAG, directly-- we made some internal adjustments to our announcements. Testing shows that traffic is now delivered as expected.
So it looks like they worked around what they still think is a DTAG issue. – That’s why we have them! They know their way around these things quite well.
As for DNSviz, I see that that has also been fixed.
