Does anyone actually use this package? Either it is heavily broken or I am doing something wrong. I set up dns2tcpd and a NS record as described in the documentation. However calling dig -t NS on the subdomain times out for the vast majority of name servers I tried. A timeout also indicates that it is not a caching problem. So I went on to see what's happening and installed tcpdump. It seems like many nameservers want to verify NS records by querying the target server (dns2tcpd). Unfortunately dns2tcpd has no handling for these requests, so it simply drops them. The asking nameserver then believes that dns2tcpd is unreachable and does not forward queries. Working out a patch for this shouldn't be difficult (famous last words), as it is "only" like handling a new packet type and answering it with information provided in the configuration file. During my research I actually found a (one) public dns server that does not do this kind of NS checking. In most use cases of dns2tcp one will not be able to choose a dns server though. Helmut
tags 567096 + patch thanks I created a patch for this issue and verified that it does answer NS request in a manner dig can understand. Unfortunately I was not able to test it in a real use case yet. Helmut
found 567096 0.4.dfsg-5 thanks This affects stable, btw. Rhonda can fix it now. Helmut
tags 567096 + pending thanks [Replace XX with correct value] Dear maintainer, I've prepared an NMU for dns2tcp (versioned as 0.4.dfsg-5.2) and uploaded it to: http://sub-zero.brumit.nl/nmu/dns2tcp/dns2tcp_0.4.dfsg-5.2.dsc Regards. Martijn van Brummelen
tags 567096 -pending thanks Martijn, you appear to have uploaded your NMU to your own website, not to the Debian upload queue; you don't appear to be a Debian developer in any case so wouldn't have access to do so. I'm therefore dropping the 'pending' tag since this doesn't actually appear to be pending. I'm not sponsoring an upload of the provided patch because a) the code has changed significantly upstream in the new version that Arnaud has just uploaded, and b) the patch involves writing code to manipulate binary data and I can't be bothered to invest the time in vetting such code for Yet Another DNS Tunnel. Arnaud, you're clearly active given that you've just uploaded a new upstream version of the package this week. Could you please comment on this bug and indicate how you intend to handle it, or if there's a case to be made that dns2tcp is useful even with this limitation present, could you please note this and downgrade the bug?
severity 567096 wishlist thanks Right, I have dns2tcpd working through "some" ns servers out there. It does not pretend to do more. I was not aware of NS servers doing such check described in the bug, but the tests sort of makes sense. I'm pinging upstream to know what he thinks of the feature and downgrading the bug as wishlist. Thanks -- Arnaud
dns2tcp is supposed to only respond to NS queries, and no dns server "checks" for NS reply before forwarding TXT as far as I know. If you happen to find one such server, please point me to one and reopen. I suspect mis-use of the software, please attach your config for any further request.
I was trying to get dns2tcp working. During my testing I found out that indeed NS queries were sent to the machine running dns2tcp. As far as I know my internet provider runs the bind9 dns server included with Debian stable. The behaviour of dns2tcpc was to time out. <--- dns2tcpd.conf listen = <primary ip address> port = 53 # If you change this value, also change the USER variable in # /etc/default/dns2tcpd user = nobody chroot = /tmp domain = <dns2tcp.somedomain.example> ressources = ssh:127.0.0.1:22 ---> I'd be glad if you could help me figure this out. Helmut