On Mar 24, 2015, at 3:02 PM, Dave Lawrence <[email protected]> wrote: > EDNS / EDNS0 -- The Extension Mechanisms for DNS, defined by > [RFC6891], are an addition to the original message format to allow DNS > agents [which I acknowledge is not defined, but by which I mean to > indicate "any software which speaks DNS"] to specify message sizes > larger than the original 512 octet limit, to expand the response code > space, and to potentially carry additional options that affect the > handling of a query. EDNS can be versioned, but currently the only > version in public use is EDNS0.
Yes, we clearly should define EDNS before we talk about OPT; done in the next draft. > ECS / EDNS client-subnet -- An EDNS option principally for carrying > information from a resolver to an authoritative server about > the general network location of a client of the resolver. This is > generally used by full service resolves who serve clients from a > diverse network topography to get response from authoritative servers > that tailor their responses based on client location. > > [This also seems to be missing as a commonly seen token:] This seems premature given that the whole area is still under discussion. > One thing that has been experience by many of us in different > organizations, and which actually has shown its head within > discussions with IETF people this week who are not in the DNS > community, is that they very, very commonly think of the EDNS > client-subnet option as being "EDNS0". Those of us involved with ECS > constantly try to educate people about this, especially since there > are currently very few EDNS options and this is the only one that > seems to be known by people outside of the DNS community. That's a row you have to hoe on your own, I'm afraid. There are other EDNS options, and the document defining EDNS0 is not all that easy to understand as "this just gives us some extensions". > RRTYPE [RRType?] -- A mnemonic or numeric value representing the type > of data carried in an RR, as defined in [RFC1035] section 3.2, which > impacts how its RDATA is interpreted. The full set of assigned values > is listed at [IANA reference]. > > RDATA -- The data portion of an RR, as defined in [RFC1035]. Its > format and semantics varies by RRTYPE. I'm hesitant to define all of the parts of a record from RFC 1035. Do we split out the subfields of RDATA? Do we also define "Answer section"? Would it be valuable to just list all these "basic terms" from 1035 in one section, and say "read 1035 for the definitions"? > PS: I tend to use NXRRSET as slightly more expressive than NODATA, > though it is an extended rcode for dynamic update. Worth mentioning > along with the NODATA definition, or am I pretty much solo in using > the term this way? Done. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
