[DNSOP] Brief addition to terminology-bis draft
Hi all, During the IESG review, Adam Roach noticed that draft-ietf-dnsop-terminology-bis talked about “class" but never defined it. This seemed to the authors and chairs like a reasonable thing to fix. It’s also important enough that we want WG review, but not extensive enough to require a new LC. Here's the definition that the authors would like to add to the document: Class: A class "identifies a protocol family or instance of a protocol" (Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a class as well as the type, so that we can allow parallel use of different formats for data of type address." (Quoted from [RFC1034], Section 2.2). In practice, the class for nearly every query is "IN". There are some queries for "CH", but they are usually for the purposes of information about the server itself rather than for a different type of address. Please let us know your opinions yea or nay by Monday, Sept. 10, midnight UTC. Thanks, Suzanne (For the chairs) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brief addition to terminology-bis draft
Suzanne Woolf wrote: Hi all, During the IESG review, Adam Roach noticed that draft-ietf-dnsop-terminology-bis talked about “class" but never defined it. This seemed to the authors and chairs like a reasonable thing to fix. It’s also important enough that we want WG review, but not extensive enough to require a new LC. Here's the definition that the authors would like to add to the document: Class: A class "identifies a protocol family or instance of a protocol" (Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a class as well as the type, so that we can allow parallel use of different formats for data of type address." (Quoted from [RFC1034], Section 2.2). In practice, the class for nearly every query is "IN". There are some queries for "CH", but they are usually for the purposes of information about the server itself rather than for a different type of address. Please let us know your opinions yea or nay by Monday, Sept. 10, midnight UTC. i don't think this def'n serves the need. we need to speak more truth: "The Class tag was weakly defined, such that either a zone can have data in multiple classes, or each class can have its own zone cut hierarchy, and so neither interpretation can be relied upon by DNS protocol implementers." then go on to "in practice..." -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brief addition to terminology-bis draft
RFC 1035 Section 5.2 limits a zone to be single class. > On 4 Sep 2018, at 1:34 am, Paul Vixie wrote: > > > > Suzanne Woolf wrote: >> Hi all, >> >> During the IESG review, Adam Roach noticed that >> draft-ietf-dnsop-terminology-bis talked about “class" but never defined >> it. This seemed to the authors and chairs like a reasonable thing to >> fix. It’s also important enough that we want WG review, but not >> extensive enough to require a new LC. >> >> Here's the definition that the authors would like to add to the document: >> >> >>Class: >>A class "identifies a protocol family or instance of a protocol" >>(Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a >>class as well as the type, so that we can allow parallel use of >>different formats for data of type address." (Quoted from [RFC1034], >>Section 2.2). In practice, the class for nearly every query is "IN". >>There are some queries for "CH", but they are usually for the >>purposes of information about the server itself rather than for a >>different type of address. >> >> Please let us know your opinions yea or nay by Monday, Sept. 10, >> midnight UTC. > > i don't think this def'n serves the need. we need to speak more truth: > > "The Class tag was weakly defined, such that either a zone can have data in > multiple classes, or each class can have its own zone cut hierarchy, and so > neither interpretation can be relied upon by DNS protocol implementers." > > then go on to "in practice..." > > -- > P Vixie > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
6. Cryptographic Hash Requirements The cryptographic hash algorithm used SHOULD provide the following properties: 1. Well known algorithm with implementations easily available. 2. Trusted algorithm with resistance to collision attacks. 3. Minimize output length for efficient storage in the TIMEOUT resource record. While computational complexity is always a consideration when selecting algorithms, the frequency of this calculation is intended to be low volume and, therefore, this property is of reduced importance. SHAKE128 does not meet these requirements. In OPENSSL it is only available in pre-release code. It will be years before OPENSSL-1.1.1 is the OPENSSL release for most operating systems. We (ISC) haven’t started working out what OPENSSL-1.1.1 breaks yet. OPENSSL-1.1.0 broke lots of existing code. Lots of code required re-writing to work with OPENSSL-1.1.0 as it broke backwards compatibility with OPENSSL-1.0.x. Please pick hash algorithms that are already USED by DNS. The results can be truncated if you are worried about space. And no it isn’t as easy as just calling OPENSSL. PKCS#11 providers also need to support the hash algorithm. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brief addition to terminology-bis draft
Actually, 5.2 suggests that a master file (not zone) should contain a single class and single SOA record. That’s not the same thing as limiting a zone to a single class AFAICT. Mike On Mon, Sep 3, 2018 at 18:49 Mark Andrews wrote: > RFC 1035 Section 5.2 limits a zone to be single class. > > > On 4 Sep 2018, at 1:34 am, Paul Vixie wrote: > > > > > > > > Suzanne Woolf wrote: > >> Hi all, > >> > >> During the IESG review, Adam Roach noticed that > >> draft-ietf-dnsop-terminology-bis talked about “class" but never defined > >> it. This seemed to the authors and chairs like a reasonable thing to > >> fix. It’s also important enough that we want WG review, but not > >> extensive enough to require a new LC. > >> > >> Here's the definition that the authors would like to add to the > document: > >> > >> > >>Class: > >>A class "identifies a protocol family or instance of a protocol" > >>(Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a > >>class as well as the type, so that we can allow parallel use of > >>different formats for data of type address." (Quoted from [RFC1034], > >>Section 2.2). In practice, the class for nearly every query is "IN".. > >>There are some queries for "CH", but they are usually for the > >>purposes of information about the server itself rather than for a > >>different type of address. > >> > >> Please let us know your opinions yea or nay by Monday, Sept. 10, > >> midnight UTC. > > > > i don't think this def'n serves the need. we need to speak more truth: > > > > "The Class tag was weakly defined, such that either a zone can have data > in multiple classes, or each class can have its own zone cut hierarchy, and > so neither interpretation can be relied upon by DNS protocol implementers.." > > > > then go on to "in practice..." > > > > -- > > P Vixie > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brief addition to terminology-bis draft
Actually it is. A master file is a zone transfer mechanism. Mark > On 4 Sep 2018, at 2:29 pm, StJohns, Michael wrote: > > Actually, 5.2 suggests that a master file (not zone) should contain a single > class and single SOA record. That’s not the same thing as limiting a zone to > a single class AFAICT. > > Mike > > > On Mon, Sep 3, 2018 at 18:49 Mark Andrews wrote: > RFC 1035 Section 5.2 limits a zone to be single class. > > > On 4 Sep 2018, at 1:34 am, Paul Vixie wrote: > > > > > > > > Suzanne Woolf wrote: > >> Hi all, > >> > >> During the IESG review, Adam Roach noticed that > >> draft-ietf-dnsop-terminology-bis talked about “class" but never defined > >> it. This seemed to the authors and chairs like a reasonable thing to > >> fix. It’s also important enough that we want WG review, but not > >> extensive enough to require a new LC. > >> > >> Here's the definition that the authors would like to add to the document: > >> > >> > >>Class: > >>A class "identifies a protocol family or instance of a protocol" > >>(Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a > >>class as well as the type, so that we can allow parallel use of > >>different formats for data of type address." (Quoted from [RFC1034], > >>Section 2.2). In practice, the class for nearly every query is "IN". > >>There are some queries for "CH", but they are usually for the > >>purposes of information about the server itself rather than for a > >>different type of address. > >> > >> Please let us know your opinions yea or nay by Monday, Sept. 10, > >> midnight UTC. > > > > i don't think this def'n serves the need. we need to speak more truth: > > > > "The Class tag was weakly defined, such that either a zone can have data in > > multiple classes, or each class can have its own zone cut hierarchy, and so > > neither interpretation can be relied upon by DNS protocol implementers." > > > > then go on to "in practice..." > > > > -- > > P Vixie > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brief addition to terminology-bis draft
Other parts of the doc say that some rr types are class specific and others are universal. There an implication that class affects rdata format within a universal rr type. It's incoherent as hell. The reason we don't use it is it's poor definition. Incompatible implmentations could all be right according to the doc. Thus my proposed wording. Is anyone arguing that the spec is coherent on this topic? If not let's move on. - Original Message - From: "StJohns, Michael" Sent: 9/4/18 - 1:29 PM To: Mark Andrews Subject: Re: [DNSOP] Brief addition to terminology-bis draft > Actually, 5.2 suggests that a master file (not zone) should contain a > single class and single SOA record. That’s not the same thing as limiting > a zone to a single class AFAICT. > > Mike > > > On Mon, Sep 3, 2018 at 18:49 Mark Andrews wrote: > >> RFC 1035 Section 5.2 limits a zone to be single class. >> >> > On 4 Sep 2018, at 1:34 am, Paul Vixie wrote: >> > >> > >> > >> > Suzanne Woolf wrote: >> >> Hi all, >> >> >> >> During the IESG review, Adam Roach noticed that >> >> draft-ietf-dnsop-terminology-bis talked about “class" but never defined >> >> it. This seemed to the authors and chairs like a reasonable thing to >> >> fix. It’s also important enough that we want WG review, but not >> >> extensive enough to require a new LC. >> >> >> >> Here's the definition that the authors would like to add to the >> document: >> >> >> >> >> >>Class: >> >>A class "identifies a protocol family or instance of a protocol" >> >>(Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a >> >>class as well as the type, so that we can allow parallel use of >> >>different formats for data of type address." (Quoted from [RFC1034], >> >>Section 2.2). In practice, the class for nearly every query is "IN".. >> >>There are some queries for "CH", but they are usually for the >> >>purposes of information about the server itself rather than for a >> >>different type of address. >> >> >> >> Please let us know your opinions yea or nay by Monday, Sept. 10, >> >> midnight UTC. >> > >> > i don't think this def'n serves the need. we need to speak more truth: >> > >> > "The Class tag was weakly defined, such that either a zone can have data >> in multiple classes, or each class can have its own zone cut hierarchy, and >> so neither interpretation can be relied upon by DNS protocol implementers.." >> > >> > then go on to "in practice..." >> > >> > -- >> > P Vixie >> > >> > ___ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
