tor's dnsserv returns NOTIMPL for queries of type ALL and MX

While trying to get qmail working over tor I found that it will work if ALL and MX records don't return NOTIMPL. In the attached patch I have ALL records doing whatever A and AAAA records do and MX just returning NXDOMAIN. (Which should be fine since MX records aren't required and MTAs should fall back to A records if they don't exist, right?)

Trac:
Username: epoch

changed milestone to %Tor: 0.2.5.x-final

added 025-triaged andrea-review-0254 component::core tor/tor dns dnsport milestone::Tor: 0.2.5.x-final priority::medium reporter::epoch resolution::implemented status::closed tor-client type::enhancement version::tor unspecified labels

Hopefully this patch won't affect what was wanted with https://trac.torproject.org/projects/tor/ticket/3369

Trac:
Username: epoch

Trac:
Username: epoch
Type: defect to enhancement
Milestone: Tor: unspecified to N/A

It does seem to conflict with #3369 (moved), at least as I read it, but I might misunderstand.

The real long-term solution here would be to implement proposal 219 so that we can support more DNS types, but that's obviously not going to be simple. If this gets qmail working, we should maybe see whether it's workable for as a stopgap option or something.

Trac:
Milestone: N/A to Tor: 0.2.5.x-final
Status: new to needs_review
Keywords: N/A deleted, tor-client dns dnsport added

Replying to epoch:

While trying to get qmail working over tor I found that it will work if ALL and MX records don't return NOTIMPL. In the attached patch I have ALL records doing whatever A and AAAA records do and MX just returning NXDOMAIN. (Which should be fine since MX records aren't required and MTAs should fall back to A records if they don't exist, right?)

Didn't know that descriptions weren't changeable... Right now the patch is returning NO ERROR for queries for MX records with 0 answers. Which is what seems to be correct according to what bind does when a domain doesn't have an MX record and should satisfy the process in http://tools.ietf.org/html/rfc5321#section-5.1 describing how mailers should figure out where to send mail which says NX returned for an MX lookup is supposed to be reported as an error.

Trac:
Username: epoch

Patch has been tested with postfix too. Can send and receive mail to and from hidden services.

Trac:
Username: epoch

Trac:
Username: epoch

tor-dnsserv.patch

Trac:
Username: epoch

This looks plausible to me... but maybe it should return nothing for all other types, not just for MX?

Trac:
Keywords: tor-client dns dnsport deleted, tor-client dns dnsport 025-triaged added

(We chatted about this a little on IRC; it sounds plausible. Maybe it should be controlled by an option. Marked as 025-triaged)

I tweaked it as a new branch "bug10268" in my public repository. It now takes all previously disallowed qtypes and responds by sending an empty reply. In theory. I tested it a little and it doesn't seem to have anything wrong with it, though more attention would be good.

Drop owners from needs_review tickets in tor 0.2.5

Trac:
Keywords: tor-client dns dnsport 025-triaged deleted, andrea-review-0254, tor-client, dns, dnsport, 025-triaged added

Review:

• The if (!q) case to send a NOTIMPL can only happen if req->nquestions == 0 or if all of the questions either have req->questions[i] == NULL or req->questions[i]->dns_question_class != EVDNS_CLASS_INET. I suppose the last case is the one that can actually happen if a client still cares about CHAOS or HESIOD for some reason, and so the if (!q) { NOTIMPL } bit isn't dead code?

• Aside from the above inquiry, this all looks okay to me in lieu of actually doing proposal 219 properly.

wrt that question: I believe that's right. I've gotten zero requests for CHAOS or HESIOD stuff, thank goodness.

Merging to 0.2.5 then.

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

closed

mentioned in issue #11403 (moved)

mentioned in issue #18710 (moved)

moved to tpo/core/tor#10268 (closed)

mentioned in issue tpo/core/tor#18710 (closed)