Hi Jinmei On Mon, Mar 21, 2016 at 11:38:35AM -0700, 神明達哉 wrote: > At Mon, 21 Mar 2016 19:21:59 +0530, > Mukund Sivaraman <[email protected]> wrote: > > > (1) Section 7.2.1. Authoritative Nameserver: > > > > > When deaggregating to correct the overlap, prefix lengths should be > > > optimized to use the minimum necessary to cover the address space, in > > > order to reduce the overhead that results from having multipe copies > > > of the same answer. As a trivial example, if the Tailored Response > > > for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then > > > the Authoritative Nameserver would need to provide Tailored Responses > > > for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and > > > 1.2.3/24 to B. > > 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.
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.
If the auth had responded instead with 1.2.1/24/20, that would be cached
at address prefix 1.2.0/20 in the resolver's cache and a future query
for 1.2.3/24 would match it.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
