BIND 10 #598: Resolver DO bit, forwarder pass DO bit
BIND 10 Development
do-not-reply at isc.org
Fri Apr 8 12:15:14 UTC 2011
#598: Resolver DO bit, forwarder pass DO bit
-------------------------------------+-------------------------------------
Reporter: jreed | Owner: zhanglikun
Type: defect | Status: reviewing
Priority: major | Milestone:
Component: | Sprint-20110419
resolver | Resolution:
Keywords: | Sensitive: 0
Estimated Number of Hours: 0.0 | Add Hours to Ticket: 0
Billable?: 1 | Total Hours: 0
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => zhanglikun
Comment:
Hello
Replying to [comment:9 zhanglikun]:
> > I didn't look last time as closely, but isn't the same buffer sent
back? Is the message really parsed and rendered again?
>
> No, the buffer size from client is ingored now, that's always think it
support the max buffer size of forwarder. BTW, according the RFC, the
edns0 information should not be forwarded.
So, if I understand it correctly, the goal is to get as large answer as
possible and truncate it if needed, but the truncation doesn't happen yet?
So another ticket should be opened for that?
> > asio itself provides a function that reads the whole amount of data
for you, retrying the read if the previous one was shorter. You have a
loop where you keep retrying read until you have enough data, this can be
simplified (or did I look at older code?).
>
> Could you mention the code where I should use async_read?
io_fetch.cc:170. But looking at it, it's Jelte's code, for some reason
`git diff master...` showed that as well. Maybe I didn't have new enough
master or something.
> > So, what changelog entry do you propose?
>
> possible entry is:
> [trac598] Implement the simplest forwarder, which pass everything
throught except QID, port number, and the response will not be cached.
The changelog is OK regarding the code, but I'm not sure if implementing
the simplest forwarder is in scope of this ticket. Not that I'd propose
removing the code, if it leads towards what we want, of course.
Anyway, from the older comments, I might be little bit unclear, I meant
changing RunningQuery→UpstreamQuery and leaving ForwardQuery as it is
(since ForwardQuery was really good name, but the RunningQuery isn't and
UpstreamQuery is mostly about resolver I believe).
And is there some shared code left between the two? Or you removed almost
everything from the forwarding version?
Thanks
--
Ticket URL: <http://bind10.isc.org/ticket/598#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list