Opened 9 years ago

Closed 9 years ago

#834 closed defect (fixed)

no EDNS0 on outgoing queries

Reported by: jelte Owned by: jelte
Priority: medium Milestone: Sprint-20110614
Component: resolver Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 1.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

Someone reported that dig txt rs.dns-oarc.net when running as a resolver returned 'no edns', which is true, it doesn't set EDNS0 and a bufsize on outgoing queries in IOFetch.

Subtickets

Change History (15)

comment:1 Changed 9 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from new to reviewing

Note that there is a ticket to move DNS-specific code out of asiolink, but fixing this problem for now is an easy addition of a few lines of setEDNS in IOFetch. See the minor change in branch trac834.

comment:2 Changed 9 years ago by jelte

Another note is that setting EDNS0 and DO without any fallback (which would require some advanced intelligence between nsas and resolver), some old auths and 'bad' networks (fragment-filtering low MTU's) may become unreachable for us now.

comment:3 Changed 9 years ago by stephen

  • Milestone changed from Year 3 Task Backlog to New Tasks

comment:4 Changed 9 years ago by shane

  • Defect Severity set to N/A
  • Owner changed from UnAssigned to shane
  • Status changed from reviewing to accepted
  • Sub-Project set to DNS

comment:5 Changed 9 years ago by shane

  • Defect Severity changed from N/A to Medium
  • Owner changed from shane to UnAssigned
  • Status changed from accepted to assigned

This doesn't seem like it's actually ready for review, so I'm moving it to UnAssigned? work.

comment:6 Changed 9 years ago by jelte

how so? Because the change is only a couple of lines? or because this should also include fallback logic (which would be a nontrivial change with the nsas imo)

comment:7 Changed 9 years ago by shane

  • Milestone changed from New Tasks to Year 3 Task Backlog
  • Owner changed from UnAssigned to jelte
  • Status changed from assigned to reviewing

I misunderstood your comments, and didn't realize it was actually ready for review! I think there should be separate tickets created for the additional work (EDNS fallback, EDNS buffer size configuration) unless they already exist.

I went ahead and did a quick look at the code, but I think the change needs tests, right?

I'm putting this on the Year 3 backlog for now. We can discuss adding it to the next sprint (which probably makes sense).

comment:8 Changed 9 years ago by jelte

since it was still assigned to me, i just did even though it was not really on the short-term goal

only the last commit (41139644452bb11a162254b442ab611644ceb603) is really relevant, the earlier ones are an initial change (which also was kind of in master already) and a merge from master.

now actually sets edns0, but does not set DO bit (which appears to break the resolver as far as the resolver works already). updated test to reflect the added EDNS0 message.

there's no fallback for edns lameness (yet), it would make much more sense to do that after we pull dns logic out of iofetch

comment:9 Changed 9 years ago by shane

  • Milestone changed from Year 3 Task Backlog to Next-Sprint-Proposed

comment:10 Changed 9 years ago by stephen

  • Milestone changed from Next-Sprint-Proposed to Sprint-20110614

comment:11 Changed 9 years ago by jelte

  • Owner changed from jelte to UnAssigned

comment:12 Changed 9 years ago by stephen

  • Owner changed from UnAssigned to stephen

comment:13 follow-up: Changed 9 years ago by stephen

  • Owner changed from stephen to jelte

Changes are OK so please merge.

However, this adds the OPT RR to all upstream queries (except those where an incoming packet is passed upstream with minimal change). RFC 2671 Section 5.3 states:

5.3. Responders who do not understand these protocol extensions are
     expected to send a response with RCODE NOTIMPL, FORMERR, or
     SERVFAIL.  Therefore use of extensions should be "probed" such that
     a responder who isn't known to support them be allowed a retry with
     no extensions if it responds with such an RCODE.  If a responder's
     capability level is cached by a requestor, a new probe should be
     sent periodically to test for changes to responder capability.

This suggests that we need to add the ability to send message upstream with no EDNS0. It also suggests that the NSAS needs to be extended to include a record of whether a nameserver has EDNS0 support.

comment:14 in reply to: ↑ 13 Changed 9 years ago by jelte

Replying to stephen:

This suggests that we need to add the ability to send message upstream with no EDNS0. It also suggests that the NSAS needs to be extended to include a record of whether a nameserver has EDNS0 support.

yes i sort of mentioned this earlier (comment 2), and not just for non-support of the OPT record. I think we should also have a fallback scheme for MTU problems and DNSSEC lameness (and possibly other things as well).

comment:15 Changed 9 years ago by jelte

  • Resolution set to fixed
  • Status changed from reviewing to closed

Created a ticket for that fallback/support issue (ticket #996).

Merged this one, closing.

Note: See TracTickets for help on using tickets.