> On Thursday, May 29, 2014 6:53 PM, Jiann-Ming Su <su_...@yahoo.com> wrote:
> >
>
>
>
>
>
>> On Thursday, May 29, 2014 6:32 PM, Mark Andrews <ma...@isc.org>
> wrote:
>> >
>> In message <53879683.2080...@chrysler.com>, Kevin Darcy writes:
>>> Why the different RCODES? See RFC 2308. Short version: the
>> "NODATA"
>>> response occurs when the QNAME exists, but no records match QTYPE. It
>>> will also occur if the QNAME is merely a "branch" to
> something
>> further
>>> down in the hierarchy (a so-called "empty non-terminal"),
> and
>> owns no
>>> records of its own.
>>>
>>> I'm not sure why NODATA would inhibit search-suffixing, but I just
>
>>> confirmed on a Linux platform that it does. Weird.
>>>
>>> - Kevin
>>
>> Actually is it perfectly logical and fixes a long standing security
>> bug. A name should refer to a single node in the DNS not multiple
>> nodes depending upon the query type. A search should always end
>> on the same node independent of query type.
>>
>> What is broken is putting a bare SRV prefix into res_search.
>> res_search was not designed for that type of searching and doing
>> so introduces the sort of security errors talked about in RFC 1535.
>>
>
> Mark,
>
> Thanks again for your insights. The troublesome app is the same one you
> responded to me about back in February when I was asking about recursion and
> auth responses. While it does appear the app may not be following best
> practices in its DNS queries, do you have insights as to why BIND would
> respond
> NoError on one query and NXDomain on another?
>
> I'm reading through RFC 1535 now and will forward that along to the
> application owners.
>
Just finished reading RFC 1535 and thought about your point on res_search. I
wonder if the difference is the search list in /etc/resolv.conf. I don't have
access to those systems that the app runs on, so I'm only looking at the DNS
side of it.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
