>Would you please report it upstream, and mark this Debian bug as >forwarded, or should I?
I'm inexperienced with git and GNU development, and only know how to write bug reports (lucky me). So I apologize for not being on the ball. Is there a proper automated way to do this in a way that preserves the tracability each way? Or do I need to create an account on the torproject.org git server, and manually add the report there? I see that there is a tag indicating that this bug was forwarded, so I'll assume for the moment you took care of it. If not, please reply and I'll get on it. >With my Tails developer hat on (and my Debian developer hat off), I'm >surprised, since I don't remember any situation where "the Tails >project" was harmed by this issue. Could you please clarify? I'm not a Tails developer, but someone mentioned in IRC that an attempt was made to implement ttdnsd and pdnsd in Tails, and that the Tails developers abandoned that approach because they couldn't make it work. >> Ideally, an optimum tor environment includes ttdnsd and pdnsd >> packages. >(This is getting off-topic, but given the shape of the pdnsd package, >and the highly buggy state of ttdnsd itself, I would certainly not >call this "optimum".) I was describing the optimum scenario from a design standpoint without considering the quality of these tools. It would be superior (particularly in the GNU environment) to isolate DNS duties to a dedicated DNS server, which can be configured and controlled independant of the payload traffic. This separation of duties is really the only proper way to do DNS. Admins have different DNS resources, different needs, and different threat models that are particular to DNS, and would be best served if they could control a DNS server and also get detailed DNS logging that would make it easier to spot DNS poisoning. ttdnsd did not strike me as a quality robust tool (being that it's a script that was intended for a SOHO router). ttdnsd and pdnsd could merely be considered examples for how one might run torsocks w/ a disabled tordns. Some admins may find DNS leaks acceptible for MX queries (considering the status quo is no MX lookup service at all, and thus must abandon tor entirely in order to function). Giving purpose to ttdnsd and pdnsd would also motivate their improvement.. or perhaps motivate forks and alternatives. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
