AXFR response has IXFR in question

Jeff Schreiber schreiber at process.com
Fri Jul 7 14:43:38 UTC 2000


    A problem was reported to me from a user with a Windows NT 4.0 SP5
    secondary.  When the secondary tried to do a zone transfer from my
    8.2.3 T5B server, the secondary rejected the transfer with the message:

      Invalid response from master DNS server at 10.0.0.1 during 
      attempted zone transfer of zone aitsi.com. Check DNS Server at
      10.0.0.1 and insure it is properly authoritative for this zone.

    After looking into it, it was quite apparent with a trace:

    Query:
                           19af 0100 0001 0000 0000 0000 ..J+............
                 0130 0130 0331 3237 0769 6e2d 6164 6472 .0.0.127.in-addr
                 0461 7270 6100 00fc 0001                .arpa.....

    Reply:

                           005e 19af 8400 0001 0001 0000 ..I at .^..........
                 0000 0130 0130 0331 3237 0749 4e2d 4144 ...0.0.127.IN-AD
                 4452 0441 5250 4100 00fb 0001 c00c 0006 DR.ARPA.........
                 0001 0009 3a80 002c 094c 4f43 414c 484f ....:..,.LOCALHO
                 5354 000a 506f 7374 6d61 7374 6572 c032 ST..Postmaster.2
                 0000 0001 0000 1c20 0000 0e10 00b8 9200 ....... ........
                 0001 5180 0037 19af 8000 0000 0001 0000 ..Q..7..........
                 0000 0130 0130 0331 3237 0769 6e2d 6164 ...0.0.127.in-ad
                 6472 0461 7270 6100 0002 0001 0009 3a80 dr.arpa.......:.
                 000b 094c 4f43 414c 484f 5354 00        ...LOCALHOST.

    
    The Question is type 0xFC (AXFR).  The Question in the reply is type
    0xFB (IXFR).  The NT 4.0 SP5 zone transfer process is checking that.

    The problem appears to be tied into the STREAM_AXFRIXFR flag.  If I'm
    reading correctly, that flag is intended to be used if an IXFR isn't
    available, so we know to change the type to AXFR during our processing,
    then back to IXFR before we send the response.  However the code never
    bothers to check if the requestor _wanted_ an IXFR query in the first
    place.  So if there isn't IXFR data available, regardless of if the
    requestor asked for an IXFR or an AXFR, we return that the Question
    was an IXFR.

    Fix seemed simple enough.  [I apologize about the dates, our source
    files got copied to a new location and the dates aren't the same as
    the distribution anymore].  I know it fixes the problem I was seeing,
    but I've not tested it with IXFR yet to be sure it still does what
    it's supposed to do.

                                            -Jeff

*** ns_req.c~	Fri Jul  7 10:06:55 2000
--- ns_req.c	Fri Jul  7 10:27:49 2000
***************
*** 1146,1152 ****
  		if (qsp == NULL)
  			return (Finish);
  		else {
! 			if (!ixfr_found) {
  				qsp->flags |= STREAM_AXFRIXFR;
  				hp->qdcount = htons(1);
  			}
--- 1146,1152 ----
  		if (qsp == NULL)
  			return (Finish);
  		else {
! 			if (!ixfr_found && type == ns_t_ixfr) {
  				qsp->flags |= STREAM_AXFRIXFR;
  				hp->qdcount = htons(1);
  			}

--
Jeff Schreiber,            Process Software Corp.
schreiber at mx.process.com   http://www.process.com
      TCPware & MultiNet: Stronger than Ever



More information about the bind-workers mailing list