Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

[神明達哉 <[e-mail]>]

At Tue, 22 Mar 2016 01:15:48 +0530,
Mukund Sivaraman <[e-mail]> wrote:

> > > (1) Section 7.2.1.  Authoritative Nameserver:

> > I'm confused about the revised Section 7.2.1 regarding overlapping
> > prefixes.  The 07 version of the draft now states:
> >
> >    [...]  Because it can't be guaranteed that queries for all
> >    longer prefix lengths would arrive before one that would be answered
> >    by the shorter prefix length, an Authoritative Nameserver MUST NOT
> >    overlap prefixes.
> >
> > But the above "trivial example" seems to talk about what an
> > authoritative nameserver would do if it overlaps prefix...doesn't it
> > simply break the MUST NOT in the first place?
>
> When overlapped address prefixes occur in zone data (the configuration
> provided by an administrator to the authoritative nameserver), the
> authoritative server should resolve the overlap by deaggregating
> prefixes such that the prefixes in the Authoritative Nameserver's reply
> messages do not overlap.

At least to me, "MUST NOT overlap" can't obviously read that way.  I
think some more wording clarification is needed.  Also, what about
the "warn and continue" behavior of this one?

   2.  Alert the operator that the order of queries will determine which
       answers get cached, and either warn and continue or treat this as
       an error and refuse to load the configuration.

If it's not considered a violation of the MUST NOT, I think we need
more explanation here, too.

> The "Authoritative Nameserver MUST NOT overlap prefixes" requirement is
> in the reply messages that it generates. But it can accept overlapping
> prefixes as configuration and deaggregate to non-overlapping prefixes.
>
> > Also (ignoring the MUST NOT), what if a query is sent with a source
> > prefix 1.2.1/24?  The best matching prefix is 1.2.0/20, so isn't the
> > tailored response A with the scope prefix length of 20?  I mean,
> > shouldn't the above deaggregated prefixes be incomplete?
>
> The 1.2.1/24 case would be covered by 1.2.0/23 listed in the example.
> So a query with 1.2.1/24/0 would be replied to with 1.2.1/24/23.

Ah, right, I should have had another cup of coffee before asking it:-)

--
JINMEI, Tatuya