On Fri, Jun 01, 2018 at 11:06:48AM -0700, 神明達哉 wrote:
> > > - Section 4.4
> > >
> > > The zone digest is calculated by concatenating the canonical on-the-
> > > wire form of RRs in the zone, in the order described above, subject
> > > to the inclusion/exclusion rules described below, and then applying
> > > the digest algorithm:
> > >
> > > I wonder whether glue records are included in these RRs. Either
> > > way, it would be better to clarify the point.
> >
> > If we say "calculated by concatenating ... all RRs in the zone" is that
> > sufficient?
>
> I'd be even more explicit, like 'all RRs in the zone including glue
> records' or 'all RRs in the zone including those on and below a zone
> cut'.
>
> BTW, there may be some interesting corner cases related to this point.
> If we configure the 'example.com' zone with the following records:
>
> d.example.com. IN DNAME d.example.org.
> a.d.example.com. IN AAAA 2001:db8::1
>
> then, should the AAAA record be included in the digest? BIND 9
> doesn't consider it an error, does load it into memory and transfer it
> via AXFR, and, IIRC, would use it to answer queries if the DNAME is
> removed via DDNS or IXFR. So this question has a practical
> implication at least for such an implementation.
RFC 6672 (DNAME) seems to contradict itself for this.. it first says:
> 2.4. Names next to and below a DNAME Record
>
> Resource records MUST NOT exist at any subdomain of the owner of a
> DNAME RR.
Then, it continues and says:
> A server MAY refuse to load a zone that has data at a
> subdomain of a domain name owning a DNAME RR.
Further:
> 5.2. Dynamic Update and DNAME
>
> DNAME records can be added, changed, and removed in a zone using
> dynamic update transactions. Adding a DNAME RR to a zone occludes
> any domain names that may exist under the added DNAME.
It is clear that UPDATE introducing a DNAME could cause some RRs to be
occluded but remain part of the zone. Such zones written to a master
file should still be loadable from a usability point of view. I guess
the RFC meant to say in 2.4 that "answers MUST NOT be served for any
subdomain of the owner of a DNAME RR" vs. "records MUST not exist".
It looks to me that BIND does the right thing, and the records must be
considered part of the zone, and should be digested.
Similarly with "NS" too in RFC 2136:
> 7.18. Previously existing names which are occluded by a new zone cut
> are still considered part of the parent zone, for the purposes of
> zone transfers, even though queries for such names will be referred
> to the new subzone's servers.
Mukund
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
