underscores and 8.2.2-P5

Ted_Rule at flextech.co.uk Ted_Rule at flextech.co.uk
Fri Dec 3 09:38:47 UTC 1999



Another possibility is to perform the ns_nameok() on the query before
the query is forwarded, and return REFUSED - or maybe even FORMERR instead.

I believe it would require slightly more coding than the 5-liner shown below -
but probably
not much more... You should be able to do it in ns_req.c just before it calls
ns_forw() - I think.

That way any legal answer which reaches the cache is never checked by
ns_nameok() again,
which presumably will give a performance benefit.

( The idea of returning FORMERR instead of REFUSED for query section anomalies
has always appealed to me, but I can't say I'm sure it's RFC compliant so it
might lead
to further problems with client resolvers. The argument in favour of it is that
it provides
a way for a client resolver to discriminate between a permanent error in the
query and
a temporary error in the response.  )



Ted Rule,
Flextech Television.






LaMont Jones <lamont at security.hp.com> on 01/12/99 20:49:29

To:   Mark_Andrews at iengines.com
cc:   LaMont Jones <lamont at hp.com>, bind-workers at isc.org, lamont at security.hp.com
      (bcc: Ted Rule/160GPS/Flextech/UK)

Subject:  Re: underscores and 8.2.2-P5



>    I suspect the best way to "fix" this would be to look at the
>    query and refuse to answer.  I would also have an acl which
>    controls when the test is performed.

I added 'check-names request {fail | warn | ignore}', and then went to
change the docs and found this in options.html:

    If <CODE>check-names response fail</CODE> has been specified, and
    answering the client's question would require sending an invalid name
    to the client, the server will send a REFUSED response code to the
    client.

Based on that, since we would be returning an invalid name, we should be
returning REFUSED.  The only reason we return the answers is because we
don't run through ns_nameok until we get a response.  One solution is to
apply the patch below, which subjects the request to verification before
looking for it in the cache.

Another solution (which slows down startup a bit, but gets out of
req_query() and restores some performance...)  would be to modify the
startup phase to:
1. notice if there were any CNAME's with owners that fail res_ownok()
   during the load, and, if so, then once __all__ zones are loaded,
2. make a pass through the cache and verify that any such CNAME's point
   to things whose types permit the otherwise invalid owner of the CNAME,
   or which are not found in the cache.  (Either we know that it's
   NXDOMAIN, or we'll catch it when the response comes in from the auth
   NS.)

Being strapped for time, and having nameserver that are not too overloaded,
I'm going to leave it at the trivial, somewhat performance impacting patch.

Again, here is the offending cache data:
;; ANSWER SECTION:
a_1.example.com.        1D IN CNAME     b.example.com.
b.example.com.          1D IN A         10.0.0.1

lamont

--- ns_req.c.orig   Fri Oct 15 13:49:04 1999
+++ ns_req.c   Wed Dec  1 12:54:23 1999
@@ -643,6 +643,11 @@
     afterq = *cpp;
     qtypeIncr(type);

+    if (!ns_nameok(NULL, dnbuf, class, NULL, response_trans,
+                ns_ownercontext(type, response_trans),
+                dnbuf, from.sin_addr)) {
+         return (Refuse);
+    }
     /*
      * Process query.
      */





*****************************************************************
This E-mail message, (including any attachments), is intended
only for the person or entity to which it is addressed,
and may contain confidential information.

If you are not the intended recipient, any review, retransmission,
disclosure, copying, modification or other use of this E-mail message
or attachments is strictly forbidden.

If you have received this E-mail message in error, please contact the
author and delete the message and any attachments from your computer.

You are also advised that the views and opinions expressed in this E-mail
message and any attachments are the author's own, and may not reflect the
views and opinions of FLEXTECH Television.
*****************************************************************



More information about the bind-workers mailing list