[dns-operations] DNSSEC and qmail

[Mark Andrews]

In message <F1FCB202-D9E7-4CBC-8DBE-9622310B1E92 at dnss.ec>, Roy Arends writes:
> On Oct 8, 2009, at 1:36 PM, Tony Finch wrote:
> 
> > On Thu, 8 Oct 2009, Roy Arends wrote:
> >>
> >> This is odd.
> >>
> >> What cname?
> >
> > It's asking for cam.ac.uk. IN ANY when trying to canonicalize the
> > recipient domain.
> 
> I don't understand.
> 
> >
> >> Second, I'd expect qmail to talk to resolver. resolvers generally  
> >> trip the
> >> response to stubs to fit a 512 udp message.
> >
> > They do?
> 
> roy$ dig +norec cam.ac.uk any
> 
> ; <<>> DiG 9.4.3-P3 <<>> cam.ac.uk any
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25615
> ;; flags: qr ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 12
> 
> ;; QUESTION SECTION:
> ;cam.ac.uk.			IN	ANY
> 
> ;; ANSWER SECTION:
> cam.ac.uk.		12157	IN	NS	dns0.cl.cam.ac.uk.
> cam.ac.uk.		12157	IN	NS	authdns0.csx.cam.ac.uk.
> cam.ac.uk.		12157	IN	NS	dns1.cl.cam.ac.uk.
> cam.ac.uk.		14090	IN	SOA	authdns0.csx.cam.ac.uk.  
> hostmaster.ucs.cam.ac.uk. 1254988693 14400 3600 604800 14400
> cam.ac.uk.		12157	IN	NS	ns2.ic.ac.uk.
> cam.ac.uk.		12157	IN	NS	dns0.eng.cam.ac.uk.
> cam.ac.uk.		12157	IN	MX	7 mx.cam.ac.uk.
> cam.ac.uk.		12157	IN	NS	bitsy.mit.edu.
> cam.ac.uk.		12157	IN	NS	authdns1.csx.cam.ac.uk.
> 
> ;; ADDITIONAL SECTION:
> mx.cam.ac.uk.		75702	IN	A	131.111.8.145
> mx.cam.ac.uk.		75702	IN	A	131.111.8.141
> dns0.cl.cam.ac.uk.	21001	IN	A	128.232.0.19
> mx.cam.ac.uk.		75702	IN	A	131.111.8.146
> mx.cam.ac.uk.		75702	IN	A	131.111.8.140
> bitsy.mit.edu.		21357	IN	A	18.72.0.3
> authdns1.csx.cam.ac.uk.	85801	IN	A	131.111.12.37
> dns1.cl.cam.ac.uk.	21001	IN	A	128.232.0.18
> mx.cam.ac.uk.		75702	IN	A	131.111.8.147
> ns2.ic.ac.uk.		84738	IN	A	155.198.142.82
> authdns0.csx.cam.ac.uk.	85801	IN	A	131.111.8.37
> dns0.eng.cam.ac.uk.	85820	IN	A	129.169.8.8
> 
> ;; Query time: 18 msec
> ;; SERVER: x.x.x.x#53(x.x.x.x)
> ;; WHEN: Thu Oct  8 13:37:27 2009
> ;; MSG SIZE  rcvd: 451
> 
> > Looking at the code I think what is happening is that the stub  
> > resolver is
> > getting a truncated UDP response, and retrying with TCP. The stub  
> > resolver
> > truncates responses that don't fit in the caller's buffer by just  
> > chopping
> > off the end (much less gracefully than a recursive server truncates  
> > a UDP
> > response) and when qmail tries to parse the chopped packet it fails  
> > with a
> > temporary error.
> 
> 
> Wow, that is even more broken than I thought.

Not really.  The resolver library returns the number of bytes read
so you know before you start parsing that you should re-try the
query with a bigger buffer.  Lots of library routines that are
handed a too small buffer do the same thing.  It's up to the
application to look at the responses it gets back and do something
sensible with them.  It's not hard to get this right.

	unsigned char *b, buf[512];
	size_t buflen;

	b = buf;
	buflen = sizeof(buf);

 again:
	n = res_query(..., b, buflen);
	if (n < 0) 
		error
	else if (n > buflen)) {
		if (b != buf)
			free(b);
		b = malloc(n);
		if (b != NULL) {
			buflen = n;
			goto again;
		}
		error
	} else
		you have the complete response.

	if (b != buf)
		free(b);

Otherwise you can just use a 64k buffer.

Mark

> Roy
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org