> Colm MacCárthaigh <mailto:c...@allcosts.net> > Wednesday, January 21, 2015 8:36 AM > > > On Wed, Jan 21, 2015 at 7:25 AM, Paul Vixie <p...@redbarn.org > <mailto:p...@redbarn.org>> wrote: > > > if their server returns only one RR at a time, then there are ten > RRsets, as you say. however, such a server would not be speaking > the DNS protocol as defined, if it starts from a zone file or zone > transfer where there is within the zone ten RR's for a given name. > so, by definition, the current text is correct. > > > If there are two zones for the same name, with different views, do the > RRs of a given name and type in both zones form a single rrset? ...
views are outside of the protocol, and i don't think a dns terminology document should talk about them at all. > I don't think so. Zone files aren't a requirement of the DNS protocol > either; and I don't think there's any case to be made that the > configuration of multiple rrsets for the same name/type is not > speaking the DNS protocol as defined. to my credit, i wrote "or a zone transfer". that means if you are optionally receiving a zone (as defined in the protocol) or optionally loading a zone file (as defined in the protocol), then the meaning of a set of rr's in that zone transfer session or that zone file is as described by the protocol, and if you subset that set of rr's when sending a response to a query matching that name and type, then you are acting outside of the protocol. in this case as in the above case, i don't think a dns terminology document should describe things that are outside of the protocol. > > >> Stealth server: this definition seems a bit contradictory. Starts out >> by saying it's a slave, but then says it can also be a master. > > in other words, what makes you a master is that someone is transferring > from you. the primary master is the only master that by definition cannot > also be a slave. the terms "master" and "slave" refer to protocol roles > within the AXFR/IXFR transaction. > > It might be worth updating the text to say "is often also a master" to > make the non-exclusivity between master and slave a bit more clear. i think so too. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
