The dns request/response seems to have a reserved flag called Z which is not
used yet ?

This flag could be used to indicate a dns transaction id extension.

This extension could be added anywhere in the packet.

Be it as a new field... or as a extra fake query/answer.

Over time software needs to be updated anyway... so implement this extension
as soon as possible into new software and devices and all will be well soon
enough... at least for all those people that think it's important enough to
warrant an update

Bye,
Skybuck.

On Aug 11, 4:17*pm, Didi wrote:

>*There is no state to save between requests if you use TCP
> other than what there is if you use UDP. Both transports
> are defined in RFC1034/1035, the only difference being a length word
> at the beginning of the data.

Umm, what? There is *NO* state to save between requests for UDP. The
server can completely forget that the client exists and can treat each
new request packet as its own universe.

With TCP, there are two choices:

1) You could use a new TCP request with each connection. In that case,
instead of one packet for a UDP request and one packet for a UDP
reply, you have a three-way TCP handshake, then the request/reply,
then the FIN/ACK packets of a TCP shutdown. This increases the network
traffic to the DNS server by a factor of 3 or so.

2) You could keep each TCP connection up between requests. This
requires the server to store the full TCP connection state for every
client connected to it. At minimum, this is the client IP, client
port, window positions in both direction, current state. If it doesn't
use a timer of some kind, it will be vulnerable to various DOS
attacks, so it will need to keep a timeout or a 'last heard' time.

TCP requires significantly greater state on the server than UDP, or it
requires about three times the network bandwidth. Most likely,
somewhere in-between these two, depending upon the ratio of requests
to connection setup/teardowns.

DS

In article ,
vjs@calcite.rhyolite.com (Vernon Schryver) writes:
> Someone in the mailing lists suggested hacking a special code for
> very busy DNS servers that would
> - answer all SYNs to port 53 with SYN-ACK without creating a TSP or saving
> any other state,
> - acknowledge everything that seems to want an acknowledgement,
> - assume that the DNS/TCP/IP request would fit in the first and
> only non-trivial segment after the SYN,
> - and generally act as if DNS/TCP/IP were the same as DNS/UDP/IP.
>
> It would do no retransmitting, which might be hard on DNS clients beyond
> lossy paths.

Retransmissions should not be a problem, provided that you replace
"acknowledge everything that seems to want an acknowledgement", with
something just a little bit more sophisticated.
The client's sequence numbers are used to verify that it is really
talking to the server, but the server can use its sequence numbers as a
cookie. For the sake of the explanation I will assume that the server's
ISS is 0.

There are 3 things that may want an acknowledgement:

- SYN.
Always acknowledge.

- Request, with or without FIN.
Always respond with reply+FIN+ACK

If the client is on a lossy path then it will retry its request,
which triggers another reply+FIN+ACK. In other words, the client
handles retransmissions.

- FIN in a segment by itself.
Be careful. If you acknowledge this just because it seems to
want an acknowledgement then the client will assume that you've
seen its request and no longer retransmit.
We therefore only acknowledge the FIN if this segment acknowledges
our response. This is where the cookie comes in. If segment.ack <= 1
then it only acknowledges our SYN. Otherwise chances are that it
acknowledges our response.

At first sight it may seem that this causes an extra packet to be sent,
but unless the client is really broken it can combine the retransmission
of its FIN with the acknowledgement of our FIN, which needs to be sent
anyway.

Vernon Schryver wrote:
> ....
> > There is no state to save between requests if you use TCP
> >other than what there is if you use UDP.
>
> That is wrong if you define "request" as broadly as required by the
> situation. The socket and FD for a DNS/TCP request is created when DNS
> server does a select() and accept() soon after the SYN from the client
> arrives. That FD, the underlying TSP, and the client's IP address,
> sequence number, TCP options,...

I know how TCP works. Like I already said, I happen to have
implemented
it, along with DNS and many other things.
All you mention has nothing to do with states to save related to DNS
as
you claimed. This is the overhead TCP adds to which we both referred
separately.

> >other than what there is if you use UDP. Both transports
> >are defined in RFC1034/1035, the only difference being a length word
> >at the beginning of the data.
>
> that's irrelevant.

Given that now you know there are no states to save between
DNS transactions it is irrelevant indeed.

>
> > You may want to take note that this comes from someone who has
> >implemented a TCP, DNS with caches etc.
>
> Google is your friend.

I tried that - spent the 2-3 minutes I was inclined to - and all I
found
was similar to what I see here. If you have authored some real stuff
it must be harder than that to locate, please indicate what.

