Re: [DNSOP] New version of the DNS terminology draft
On Feb 25, 2015, at 2:54 PM, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: I understand cache-only or caching-only DNS server as being, strictly speaking, one which loads *no* authoritative data. Typically, this is a resolver which populates its cache by initially priming with some root hints configuration, and then walking down the namespace hierarchy via iterative queries for everything else, but I suppose, arguably, a forwarder could also qualify as a cache-only or caching-only DNS server too. Sometimes I've heard the term -- despite being absolute -- being bent to include nameservers which only load a *minimal*, convenience set of authoritative zones, e.g. for localhost, 1.0.0.127.in-addr.arpa, zones of that nature, each of which are usually intended to provide resolution for a single, non-globally-unique name. A stub zone is one in which the source of zone information -- typically in the form of IP addresses from which to fetch the data -- is defined statically within the nameserver configuration, but *not* involving full replication of the zone *or* recursive resolution towards that source, hence distinguishing it from being a slave for the zone, or engaging in any form of forwarding, respectively. Because there is no full replication, whatever contents of the zone exist on the instance configured as a stub for it, are not considered authoritative and the instance does not respond authoritatively for the zone. Given that neither of those terms appear in any RFC, I don't think we want to invent terms like these. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
I understand cache-only or caching-only DNS server as being, strictly speaking, one which loads *no* authoritative data. Typically, this is a resolver which populates its cache by initially priming with some root hints configuration, and then walking down the namespace hierarchy via iterative queries for everything else, but I suppose, arguably, a forwarder could also qualify as a cache-only or caching-only DNS server too. Sometimes I've heard the term -- despite being absolute -- being bent to include nameservers which only load a *minimal*, convenience set of authoritative zones, e.g. for localhost, 1.0.0.127.in-addr.arpa, zones of that nature, each of which are usually intended to provide resolution for a single, non-globally-unique name. A stub zone is one in which the source of zone information -- typically in the form of IP addresses from which to fetch the data -- is defined statically within the nameserver configuration, but *not* involving full replication of the zone *or* recursive resolution towards that source, hence distinguishing it from being a slave for the zone, or engaging in any form of forwarding, respectively. Because there is no full replication, whatever contents of the zone exist on the instance configured as a stub for it, are not considered authoritative and the instance does not respond authoritatively for the zone. - Kevin -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, February 24, 2015 1:53 PM To: Declan Ma Cc: IETF DNSOP WG Subject: Re: [DNSOP] New version of the DNS terminology draft On Jan 20, 2015, at 7:56 AM, Declan Ma m...@zdns.cn wrote: As for 'DNS Servers', I think we should set aside space for 'Cache-only DNS Server' which is pervasive in all kinds of DNS document. Can you clarify what you think a cache-only DNS server is? I'm not seeing how a server can be cache-only without it also doing recursive queries. And as in 'Zones', you mentioned 'Origin'. So, I suggest adding a paragraph to describe 'Default TTL', which is represented as $TTL in zone file. We can add that. Still, 'Stub Zone' is yet another common expression in DNS context. We may put it into this document. I don't find stub zone mentioned in any RFC, so I can't really imagine what that is. Please clarify. --Paul Hoffman ___ 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] New version of the DNS terminology draft
On Feb 4, 2015, at 11:09 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Jan 19, 2015 at 02:16:47PM -0800, Paul Hoffman paul.hoff...@vpnc.org wrote a message of 17 lines which said: Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. I find the definition of Forwarder still confused. I suggest to rewrite it as: DNS forwarder -- When a first resolver receives a DNS query (and cannot directly answers it), then sends the query to a second recursive resolver, instead of directly to the authoritative name servers, this second resolver is called a forwarder. Section 1 of RFC 2308 describes a forwarder as a nameserver used to resolve queries instead of directly using the authoritative nameserver chain. RFC further says The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers.” I do not think this helps. Forwarding is not always a capacity/access issue but policy decision to improve site resolution cache hit ratio among a farm of resolvers. Forwarding resolver by policy does not do recursion but requests upstream to perform recursion. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
On Mon, Jan 19, 2015 at 02:16:47PM -0800, Paul Hoffman paul.hoff...@vpnc.org wrote a message of 17 lines which said: Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. I find the definition of Forwarder still confused. I suggest to rewrite it as: DNS forwarder -- When a first resolver receives a DNS query (and cannot directly answers it), then sends the query to a second recursive resolver, instead of directly to the authoritative name servers, this second resolver is called a forwarder. Section 1 of RFC 2308 describes a forwarder as a nameserver used to resolve queries instead of directly using the authoritative nameserver chain. RFC further says The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Olafur Gudmundsson o...@ogud.com wrote: Forwarding resolver by policy does not do recursion but requests upstream to perform recursion. Aargh no. A forwarding resolver makes RD=1 queries to an upstream resolver. This is a recursive query. The upstream resolver replies with RA=1 which means it supports recursive clients (and so in common parlance it is a recursive server). The upstream resolver performs iterative resolution. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Northwest veering north 5 to 7, occasionally gale 8 at first. Rough or very rough. Showers. Mainly good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
A few years ago at ISC, we spent some hours discussing that the generic term forwarders really had multiple different meanings: https://www.isc.org/blogs/dns-forwarders/ (To give credit, I think most of that is from Jelte and Shane.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
It is a great job. It lists many terms. In order to have some words be understood by newbie of DNS, I think that adding the example for every term in the appendix will be another bonus. For example,for the term of zone cut Zone cut -- The delimitation point between two zones where the origin of one of the zones is the child of the other zone. If there are some examples which show what the zone cuts are, that will be great. Jiankang Yao From: Paul Hoffman Date: 2015-01-20 06:16 To: IETF DNSOP WG Subject: [DNSOP] New version of the DNS terminology draft Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks! Name: draft-hoffman-dns-terminology Revision: 01 Title: DNS Terminology Document date: 2015-01-19 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/ Htmlized: http://tools.ietf.org/html/draft-hoffman-dns-terminology-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01 ___ 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] New version of the DNS terminology draft
At Mon, 19 Jan 2015 14:16:47 -0800, Paul Hoffman wrote: [...] we wanted people to look over the new version and give feedback. Thanks! The introduction presents the definition, The DNS is a simple query-response protocol whose messages in both directions have the same format. Maybe it's just me, but I think a broader definition would be useful for instructional purposes. I'm not thinking here only of teaching students or professional trainees, but also of persuading management. From time to time, I've found I needed to describe the DNS in any of four different ways, according to the aspect needing emphasis in particular circumstances. FWIW, I see the DNS as - a naming scheme for objects on the Internet; - a database representing the names and certain properties of these objects; - an architecture providing distributed maintenance, resilience, and loose coherency for this database; and - a simple query-response protocol (as mentioned in the current draft) implementing this architecture. IHTH Niall O'Reilly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
At Wed, 21 Jan 2015 07:54:18 -0800, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jan 21, 2015, at 6:52 AM, Colm MacCárthaigh c...@allcosts.net wrote: RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I also think views and other implementation specific features confuse things here. A user might have 10 A records defined for a given name; but if their DNS server returns one at a time (say it's using weighted round robin) - I don't think of the 10 as an RRSet; but rather it's 10 RRSets. What's actually sent on the wire is what matters, I think. Note that, when possible, our document is reproducing what is in the standards-track RFCs. You might want a different definition for a term, but if there is a non-confusing definition already, our document should use it. In this case, the RFC 2181 definition is refreshingly clear, and what you are describing would be a thing that is not an RRset and maybe should have a different term. +1. I'd also note that if we extended the definition of the term RRset so it can contain duplicate RDATA, it would break Section 6.3 of RFC4034: [RFC2181] specifies that an RRset is not allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error. I guess there may be other normative text that relies on this definition. So, if we had any specific reason to name the concept of a set of RRs that can contain duplicate RDATA, that should be something different than RRset. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
On Jan 21, 2015, at 10:27 AM, Niall O'Reilly niall.orei...@ucd.ie wrote: I'ld suggest using the following text from RFC1034 (section 4.2.1): The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone. Quoting directly from the source RFCs seems better, yes. Thanks! --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
At Mon, 19 Jan 2015 14:16:47 -0800, Paul Hoffman wrote: Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, So far, great job! but we wanted people to look over the new version and give feedback. Thanks! [snip from http://www.ietf.org/id/draft-hoffman-dns-terminology-01.txt] 7. Zones This section defines terms that are used when discussing zones that are being served or retrieved. Zone -- A unit of organization of authoritative data. [...] Authoritative data -- RRsets in the Answer section of a DNS response that has the AA bit in the response header set to 1. [/snip] This seems to describe how Authoritative data must be marked in a DNS response, rather than to define Authoritative data. Besides, section 6.2.7 of RFC1034 shows a non-authoritative RR in the Answer section of a response which has the AA bit. I'ld suggest using the following text from RFC1034 (section 4.2.1): The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone. Best regards, Niall O'Reilly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Thanks for the suggestions! However: On Jan 21, 2015, at 6:52 AM, Colm MacCárthaigh c...@allcosts.net wrote: RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I also think views and other implementation specific features confuse things here. A user might have 10 A records defined for a given name; but if their DNS server returns one at a time (say it's using weighted round robin) - I don't think of the 10 as an RRSet; but rather it's 10 RRSets. What's actually sent on the wire is what matters, I think. Note that, when possible, our document is reproducing what is in the standards-track RFCs. You might want a different definition for a term, but if there is a non-confusing definition already, our document should use it. In this case, the RFC 2181 definition is refreshingly clear, and what you are describing would be a thing that is not an RRset and maybe should have a different term. We are, in fact, making up some terms in the document, but only in cases where there is a well-known thing that doesn't have a term. I don't think your round-robin example is such a thing, but if others disagree and can come up with a new term, we can add it. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
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
Re: [DNSOP] New version of the DNS terminology draft
Colm MacCárthaigh c...@allcosts.net wrote: TTL: It might be worth using the word 'maximum' in relation to the TTL; I think there is consensus that TTLs may be truncated. Yes, due to memory pressure, server restarts, administrative fiat, DNSSEC (RFC 4035 section 5.3.3), etc. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber, Thames, Dover, Wight, Portland: Southeast, backing east, 4 or 5, occasionally 6 at first in Humber. Slight or moderate, but rough at first in Portland. Showers. Good, occasionally moderate.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
On Wed, Jan 21, 2015 at 7:25 AM, Paul Vixie p...@redbarn.org wrote: RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I also think views and other implementation specific features confuse things here. A user might have 10 A records defined for a given name; but if their DNS server returns one at a time (say it's using weighted round robin) - I don't think of the 10 as an RRSet; but rather it's 10 RRSets. What's actually sent on the wire is what matters, I think. 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? 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. 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. -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Colm MacCárthaigh mailto:c...@allcosts.net Wednesday, January 21, 2015 6:52 AM RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I also think views and other implementation specific features confuse things here. A user might have 10 A records defined for a given name; but if their DNS server returns one at a time (say it's using weighted round robin) - I don't think of the 10 as an RRSet; but rather it's 10 RRSets. What's actually sent on the wire is what matters, I think. 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. 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 http://www.rfc-editor.org/rfc/rfc1996.txt we see: 1.3. This document intentionally gives more definition to the roles of Master, Slave and Stealth servers, their enumeration in NS RRs, and the SOA MNAME field. In that sense, this document can be considered an addendum to [RFC1035]. ... 2.1. The following definitions are used in this document: Slave an authoritative server which uses zone transfer to retrieve the zone. All slave servers are named in the NS RRs for the zone. Master any authoritative server configured to be the source of zone transfer for one or more slave servers. Primary Master master server at the root of the zone transfer dependency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR. There is by definition only one primary master server per zone. Stealth like a slave server except not listed in an NS RR for the zone. A stealth server, unless explicitly configured to do otherwise, will set the AA bit in responses and be capable of acting as a master. A stealth server will only be known by other servers if they are given static configuration data indicating its existence. Notify Set set of servers to be notified of changes to some zone. Default is all servers named in the NS RRset, except for any server also named in the SOA MNAME. Some implementations will permit the name server administrator to override this set or add elements to it (such as, for example, stealth servers). 2.2. The zone's servers must be organized into a dependency graph such that there is a primary master, and all other servers must use AXFR or IXFR either from the primary master or from some slave which is also a master. No loops are permitted in the AXFR dependency graph. 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. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Paul, As for 'DNS Servers', I think we should set aside space for 'Cache-only DNS Server' which is pervasive in all kinds of DNS document. And as in 'Zones', you mentioned 'Origin'. So, I suggest adding a paragraph to describe 'Default TTL', which is represented as $TTL in zone file. Still, 'Stub Zone' is yet another common expression in DNS context. We may put it into this document. Declan Ma ZDNS Ltd. 4, South 4th Street, Zhongguancun, Haidian, Beijing 100190, China 在 2015年1月20日，上午6:16，Paul Hoffman paul.hoff...@vpnc.org 写道： Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks! Name: draft-hoffman-dns-terminology Revision: 01 Title:DNS Terminology Document date:2015-01-19 Group:Individual Submission Pages:14 URL: http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/ Htmlized: http://tools.ietf.org/html/draft-hoffman-dns-terminology-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01 ___ 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] New version of the DNS terminology draft
All, This seems like a tremendously useful document to have out there. Thanks to the authors for the effort and I suspect discussion on the list would be helpful. As a general reminder, we had a very productive meeting in Honolulu, and now we're about halfway from there to Dallas (somewhere just west of LA? :-)) For authors, editors, and reviewers-- it'll be agenda-bashing time before you know it, let's start now and beat the rush! (And yes that means it's also time to start letting your chairs know what we can do to support progress on new drafts or those already in the pipeline.) thanks, Suzanne On Jan 19, 2015, at 5:16 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks! Name: draft-hoffman-dns-terminology Revision: 01 Title:DNS Terminology Document date:2015-01-19 Group:Individual Submission Pages:14 URL: http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/ Htmlized: http://tools.ietf.org/html/draft-hoffman-dns-terminology-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01 ___ 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] New version of the DNS terminology draft
Oh, It's a great work and helpful as a collection of important DNS terminology. It's not easy to choose the terminology from massive DNS-related RFCs. By the way, I notice the Priming is not included in the draft. I think it is a common jargon(not documented yet) used in the community. There maybe other jargon like that. Davey On Tue, Jan 20, 2015 at 6:16 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks! Name: draft-hoffman-dns-terminology Revision: 01 Title: DNS Terminology Document date: 2015-01-19 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/ Htmlized: http://tools.ietf.org/html/draft-hoffman-dns-terminology-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01 ___ 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] New version of the DNS terminology draft
Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks! Name: draft-hoffman-dns-terminology Revision: 01 Title: DNS Terminology Document date: 2015-01-19 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/ Htmlized: http://tools.ietf.org/html/draft-hoffman-dns-terminology-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
