Re: Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd)

Mark Andrews <[email protected]>
Newsgroups gmane.ietf.dnsext
Message-ID <[email protected]>
In message <[email protected]>, Paul Wouters w
rites:
> On Sat, 19 Oct 2013, Mark Andrews wrote:
> 
> >>> An RFC 5966 server supports persistent TCP but does not advertise this
> >>> fact.
> >>
> >> I hope to have some measurements done in time for Vancouver to see what
> >> the percentage of queries/servers is where this is a problem. That could
> >> help assess whether or not we still need a special indication via edns
> >> or not.
> >
> > Why?  Clients should be able to handle the connection being closed
> > unexpectedly and retry any uncompleted queries.
> 
> I'm trying to reduce dns(sec) latency, not adding more repeating tcp
> failures. If it turns out that most obtained DNS resolvers are useless
> for TCP than there is a need to give a clear indication to a client
> that a resolver does work well.
> 
> The question is how pervasive are rfc 5966 compliant resolvers out
> there, and whether there is a need to advertise those who are.
> 
> Paul

All DNS servers should already handle multiple questions over a TCP
socket.  This is *basic* RFC 1035.  Just send the queries and deal
with the fact that you may have broken servers. 

Adding a new option often the worst thing you can do to fix a failure
to follow specification.  It is definitely not needed to fix this
problem.

Just write a RFC with a title like "Common DNS server errors in
handling queries over TCP" which points out that DNS servers are
expected to handle multiple queries over TCP.  Then a user has a
second clue bat to go beat the vendor over the head with.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.