> While in theory and special implementations, Van Jacobson's number of
> ~100 cycles per TCP segment exclusive of byte copies and checksums is
> right, in typical practice it is orders of magnitude small. On the
> other hand, searching a DNS cache needs few cycles if you're a rabid
> coder comfortable writing your own tree and hash searching code.

So you want to search the database of the root servers in a few cycles
per request. How many entries per cycle do you actually want to go
through? Sorry but this sounds like you don't have a clue of what
you are talking about.

Didi

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tg...7600228621276/

Original message: http://groups.google.com/group/comp....d?dmode=source

Vernon Schryver wrote:
> Besides, anycast is not the only kind of load balancing in front of
> big DNS servers. Consider a load balancer that even distributes
> incoming packets to a bag of MAC addresses. You'd hope that a load
> balancer would not do that to TCP segments, but doing the right
> thing would require the load balancer to keep state for bazillions
> of DNS/TCP/IP connections.

Or simply do its balancing decisions based on the four-tuple. If we
are talking about bazillions of DNS/TCP/IP connections one probably
gets good distribution from a hash on the four-tuple.

> Someone in the mailing lists suggested hacking a special code for
> very busy DNS servers that would
> - answer all SYNs to port 53 with SYN-ACK without creating a TSP
> or saving any other state,
> - acknowledge everything that seems to want an acknowledgement,
> - assume that the DNS/TCP/IP request would fit in the first and
> only non-trivial segment after the SYN,
> - and generally act as if DNS/TCP/IP were the same as DNS/UDP/IP.

> It would do no retransmitting, which might be hard on DNS clients
> beyond lossy paths.

So long as the ACK of the request was only piggybacked on the segment
carrying the reponse you would be OK. Then in the event of loss of
ACK you would get a retransmit from the client.

> It would naturally defend against the current excitement by the DNS
> client using the additional entropy in its TCP initial sequence
> number. It is such a completely nasty ugly kludge that I love it,
> if it really works.

Is it really sufficient to protect against the spoofing if only the
clients to be keeping state? I guess the 32 bit ISN of TCP is a nice
boost. It would be a nasty ugly kludge. How many more nasty ugly
kludges can dance on the Internet pin-head?

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article ,
Rick Jones wrote:

>> It would do no retransmitting, which might be hard on DNS clients
>> beyond lossy paths.
>
>So long as the ACK of the request was only piggybacked on the segment
>carrying the reponse you would be OK. Then in the event of loss of
>ACK you would get a retransmit from the client.

good point

>Is it really sufficient to protect against the spoofing if only the
>clients to be keeping state? I guess the 32 bit ISN of TCP is a nice
>boost.

The current kludges of less than partial fixes of varying the client's
UDP port number or toggling 0x20 bits is all about state on the client.
The real DNSSEC fix is also about client state if you squint at it from
the right angle.
The server's state is useless, expensive overhead except when the server
recurses. Real DNS/TCP/IP protects against the current cache poisoning
attack only because predicting the client's DNS/TCP initial sequence
numbers to spoof the server's answers is hard in the modern era. For
example, if the client always used an initial sequence number of 1, the
bad guy could spew DNS/TCP segments with bogus answers much like the
bogus DNS/UDP bogus answers. The main difference is that the DNS/TCP
bogus answers would need to be preceded by bogus SYN-ACKs.


> It would be a nasty ugly kludge. How many more nasty ugly
>kludges can dance on the Internet pin-head?

time-wait delays, MSS options, Nagle, congestion control, congestion
avoidance, header prediction, page flipping/zero-copy, timestamps,
extended windows, IPv6 and the rest of the list implies some job security.

oh what a tangled web we weave when first we practice to be compabible.


Vernon Schryver vjs@rhyolite.com

On Tue, 12 Aug 2008 01:20:45 -0700, Didi wrote:

> Vernon Schryver wrote:
>> ....
>> > There is no state to save between requests if you use TCP
>> >other than what there is if you use UDP.
>>
>> That is wrong if you define "request" as broadly as required by the
>> situation. The socket and FD for a DNS/TCP request is created when DNS
>> server does a select() and accept() soon after the SYN from the client
>> arrives. That FD, the underlying TSP, and the client's IP address,
>> sequence number, TCP options,...
>
> I know how TCP works. Like I already said, I happen to have implemented
> it, along with DNS and many other things.
> All you mention has nothing to do with states to save related to DNS
> as
> you claimed. This is the overhead TCP adds to which we both referred
> separately.

I don't see how you can implement DNS over TCP without saving the socket,
thus saving extra state. Which is what Vernon said btw.

M4