Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-root-loopback
Brian Dickson brian.peter.dick...@gmail.com wrote: - Given the lack of the big red button, this would be a good time to introduce the ability to opt-in to a NOTIFY registry, so that appropriately validated notifications could be sent by a root-zone operator (from whom the root-loopback operator does AXFRs) I don't think this necessary. The refresh timer on the root zone is 30 minutes but the update frequency is twice a day (I think). NOTIFY would not provide much benefit. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Dover, Wight, Portland, Plymouth: South 5 or 6, veering southwest 6 to gale 8, becoming cyclonic 4 or 5 later. Moderate or rough, occasionally very rough in Portland and Plymouth. Rain. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] ID Tracker State Update Notice: draft-ietf-dnsop-dnssec-key-timing-06.txt
IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Optimization in draft-ietf-dnsop-qname-minimisation
On Jan 4, 2015, at 12:13 PM, David Conrad d...@virtualized.org wrote: Sending the full qname to the authoritative name server is a tradition, not a protocol requirment. I'd actually call it an optimization, not a tradition. In many cases, sending the full qname degrades performance so I would not call it an optimization. If there are cases in which sending the full QNAME degrades performance, it might be useful to document them in the draft (off the top of my head, I can't imagine non-broken cases where that would be true, but I haven't thought about it too long). The reason I'd call it an optimization is that in the case where a server is authoritative for multiple layers of hierarchy, sending the full QNAME allows that server to bypass the referrals for all intermediate layers of hierarchy and simply respond to the depth it knows. If QNAME minimization is applied, that shortcut isn't possible. +1 to David's comment. I have always heard that sending the full name was an optimization for authoritative severs that spanned more than one level, and that such servers were common in the early days. It is worth pointing this out in this draft, and to also say that that situation may be much less common now than it was in antiquity. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Optimization in draft-ietf-dnsop-qname-minimisation
Does anyone have actual data on how common it is, so we can make an informed decision? I would expect www.something... to be in the same zone as something... in most cases, so I think it is actually very common to have more than one level on the same DNS. -- Bob Harold hostmaster, UMnet, ITcom Information and Technology Services (ITS) rharo...@umich.edu 734-647-6524 desk On Mon, Jan 5, 2015 at 11:33 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jan 4, 2015, at 12:13 PM, David Conrad d...@virtualized.org wrote: Sending the full qname to the authoritative name server is a tradition, not a protocol requirment. I'd actually call it an optimization, not a tradition. In many cases, sending the full qname degrades performance so I would not call it an optimization. If there are cases in which sending the full QNAME degrades performance, it might be useful to document them in the draft (off the top of my head, I can't imagine non-broken cases where that would be true, but I haven't thought about it too long). The reason I'd call it an optimization is that in the case where a server is authoritative for multiple layers of hierarchy, sending the full QNAME allows that server to bypass the referrals for all intermediate layers of hierarchy and simply respond to the depth it knows. If QNAME minimization is applied, that shortcut isn't possible. +1 to David's comment. I have always heard that sending the full name was an optimization for authoritative severs that spanned more than one level, and that such servers were common in the early days. It is worth pointing this out in this draft, and to also say that that situation may be much less common now than it was in antiquity. --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] Optimization in draft-ietf-dnsop-qname-minimisation
Em 05/01/2015, à(s) 14:33:000, Paul Hoffman paul.hoff...@vpnc.org escreveu: On Jan 4, 2015, at 12:13 PM, David Conrad d...@virtualized.org wrote: Sending the full qname to the authoritative name server is a tradition, not a protocol requirment. I'd actually call it an optimization, not a tradition. In many cases, sending the full qname degrades performance so I would not call it an optimization. If there are cases in which sending the full QNAME degrades performance, it might be useful to document them in the draft (off the top of my head, I can't imagine non-broken cases where that would be true, but I haven't thought about it too long). The reason I'd call it an optimization is that in the case where a server is authoritative for multiple layers of hierarchy, sending the full QNAME allows that server to bypass the referrals for all intermediate layers of hierarchy and simply respond to the depth it knows. If QNAME minimization is applied, that shortcut isn't possible. +1 to David's comment. I have always heard that sending the full name was an optimization for authoritative severs that spanned more than one level, and that such servers were common in the early days. It is worth pointing this out in this draft, and to also say that that situation may be much less common now than it was in antiquity. I can point to 25 million domain names that currently benefit from such optimization in .br and .uk alone, probably more if you add other TLDs that register on the 3rd level. Rubens ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
On 01/05/2015 09:15 PM, Andrew Sullivan wrote: On Mon, Jan 05, 2015 at 08:16:26PM +0100, Christian Grothoff wrote: Usability. Especially on small screens (mobiles, etc.), every character matters. Who even types domain names any more? On small screens, you don't type domain names. You use apps. The domain names are embedded in places. When I use the onion browser on my mobile, I follow links. And I call people by typing (yes, console) /call nickname.gnu and I prefer to keep doing just that to avoid repetitive strain injury. In fact, I can see a stronger argument for, More octets in the name takes away from the space of the 255 octets we have to work with, except of course since these names _aren't_ DNS, they don't have that limit. Except of course maybe they do, because people seem to want these alternative names to work just fine in every domain name slot. Fundamentally, this is where the problem lies: every one of these systems wants to do DNS-ng without fixing some of the big limitations. Right, GNS could be much nicer without IDNA insanity, 63-character label limitations and 255 character limits. But if we do stick to them, then telnet, ssh, and Firefox can use GNS without changes to the application. So this is the catch 22: _some_ compatibility will have to be maintained for some time, because we won't see direct application support until we have many users, and we won't get many users unless there are applications that can use the system. So GNS offers a DNS-compatible API (and even a dns2gns proxy) where it doesn't hurt too much (i.e. the limitations are not that painful for the user). I have a great deal of sympathy for that desire, because I agree that reformat the Internet isn't really an option. But the fit is rather awkward. .alt is IMO worse. Also, we're not alt (German for old), we're new! DNS is alt. If the primary objection to _that_ draft is the string, the problem is easily resolved. I'll add markup to my sarcasm next time. I personally also refuse to accept that ICANN somehow owns the entire global name space. ICANN does not own it; indeed, the very existence of top level names in the special-names registry is evidence to that effect. But the IETF has in fact delegated the responsibility of managing the root zone to IANA, and the IANA operator is ICANN. Having made that delegation, it seems rather arbitrary of us to come along and yank back chunks of it for political reasons. Hence my concern. Not political reasons, these are technical reasons. Usability is a technical concern. Using privacy-preserving, end-to-end secure name resolution is a technical matter. We can't do those with DNS, so we need a (name)space to enable/explore those matters. With GNS specifically, we tell users that the labels match exactly the entities they rely on for resolution (no out of bailiwick, no glue or other funny business). If you append some semi-random DNS name, you destroy this key aspect of usable security where the user's intuition about what is going on matches what is happening. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
Hellekin, *** Our next draft will certainly address this point. Thanks. If it makes sense to delegate a subtree and tell the implementors: now, for all domains under the .alt DNS subtree, you MUST check what is the correct assignment and resolution strategy for each domain, and you MUST handle the domains accordingly., then I guess it makes sense to use .bit.alt, and then .cjdns.alt, and .fubar.alt, etc. as long as each SUBDOMAIN will use a different strategy for handling names. That is the basis behind https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-03. On the other hand, if we want to keep a sane base, we'd rather identify, circumscribe and announce the various existing strategies, and hope that future strategies that may or may not appear will have a solid foundation for incorporating their innovative strategy into the global name space. Our group chose the latter. There is a token at the end of a domain name that indicates it shall be handled differently than domain names without that token. Aside from the length, I'm afraid I don't see how having a . in the string negatively impacts the solidly of a foundation, innovative or not. Some additional comments on http://tools.ietf.org/pdf/draft-grothoff-iesg-special-use-p2p-names-03.pdf: - 1. Overall: As with previous versions of this draft, I believe it should be broken up into separate drafts for each of the proposed 6761 special names registry entries. Tying all 6 names into a single draft is pointlessly complicating the discussions and it is likely some special use names may be more easily justified than others (e.g., .ONION) due to existing installed base, completeness of documentation, etc., and it would be a shame to delay that approval because of requests for other, unrelated, special use names. This document confuses the concepts of the domain name namespace with the DNS implementation of that namespace, making numerous assertions that they must have a particular string within the namespace because their particular application does not (necessarily) require the use of the DNS. This is a false dichotomy: the DNS implementation of the singular hierarchical domain name namespace does not preclude the use of any portion of that namespace outside of the DNS (for example, see nsswitch). I'm not sure if this is the right place to raise this, but I'm a bit confused: if DNS servers (caching/authoritative) are expected to respond with NXDOMAIN since not doing so can put users’ privacy at risk, doesn't this set users of pTLDs up for privacy violations by bad guys running a DNS server? - Introduction: However, the hierarchical nature of DNS makes it unsuitable for various P2P Name Systems. As mentioned above, the fact that a P2P name does not require the DNS hierarchy does not mean it is unsuitable to be placed within that hierarchical namespace that the DNS implements. In fact, one can argue (as dnsop-alt-tld does) that placing the special use name within a sub-tree of the namespace facilitates interoperability of DNS and non-DNS domain names utilizing a single rooted namespace. - 2. Applicability pTLDs cannot be allocated administratively Perhaps you mean Names within pTLDs cannot be allocated administratively? pTLDs do not depend on the DNS tree hierarchy for their resolution As above. However the default hierarchical DNS response to any request to any pTLD MUST be NXDOMAIN. If your applications depend on getting back an NXDOMAIN, you're going to have a bit of trouble with DNS redirection. More to the point, if your applications require an NXDOMAIN, it suggests you _ARE_ using the DNS which implies RFC 6761 does not apply. It also suggests your applications will be flooding the root with queries for non-resolvable names which, while all the rage these days, is a bit anti-social. 'The word peer is used in the meaning of a individual system on the network. Thus, local peer means the localhost.' I would've thought local peer would mean a system within the same network topological level, not on the same machine (implied by localhost). But maybe that's just me. A pTLD is mentioned in capitals, and within double quotes to mark the difference with a regular DNS gTLD. Presumably you mean TLD not gTLD as gTLD is a specific type of top-level domain (generic as opposed to country code (ccTLD)). Hope this helps. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/05/2015 03:25 PM, David Conrad wrote: I think you missed Andrew's point. *** Thank you David for shedding some light. All 6 technologies use a string that looks like a domain name but isn't intended for use in the DNS. Why does it matter if there is a '.' in the middle of that string? That is, given the technology is presumably going to intercept the domain name before it gets sent to a resolver, why would it not be possible to use (say) BIT.ALT instead of .BIT? *** Our next draft will certainly address this point. I would say, like Christian: usability. But for a completely different reason. If it makes sense to delegate a subtree and tell the implementors: now, for all domains under the .alt DNS subtree, you MUST check what is the correct assignment and resolution strategy for each domain, and you MUST handle the domains accordingly., then I guess it makes sense to use .bit.alt, and then .cjdns.alt, and .fubar.alt, etc. as long as each SUBDOMAIN will use a different strategy for handling names. On the other hand, if we want to keep a sane base, we'd rather identify, circumscribe and announce the various existing strategies, and hope that future strategies that may or may not appear will have a solid foundation for incorporating their innovative strategy into the global name space. Our group chose the latter. Regards, == hk -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJUqy0EXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg94mQP/2NIS70S8Pf8ZaoXsOy0uMG7 57IL7+0DQSug60NSeZBcSMqEBZsMUdtWA5gnnxTph6nSQaDCDdyGuE8UghhoMSTO nKr8rjUDeCMOGoYOmB5z1ldhJkezz4b1ryRPVqQoClne4aJvnVzLwB5hCeGYVi1B vZAC9BgkctdMMPcTv7lD2nc2cOv0C8qXxAiG9fPT+sTrYoaTm0j47+spyWx73NF9 eJWlpu4/Q6xgNzoShBoGAB/e6+5W1sOTLNMLwQMaSF/Yof54q2Uj+T/JOCLFQx0U e8czocLdhym1dXtEJwW686Q6XZjEGJ8kvfkGjqjChASkhuzD5P5+Wg6DLX6AmmMC Z5kc0ltuZuTKheKbOzoVmL2HAmvW6qwKJgyCcKGFMvVyG0ddcdroylpsQ/F5G9ha Pw+DCIqdti9nPS8x+DSQR9JPsKWGPbZaQ8Su/AWhIr/z2Zw5nbo1iMLcmMmbWuXd rIWYaCd3RPIq0P0tIN6gnCIEXSI5HkH0E+GPxPcapWCZT16Oz9NqBBu85xp9x7aC 4zY5Bj8IeRu9GQy+ilH4EzFMALwu1qm0bXINmPiJlhUBkbMbsT0SJUg2Qx/9lvLm +8Qm7bJm70QT3hsasXTWD8z+5/PD+cFA1zR3CRqYIt5KVYOoeA2YGBdDyaxmKfsT wFGvQzZ1jGSwx82NmA+C =tBlR -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
Dear colleagues, I have read draft-grothoff-iesg-special-use-p2p-names-03. I have some comments. In section 3, the definition of NXDOMAIN isn't actually necessary; this was defined in RFC 2308. I think it's great that the authors of this document have broken out the specialness of each kind of name, according to the criteria of RFC 6761. This is very helpful, because it allows each name to be considered independently. I do think it would be rather better if they were broken apart into separate documents -- or at least broken into groups of interdependent names -- because some of these names seem to me to be more problematic than others. Each of the names' special-processing sections includes a requirement (in item 6) that DNS server operators not provide resolution for names beneath the pseudo-TLD in question. I hope the authors do not imagine that this will prevent any server operator from answering queries for such names; there is effectively no way to make this guarantee, which is part of the risk of using DNS-like names that are not actually in the DNS. It seems that ought to be pointed out in the security considerations. For each of these names, it would be nice to see an argument as to why the names need to be TLDs as opposed to being located elsewhere in the tree. Given the fairly wide deployment of Tor, it's probably too late to fix onion and exit; but the other cases seem to be pretty lightly deployed, and I think one probably needs a strong argument for why we ought to be encroaching on the global namespace this way. In the draft, at least the motivations for onion and exit are made clear. It's a little harder to find the motivation for i2p, gnu, and zkey; but if you follow the references, you can figure it out. The same cannot be said for bit. The specification for it that is referred to in the draft is, to put it charitably, rather sketchy. It appears, however, that bit is an attack on the existing IANA-managed name registration system. There appears to be a namecoin business model and fees, and there are claims on https://wiki.namecoin.info/index.php?title=Register_and_Configure_.bit_Domains about owning the domain. I think it is completely illegitimate to use the IANA special-use names registry to try to circumvent the administrative arrangements undertaken by the IANA operator of the global namespace (regardless of how one might feel about that operator's stewardship of the global namespace or the policies, financial or otherwise, governing the root zone). There seems to be no technical advantage that bit is enabling (cf. special handling of a name is required in order to implement some desired new functionality, from RFC 6761) apart from the trick of removing name registration activities from the DNS and putting them in the hands of someone else, with policies and protocols that are not well specified. I therefore do not believe that this I-D should proceed until either bit is removed from it, or a justification for the registration of bit is added to the document. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation
Rubens Kuhl mailto:rube...@nic.br Sunday, January 04, 2015 2:11 PM ... My guess is this would even accommodate cases such as dotless domains (like dk) and in-addr.arpa. i prefer the more aggressive approach, because caching. also noting, dotless domains exist. dotless hostnames (for mail, web, etc) by def'n do not. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
On Jan 5, 2015, at 11:16 AM, Christian Grothoff christ...@grothoff.org wrote: Usability. Especially on small screens (mobiles, etc.), every character matters. . . . I personally also refuse to accept that ICANN somehow owns the entire global name space. Given the weakness of the first statement, and the lack of understanding of the DNS in the second, I support Andrew Sullivan's statement earlier: On Jan 5, 2015, at 9:44 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: I therefore do not believe that this I-D should proceed until either bit is removed from it, or a justification for the registration of bit is added to the document. --Paul Hoffman signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
On Mon, Jan 05, 2015 at 08:16:26PM +0100, Christian Grothoff wrote: Usability. Especially on small screens (mobiles, etc.), every character matters. Who even types domain names any more? On small screens, you don't type domain names. You use apps. The domain names are embedded in places. When I use the onion browser on my mobile, I follow links. In fact, I can see a stronger argument for, More octets in the name takes away from the space of the 255 octets we have to work with, except of course since these names _aren't_ DNS, they don't have that limit. Except of course maybe they do, because people seem to want these alternative names to work just fine in every domain name slot. Fundamentally, this is where the problem lies: every one of these systems wants to do DNS-ng without fixing some of the big limitations. I have a great deal of sympathy for that desire, because I agree that reformat the Internet isn't really an option. But the fit is rather awkward. Also, we're not alt (German for old), we're new! DNS is alt. If the primary objection to _that_ draft is the string, the problem is easily resolved. I personally also refuse to accept that ICANN somehow owns the entire global name space. ICANN does not own it; indeed, the very existence of top level names in the special-names registry is evidence to that effect. But the IETF has in fact delegated the responsibility of managing the root zone to IANA, and the IANA operator is ICANN. Having made that delegation, it seems rather arbitrary of us to come along and yank back chunks of it for political reasons. Hence my concern. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
Hellekin, For each of these names, it would be nice to see an argument as to why the names need to be TLDs as opposed to being located elsewhere in the tree. A common denominator of all 6 pTLDs is that they do not use the DNS tree hierarchy. It's not that they don't want to, but that their technical approach, both in terms of objectives and solutions, make them incompatible with a centralized, hierarchic name assignation and resolution. I think you missed Andrew's point. All 6 technologies use a string that looks like a domain name but isn't intended for use in the DNS. Why does it matter if there is a '.' in the middle of that string? That is, given the technology is presumably going to intercept the domain name before it gets sent to a resolver, why would it not be possible to use (say) BIT.ALT instead of .BIT? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
On Mon, Jan 05, 2015 at 03:01:41PM -0300, hellekin wrote: *** A common denominator of all 6 pTLDs is that they do not use the DNS tree hierarchy. It's not that they don't want to, but that their technical approach, both in terms of objectives and solutions, make them incompatible with a centralized, hierarchic name assignation and resolution. But that isn't _quite_ true. If I go and read the documentation for bit, it tells me how to configure my DNS servers. In that respect, it seems quite different from the other names. It appears, however, that bit is an attack on the existing IANA-managed name registration system. *** I'm very sorry to read that. It reminds me the claims that the automobile industry is an attack on the horse-carriage, or that the optical drive is an attack on the cassette recorder: it has zero technical value and seems not to have its place on an IETF mailing list. I am not sure how else to understand the documentation that is available around bit. Part of this could be solved, I suppose, if the documentation for bit were somewhat more detailed (and stable). The naming system of .bit uses a public ledger based on the technology introduced with Bitcoin. All that tells me is the policy by which names in bit are registered. In that sense it's not different from zone policies like, I permit U-labels that include Han characters but not Arabic characters. .bit, as the other P2P names proposed in our draft, in common, for they share commonalities, should be considered for their technical merits and not the political agenda of third parties. My point was not a political one, but a technical one: I don't see what bit offers that is any different from the DNS, and it's requesting that the IETF take back from ICANN a part of the root namespace that is otherwise available to ICANN to delegate. The only justification that I can find in the bit documentation is simply a political one: the proponents don't seem to like the name-registration process that exists now, and they want a different one, but they want it all to work with the DNS. That seems to me to be engineering around a political problem, and I am not convinced that the IETF ought to taking back part of the root name space in order to facilitate that. That doesn't mean that the namecoin system shouldn't be supported. But it seems to me that there's a difference between registering a special name for this, and registering it such that we alter the size of the root namespace. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-grothoff-iesg-special-use-p2p-names-03
On 01/05/2015 07:25 PM, David Conrad wrote: Hellekin, For each of these names, it would be nice to see an argument as to why the names need to be TLDs as opposed to being located elsewhere in the tree. A common denominator of all 6 pTLDs is that they do not use the DNS tree hierarchy. It's not that they don't want to, but that their technical approach, both in terms of objectives and solutions, make them incompatible with a centralized, hierarchic name assignation and resolution. I think you missed Andrew's point. All 6 technologies use a string that looks like a domain name but isn't intended for use in the DNS. Why does it matter if there is a '.' in the middle of that string? That is, given the technology is presumably going to intercept the domain name before it gets sent to a resolver, why would it not be possible to use (say) BIT.ALT instead of .BIT? Usability. Especially on small screens (mobiles, etc.), every character matters. Also, we're not alt (German for old), we're new! DNS is alt. I personally also refuse to accept that ICANN somehow owns the entire global name space. We must not let anybody own our language. Allowing ownership for certain individual words -- just as in trademarks -- can be acceptable, but never everything. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
