On 02/09/2012 10:58 PM, Ondrej Mikle wrote: > On 02/09/2012 12:24 AM, Jacob Appelbaum wrote: >> On 02/08/2012 11:47 PM, Ondrej Mikle wrote: >>> On 02/08/2012 02:59 AM, Nick Mathewson wrote: >>>> On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle <[email protected]> >>>> wrote: >>>> >>>> I think if we want an extra field in the future, we want to put it >>>> after the end of the response (that is, after total_len), rather than >>>> having it be optionally in every cell. >>> >>> OK. >>> >>>>> That also means AXFR/IXFR would be off limits (I'm OK with that). >>>> >>>> Me too. >>> >>> Without AXFR/IXFR we could limit total_len to 2 octets. >> >> I'd really like to be able to AXFR. I think it's important to have Tor's >> DNSPort able to do some of the most basic and common DNS stuff. > > What about making a specialized tool for AXFR/IXFR (like tor-resolve)? Its > interface could be listening for DNS packets and returning DNS-stream with > AXFR/IXFR data. Since practically every DNS server open to AXFR/IXRF must > listen > on TCP, this can be much easier implemented using the already existing TCP > tunneling in Tor. > > I think this solution would make the rest of design simpler.
Another good reason for separate tool is to be able to specify the actual server where to ask for *XFR. Using just standard recursion and asking master NS may not always give the results you want. Standard recursion with AXFR never worked for me in cases of servers listed here: http://axfr.nohack.se/ Ondrej _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
