[dns-operations] finding the longest encloser

[Olafur Gudmundsson]

The easiest way to discover what zone answer orginates from is to look
at the Signer name in RRSIG records. Unfortunatly this only works for
signed zones :-(

	Olafur



On 17/02/2010 8:13 PM, Crist Clark wrote:
>>>> On 2/16/2010 at 3:50 PM, Jim Reid<jim at rfc1035.com>  wrote:
>> On 16 Feb 2010, at 22:27, Crist Clark wrote:
>>
>>>> The SOA record does not contain the longest existing suffix.  I think
>>>> you really need to know that the root is delegation-centric, or that
>>>> all delegations have a single label, combined with the SOA trick to
>>>> deal with the arpa. special cases.
>>>
>>> Shouldn't it always contain the longest valid zone? I mean, that's
>>> what it's there for right?
>>
>> Yes and no. Once upon a time, I was co-author of a draft that
>> suggested using the SOA record in an NXDOMAIN response to find the
>> closest enclosing delegation. This was to be used in ENUM domain names
>> with ~20 labels and could have contain a handful of delegations:
>> walking up the domain name label at a time to find the deepest
>> delegation point (=>  "closest" default SIP/PSTN terminator) would have
>> been painful.
>>
>> I was told that this was too clever by half and it wasn't acceptable
>> for clients to treat SOA records in this way because they were in the
>> Authority Section. Clients were supposed to only act on whatever was
>> in the Answer Section.
>
> The behavior being discussed seems like something an intermediate
> caching server would implement, not something an end client would
> do.
>
> I can see saying that stub resolvers really have no need to look
> at the auth section, but recursive resolvers use it. If no one is
> supposed to use it, what's the point of including it?
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
>