Delivery of non-cached replies

Jakob Blomer jakob.blomer at cern.ch
Wed Oct 21 13:39:18 EDT 2009


Hi,

thanks for the fast reply.

> First of all, I'm very happy to see my software being used by
> significant organizations such as the one that invented the world wide
> web (and, on the side, does some really cool physics that would
> impress even Sheldon from the American sitcom /The Big Bang Theory/).
> :)

After all, Big Bang Theory is not too far from reality...

> full Windows support).  Also, DNS packets received by the VMware
> player guess have their TTLs changed to always be five seconds.

That's what I figured with Fusion on Mac, too, and I am still curious
why it is tweaking TTLs.

> I just looked at this file.  It's a strange binary file (and isn't a
> raw DNS packet; I know what those look like) which I will need to
> install a special program to look at.  Do you have handy tools that
> convert this to ASCII, so that you can post it to the list and we can
> look at it and discuss it on the list?

I captured a couple of dig-requests with tcpdump.  I captured only eth0,
so the loopback traffic between dig and Deadwood is not shown.  It is
only the traffic between Deadwood and the upstream server.  I use
Wireshark to view those dump files.  I also used it to created an ASCII
version under http://jblomer.web.cern.ch/jblomer/dns-nxdomain.txt.

> Does this patch fix the problem for you?  If you confirm that it does,
> I will document the new feature (RTFM isn't very helpful if the
> documentation is incomplete), apply your patch to the stable (2.3)
> branch of Deadwood, forward-port it to the development (2.4) branch of
> Deadwood, and should have time this afternoon to release new snapshots
> of the program.

The patch fixes the problem for me.  By "fix", I mean that I don't run
into a timeout when having it enabled.  The problem is that without the
patch, Deadwood is apparently waiting some time and eventually answers
with a SERVFAIL.  To answer your second post, setting handle_noreply = 0
does not help, because then the application that tries to resolve the
name runs into the timeout.

I am not familiar enough with DNS to tell for sure, but I could imagine
that the reply from the upstream DNS server is just broken enough not to
be accepted by Deadwood.  In principle, as you said, negative caching
with other upstream DNS servers works fine.  In fact, the last
query-response of the tcp dump was with Cern DNS server as upstream
without any problems.

I attached another version of the path according to your coding style
comments (but still without touching the documentation).  The default
value is not to change the current behaviour.

Cheers,
Jakob



diff -u ../../deadwood-2.3.04/src/DwMararc.c ./DwMararc.c
--- ../../deadwood-2.3.04/src/DwMararc.c	2009-05-21 23:02:20.000000000 +0200
+++ ./DwMararc.c	2009-10-21 19:27:28.000000000 +0200
@@ -28,7 +28,7 @@
 /* Number of dictionary parameters in the mararc file */
 #define KEY_D_COUNT 1
 /* Number of numeric parameters in the mararc file */
-#define KEY_N_COUNT 15
+#define KEY_N_COUNT 16

 dwm_fs fsm[DWM_MAX_STATES + 1]; /* Finite state machine */
 dw_str *key_s[KEY_S_COUNT + 1]; /* All of the string dwood2rc parameters */
@@ -72,6 +72,7 @@
 	"num_retries", /* Number of times we try to connect to an upstream
                         * server before giving up */
 	"verbose_level", /* How verbose our logging should be */
+	"deliver_all", /* Deliver non-cachable replies */
         0 };

 char *fsm_desc=dwm_machine;
@@ -425,6 +426,7 @@
 	key_n[DWM_N_resurrections] = 1;
 	key_n[DWM_N_num_retries] = 1;
 	key_n[DWM_N_verbose_level] = 3;
+	key_n[DWM_N_deliver_all] = 0;
 }

 /* Look for a Mararc parameter; -1 if not found/error; 0-n if found
diff -u ../../deadwood-2.3.04/src/DwMararc.h ./DwMararc.h
--- ../../deadwood-2.3.04/src/DwMararc.h	2009-05-21 23:02:20.000000000 +0200
+++ ./DwMararc.h	2009-10-21 13:40:34.000000000 +0200
@@ -45,6 +45,7 @@
 #define DWM_N_resurrections 12
 #define DWM_N_num_retries 13
 #define DWM_N_verbose_level 14
+#define DWM_N_deliver_all 15

 /* Various character classes used by the Mararc parser's finite state
  * machine */
diff -u ../../deadwood-2.3.04/src/DwSocket.c ./DwSocket.c
--- ../../deadwood-2.3.04/src/DwSocket.c	2009-04-21 17:17:28.000000000 +0200
+++ ./DwSocket.c	2009-10-21 14:11:28.000000000 +0200
@@ -58,6 +58,7 @@
 int32_t maradns_uid = 99;
 int32_t maradns_gid = 99;
 int num_retries = 1;
+int deliver_all = 0;

 #ifdef MINGW
 u_long dont_block = 0;
@@ -359,6 +360,7 @@
         maradns_gid = get_key_n(DWM_N_maradns_gid,10,65535,99);
         resurrections = get_key_n(DWM_N_resurrections,0,1,1);
         num_retries = get_key_n(DWM_N_num_retries,0,8,1);
+	deliver_all = get_key_n(DWM_N_deliver_all,0,1,1);	

         if((num_ports & (num_ports - 1)) != 0) {
                 dw_fatal("num_ports must be a power of 2");
diff -u ../../deadwood-2.3.04/src/DwUdpSocket.c ./DwUdpSocket.c
--- ../../deadwood-2.3.04/src/DwUdpSocket.c	2009-04-21
17:27:21.000000000 +0200
+++ ./DwUdpSocket.c	2009-10-21 14:01:29.000000000 +0200
@@ -49,6 +49,7 @@
 extern int min_bind;
 extern int num_ports;
 extern int num_retries;
+extern int deliver_all;

 #ifdef MINGW
 /* Needed for the Windows way of making a socket non-blocking */
@@ -600,7 +601,7 @@
         if((a[2] & 0x02) == 0x00) { /* If not truncated */
 		fflush(stdout);
 #ifndef NOCACHE
-                if(cache_dns_reply(a,count) == -1) {
+                if((cache_dns_reply(a,count) == -1) && (deliver_all ==
0)) {
 			return; /* Bad reply */
 		}
 #endif /* NOCACHE */


More information about the list mailing list