Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-push-13.txt

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Nov 2017 05:37:56 -0500

Hi,

I've just been looking at this draft again and, as it happens, I've
been struggling over in DNSOP with the question of referrals.  So I
realised there may be a small wrinkle in section 6.1.

There are a few possible (protocol-permitted) responses to a query for
_printers._tcp.foo.example.com:

    1.  An answer.  In this case the Answer section is populated, and
    the client has discovered that there is a zone cut at
    _printers._tcp.foo.example.com.  This seems fantastically unlikely
    for our case, but it's a possibility.

    2.  Name Error (NXDOMAIN).  This is also an answer, actually.  It
    says the name _printers._tcp.foo.example.com doesn't exist,
    period, so the client knows that the name doesn't exist.  I'm not
    actually sure why step 3 in the algorithm is needed, though it
    might be to try to foil broken servers that send NXDOMAIN when
    they should not.  Anyway, if you're looking for a printer and you
    get NXDOMAIN from the query for _printers._tcp.foo.example.com,
    then it doesn't exist.  

    3.  NOERROR/NODATA.  This actually seems like the most likely case
    when there is a printer: there won't be a zone cut at
    _printers._tcp.foo.example.com, but there will be an RR there.

    4.  A referral.  This is the response that is actually desired in
    step 1, I think ("The goal is to determine the authoritative
    server for _printers._tcp.foo.example.com.").  What we're actually
    looking for is a referral response, which may well not contain the
    SOA but instead the NS records in the authority section.

I think the wrinkle in step 2 in this section is that (4) won't
necessarily return the SOA record as desired, but instead the NS
RRset.  The section is correct that you want to find the place that
can answer with the SOA (such a server really is the authoritative
server), but you get there by stumbling across the NS records n the
Authority section.

I hope that makes sense.

There might be a tiny value in adding a sentence to section 3, noting
that clients that are too aggressive might find themselves cut off or
even locked out by server policies (those policies seem already to be
contemplated in draft-ietf-dnsop-session-signal-04).  I don't know how
useful that would be, though, and it's not a big deal.

Other than this, I think the draft looks in pretty good shape, and I
like this work.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]