AXFR response has IXFR in question

[Mark.Andrews at nominum.com]

	Thanks Jeff,
		      we already have this one in a pool awaiting inclusion
	in 8.2.3-T6B / 8.2.3-REL.

	Mark

>     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
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com