Re: TCP connections to DJBDNS

Jakob Hirsch <[email protected]>
Newsgroups gmane.network.djbdns
Message-ID <[email protected]>
Dean Anderson wrote:

>>> This is right, BUT---I think the consensus on DNSEXT was that
>>> implementations must support TCP or ENDSO, and DNSSEC requires TCP or
>>> ENDSO.  

BTW, last sentence is wrong. DNSSEC _requires_ EDNS0, not only because
the RFC says so, but because there's no place in the standard DNS header
for the DO-Flag.

>> Well, I don't know about that. Is that documented anywhere or is 
>> somebody preparing a RFC or something to share the enlightenment with 
>> the rest of the internet?
> Hmm. RFC4033 mentions fallback to TCP; as does RFC2181. But neither
> explicitly state TCP is required.  All that is required by RFC4033 is
> EDNSO for the DO and message size options. However the maximum EDNSO
> message size can be at most 8192 

Where do you get that from? I read no limit, so it would be 64k.
Anyway, it seems that a EDNS0 client can still have a limit of 512
octets, since 2671 specifies no lower limit. So, in theory, a DNSSEC
(and therefore EDNS0) client could query with such a limit, which the
server would have to reply with a truncated answer, so the client is
entitled to use tcp. But that's all very unlikely, and you don't have to
support every brain-deadness.

> and the maximum supported by a server can be less than that. 
> The implication is that a fallback to TCP is
> inherently unavoidable.  

Only for some unrealistic border case. And if you use DNSSEC, of course,
which the OP nothing wrote about.

> I don't know of anything written that makes TCP
> _required_, but I think most people would agree that it is a necessity.  

I would say, if you use DNS, also support tcp, only to be on the safe
side. If you use AXFR, you need it anyway.
But AFAICS there is no real need for it. All I see in my logs of the
last few months is either AXFR or invalid. So there is absolutely no
"necessity" for it.

>>> I am also thinking about changes to dnscache to enable one to
>>> configure it to accept UDP queries, but prefer TCP for recursion.  
>>> Thoughts?
>> This would be a violation of RFC 1123 (as mentioned above). And it
>> would put additional load on DNS servers.
> It doesn't violate RFC1123: Section 6.1.3.2:
> 
>  	"but it SHOULD NOT
>          refuse to service a TCP query just because it would have
>          succeeded with UDP."

It says "refuse", which means it could answer a specific query, but
decides not to. And "SHOULD" is not "MUST". As I quoted, it also say
"DNS servers ... SHOULD be able to service TCP queries", but not MUST.
On the contrary, it says "DNS resolver or server ... MUST send a UDP
query first."

> It goes on to say:
> 
>         "By private agreement, name servers and resolvers MAY arrange
>          to use TCP for all traffic between themselves."

By private agreement, you can do almost everything.
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.