[rbldnsd] NotImpl when AA bit is set in request...

[askthelist at gmail.com]

On Tue, Aug 5, 2008 at 1:22 PM, Michael Tokarev <mjt at tls.msk.ru> wrote:

> askthelist at gmail.com wrote:
> >   rbldnsd is returning "Not Implemented" in responses to requests in
> > which the DNS AA (Authoritative Answer) bit is set... This may seem
> > strange and an odd request, but Is there a way to configure rbldnsd to
> > ignore this bit in requests and respond to the query anyway? If there is
>
> Yes indeed this is strange, more than strange.


Truth is stranger then fiction sometimes...

>
>
> This bit is used for ANSWERS (as it's authoritative ANSWER), it can't
> be set in queries.  Just like some other bits, like RA (recursion
> available).


According to the RFC1035 this should be illegal, yet our Microsoft DNS
Servers with forwards to our local rbldnsd's began sending queries with this
bit set recently, not sure if it has anything do do with the recent dns
patches that were released, but... Heres a debug that shows the bit being
set...

20080804 21:30:35 728 PACKET  0000000002722CA0 UDP Snd x.x.x.x  d42a   Q
[0004 A     NOERROR] A     (3)cnn(3)net(5)multi(5)surbl(3)org(0)
UDP question info
  Socket = 4740, recvd on port (65535)
  Remote addr x.x.x.x, port 53
  Time Query=0, Queued=0, Expire=0
  Buf length = 0x0500 (1280)
  Msg length = 0x0029 (41)
  Message:
    XID       0xd42a
    Flags     0x0400
      QR        0 (QUESTION)
     * OPCODE    0 (QUERY) *
*      AA        1 *
      TC        0
      RD        0
      RA        0
      Z         0
      RCODE     0 (NOERROR)
    QCOUNT    1
    ACOUNT    0
    NSCOUNT   0
    ARCOUNT   0
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name      "(3)cnn(3)net(5)multi(5)surbl(3)org(0)"
      QTYPE   A (1)
      QCLASS  1
    ANSWER SECTION:
      empty
    AUTHORITY SECTION:
      empty
    ADDITIONAL SECTION:
      empty

>
>
> > I couldnt find it and havent been able to find much documentation on the
> > subject. I've sifted through the source code and it seems the relevant
> > code would be in the rbldnsd_packet.c/dns.h source files but since my C
> > skills are non-existant it would be great if someone can provide a hack
> > for me to implement this...
>
> There's no config option for this, and yes it's in the source.  In
> rbldnsd_packet.c file, in function named replypacket(), there's this
> code:
>
>   if (h[p_f1] & (pf1_opcode | pf1_aa | pf1_tc | pf1_qr)) {
>     h[p_f1] = pf1_qr;
>     refuse(DNS_R_NOTIMPL);
>   }
>

> You can just comment it out.  But this is WRONG.  In a way similar to
> the way it drops packets when QR flag is set -- ie, when it's a
> reply, not a query.  Imagine someone sends out a query with a fake
> source address equal to the address of the server itself -- the server
> replies to this packet, and the reply goes back to the same server,
> which now interprets the reply as new query and replies to it and
> so on ad infinitum... The bit you're talking about should NEVER, EVER
> be set in a query, and no sane DNS client software will set it.
> Something's seriously wrong on your client side.


Great, thanks for the info. I seen that bit of code but was unsure how to
manipulate it the way I needed to without breaking anything. I just need a
bandaid until our vendor(Microsoft) can figure out why our server is
behaving in this way and provide us either a solution or a workaround before
our servers start getting banned from making too many dns requests...

>
>
> And by the way, returning NOTIMPL here is questionable as well --
> maybe FORMERR is better.  But in any way it's a clear error,
> clearly wrong packet, and I don't know how to implement its
> processing...
>
> /mjt


Thanks.

>
> _______________________________________________
> rbldnsd mailing list
> rbldnsd at corpit.ru
> http://www.corpit.ru/mailman/listinfo/rbldnsd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.corpit.ru/pipermail/rbldnsd/attachments/20080805/7f9b2bea/attachment.htm