Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Edward Lewis <[e-mail]>]

To clear up a few points.

On Oct 31, 2014, at 7:08, Stephane Bortzmeyer <[e-mail]> wrote:

> On Thu, Oct 30, 2014 at 03:29:21PM -0400,
> Edward Lewis <[e-mail]> wrote 
> a message of 526 lines which said:
> 
>> This sounds like something related to work attempted in the DBound
>> mail list,
> 
> Doug Barton suggested here to use Dbound-like techniques to optimize
> the work of a qname-minimising resolver. I personally don't think this
> small improvment would be worth the added complication and risks of
> staleness.

I had in mind what Doug suggested.

> You say that not sending a SOA (when requested) is legal? 

A server may, at any time, return REFUSED.  If you want to argue based on the RFCs:

See RFC 1035, section 4.1.1. (Header section format), under RCODE, value 5

As far as not returning at all, that isn’t considered an option by the RFCs and protocol designers but is justified in my eyes under the reality of operations.

>>   292	##Appendix A.  An algorithm to find the zone cut
>> 
>> It's not the zone cut that matters, it's what zones the server
>> answers that matters.
> 
> I disagree. When you want to resolve www.example.com with Qname m12n,
> knowing that example.com and com are on different sides of a zone cut
> is necessary. Knowing that the .com name servers also serve .net is
> useless.

In this case the point was not made well.  What I mean is for a name like this:

www.localschool.K-12.city.county.province.ccTLD. : one name server might serve these zones:

localschool.K-12.city.county.province.ccTLD.
K-12.city.county.province.ccTLD.
county.province.ccTLD.

It’s not the zones that matter, but the set of zones on the server because if you ask this server the full name you will get to the result much faster than targeting the NS records of the zones.

The DNS does not convey the zones on a server - it does report the servers a zone is to be found on (although we know that it might be inaccurate).