Re: TCP connections to DJBDNS (fwd)

On Mon, 26 Jan 2009, Jakob Hirsch wrote:

> 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.

You are correct. Of course, DNSSEC also requires _much_ larger packet 
sizes to send all the signatures and related RRs.

> >> 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.

You're right that by RFC2671 there is no limit and a 16bit field size.  
However UDP fragment reassembly puts a practical limit on the maximum
size at around 8k. I've heard 9K for some

I suggest you look at DNSOP archives for Feb 2005 on this subject:
Re: [dnsop] comments on draft-fujiwara-dnsop-bad-dns-auth-01 
particularly messages by Mark Andrews and [email protected].


> > 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.

??? Dnscache supports only 4096, I think, and 512 before that.  That's
not too unrealistic.

> > 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.

Sure, you can say that. Some disagree with you on the necessity, 
thinking that it is a practical necessity.  Indeed, it sounds like you 
agree that DJBDNS should support TCP 'to be on the safe side'.  That's 
good enough for me.

> 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.

Again, many disagree. And my point is that being able to secure DNS from
all but MITM is a genuine benefit, that creates a real need 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."

Yes, I know. My point is that the consensus is developing to say "MUST". 
So a software implementation should be moving toward supporting TCP.


> > 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.

Exactly.  And the software implementation would want to be able support
that.  Recall, we are discussing what DJBDNS should be able to do in
software, not what you personally want to do on your site.

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000