[DNSOP] housekeeping for DNSOP meetings: volunteers needed
Dear colleagues, DNSOP now has two meetings to manage, both with packed agendas. This means your chairs will really appreciate early volunteers for note-takers and jabber scribes. Please drop us a note if you can do either job for either session. Pitch: you might get more out of the session if you're forced to ignore your email, and your chairs (and all participants) will love you for the help. Thanks, Suzanne ( Tim) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QUIC for DNS confidentiality (Was: my dnse vision
Talked with Jim Roskind who did the QUIC talk back in Vancouver. I include his comments: I actually discussed this in a hallway discussion at the Canada IETF meeting. I think it would fit well, as it has the potential to offer zero-RTT connect (similar to what DNS over UDP effectively supports today), and yet it will better (actually) handle guaranteed delivery, as well as deal with large return packages (DNS Sec). DNS currently supports (sadly) an amplification attack of about 50x, and in QUIC, we worked hard to control this problem. IT is also nice that it is encrypted which means that folks will get some extra privacy, and not reveal (to observers) what they are resolving ;-). One hassle is that we do try to encrypt/authenticate... and with an IP address only (pointing to the DNS resolver), I don't see a clean way to have a cert providing authentication :-/. I guess you *could* implant (into a client) a combination of both the DNS resolver's IP address, *plus* an expected server name. Fun stuff to ponder ;-). IMO, interesting, and plausibly nice, fit. Jim - On 3/5/14, 2:19 PM, Stephane Bortzmeyer wrote: On Wed, Mar 05, 2014 at 11:33:07AM +, Miek Gieben m...@miek.nl wrote a message of 22 lines which said: Can't we use QUIC (http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf) ? It seems to me that a lot of use cases covered in dnse are being addressed in this protocol. It's partly a problem of timing. How long before QUIC is ready and implemented? But you're right, I'll add it to the next version of draft-bortzmeyer-dnsop-privacy-sol. ___ 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] housekeeping for DNSOP meetings: volunteers needed
On Thu, Mar 06, 2014 at 05:51:32AM -0500, Suzanne Woolf suzworldw...@gmail.com wrote a message of 16 lines which said: you might get more out of the session if you're forced to ignore your email, Email? You mean the thing we used in the 1990s? Today, people use Twitter and Facebook, you know :-) And they are much more distracting. [As the minute taker in DANE this morning, and a Twitter addict, I violently agree about the you get more out of the session.] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Food for thoughts] [Identifiers] Frogans addresses
Here are new identifiers that are not domain names and do not even look like domain names: https://www.frogans.org/ If you are in a hurry, and just interested in the identifiers, they are at: https://www.frogans.org/en/resources/ifap/access.html And you may read only the first one IFAP 1.0 technical specification Disclaimer: there is an ICANN application going on for .FROGANS Disclaimer 2: I'm not involved in that project and therefore cannot reply to serious technical questions. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] housekeeping for DNSOP meetings: volunteers needed
Suzanne, On 3/6/14 10:51 AM, Suzanne Woolf suzworldw...@gmail.com wrote: DNSOP now has two meetings to manage, both with packed agendas. This means your chairs will really appreciate early volunteers for note-takers and jabber scribes. Please drop us a note if you can do either job for either session. I am glad to help with Jabber for both sessions. As we're in some larger rooms, I would welcome someone else to help, too (and, for example, to sit near another microphone to help capture people's names). Pitch: you might get more out of the session if you're forced to ignore your email, That's a large part of why I *do* volunteer for Jabber scribing. It forces me to pay attention to exactly what is going on. Plus, it forces me to learn people's names. :-) Dan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Mar 04, 2014 at 02:38:14PM +, Warren Kumari war...@kumari.net wrote a message of 39 lines which said: Which is why I think that some of this involves us[0] talking to ICANN and explaining the reason / purpose for ALT, and playing nice. OK, so we just have to find people who accept to devote the next N years of their life to a boring and unrewarding task, full of meetings and thick reports, with lawyers and politicians. You've found someone? :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision (3 cases)
This is an update of my previous messages. The generic DNS confidentiality problem can be divided into 3 cases: 1- stubs - local resolver 2- stubs - remote open resolver 3- resolver - auth. servers In the first case the local resolver is in the same security area (I use area to avoid to overload domain or zone) than clients/ stubs (and the infrastructure between them two). This covers the case where the resolver is physically local and the one where a mobile client is securely connected to the local network, so the usual perimeter/VPN/etc including nomadic VPNs. As DNS is in the 1- case only one of the services to protect I consider without a strong argument for the opposite the security will be provided by a general (vs. a DNS one) mechanism so doesn't need a DNSE solution. BTW usually in the 1- case the resolver is dual headed so authentication and authorization are already required/provided. 2- is about a very low number of remote open resolvers so again without an explicit request I suggest we consider it is a private issue between the open resolver service and its customers. Note the environment is very different than 3- so even it has to be addressed 2- should lead to a different solution too. So we have to address 3-, and to begin by qname minimization (which is also minimal on many aspects :-). Regards francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Wed, Mar 05, 2014 at 02:58:49PM +, Jelte Jansen jelte.jan...@sidn.nl wrote a message of 20 lines which said: all the more reasons for ISPs to try and force you to use theirs (perhaps even after some friendly coercion from the nearest three-letter agency (four in the netherlands as well)). In which case we'd need even better channel encryption, to the point where you can't tell it's DNS, so it can be tunneled out of the network If we follow this line of reasoning, why do we deploy more security, then? With this argument, we would never have deployed HTTPS either. (Or SSH: most hotspots and many ISP block SSH.) We promised in Vancouver to seriously strengthen the Internet against surveillance. Was it an empty promise, politician-style? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Wed, Mar 05, 2014 at 03:11:59PM +, Wessels, Duane dwess...@verisign.com wrote a message of 35 lines which said: The goal of the DNSE BoF was privacy, not authentication. For Do you mean data authentication, or who-I-am-talking to authentication? Data authentication. In the DNS, where the authoritative name servers for a given zone can be under ≠ organisations (the root...) and where there are relays and caches everywhere, the authentication of the server has little value (that's one of the reasons I'm not a big fan of DNScurve). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Wed, Mar 05, 2014 at 04:38:20PM +, Tony Finch d...@dotat.at wrote a message of 13 lines which said: For authentication, we have DNSSEC :-) DNSSEC authenticates data not servers. See my reply to Duane. Athenticating an autoritative name server or a forwarder has little value (because they could have cheated and changed the data). The only place where server authentication could be useful is between a stub and the first resolver. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deploying security
In your previous mail you wrote: If we follow this line of reasoning, why do we deploy more security, then? = because we want (and as you noticed they don't want). With this argument, we would never have deployed HTTPS either. = have we? I am afraid most HTTPS are MITM'ed where SSH co are blocked. (Or SSH: most hotspots and many ISP block SSH.) = I know and it is a shame! BTW for ISP it is for me a good (and enough) reason to go another one (fortunately in France ISP competition is high: no NAT, no silly filters, less than 20 EUR per month for 20Mbits/s triple play...) We promised in Vancouver to seriously strengthen the Internet against surveillance. Was it an empty promise, politician-style? = the political side is politician-style, do you have a doubt? Regards francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Thu, Mar 06, 2014 at 02:50:20PM +, Stephane Bortzmeyer wrote: The only place where server authentication could be useful is between a stub and the first resolver. I think that's exactly the point that was under discussion, though: How can people who don't want their DNS traffic snooped and analyzed, but have decided for some reason to use 8.8.8.8 anyway, be sure they're talking to the real 8.8.8.8? :) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
-Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Evan Hunt Sent: Thursday, March 06, 2014 6:32 PM To: Stephane Bortzmeyer Cc: Tony Finch; dnsop@ietf.org Subject: Re: [DNSOP] my dnse vision On Thu, Mar 06, 2014 at 02:50:20PM +, Stephane Bortzmeyer wrote: The only place where server authentication could be useful is between a stub and the first resolver. I think that's exactly the point that was under discussion, though: How can people who don't want their DNS traffic snooped and analyzed, but have decided for some reason to use 8.8.8.8 anyway, be sure they're talking to the real 8.8.8.8? :) -- This is actually addressed in CGA-TSIG draft (a secure authentication) and also confidentiality ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Thu, Mar 06, 2014 at 05:31:32PM +, Evan Hunt e...@isc.org wrote a message of 12 lines which said: I think that's exactly the point that was under discussion, It's a very valid and interesting point but it has not a lot of relationship with the privacy issues. I suggest that it deserves a separate effort, which could start with a nice I-D describing the problem statement/analysis (and then to proposed solutions). Unless we want to solve all the security problems of the DNS at once, with the same solution? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Thu, Mar 06, 2014 at 06:39:07PM +0100, Stephane Bortzmeyer wrote: It's a very valid and interesting point but it has not a lot of relationship with the privacy issues. I don't entirely agree: if a MITM can spoof a trusted remote resolver, then QNAME minimization won't help you. DNSSEC ensures that you get legitimate answers; it doesn't ensure that the server on the other end belongs to someone you trust to keep your queries confidential. I suggest that it deserves a separate effort, which could start with a nice I-D describing the problem statement/analysis (and then to proposed solutions). I agree it would be appropriate to treat stub-to-resolver channel security as a separate problem space. (I will note in passing that I'm intrigued by the CGA-TSIG draft being circulated by Mr. Raffieh.) Unless we want to solve all the security problems of the DNS at once, with the same solution? Oh, I didn't realize it was an option. Yes, that sounds excellent, please do that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
From: Tony Finch d...@dotat.at It is an interesting draft and I can see why the problem concerns you. The dummy DS is a clever work-around, but it is a pity about the validation bug in Google public DNS. Thanks. I'm not sure that the validation error is a bug or not. I wonder about the possibility of adjusting the rules for caching delegations. Would it make sense to remember that a referral is insecure for the lifetime of the NS RRset, instead of the lifetime of the negative DS answer? This idea requires updating RFC 2308. I'm afraid that when newly registered DS RR will be used if the negative DS answer is cached. -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
Hi, I believe there may of been some take away from Vancouver on direction. I have a hand written note on this, but it was lost in the discussion on Key Exchanges. I will followup with you after tonight's meeting, and apologies for dropping this. tim On 3/6/14, 5:57 PM, fujiw...@jprs.co.jp wrote: From: Tony Finch d...@dotat.at It is an interesting draft and I can see why the problem concerns you. The dummy DS is a clever work-around, but it is a pity about the validation bug in Google public DNS. Thanks. I'm not sure that the validation error is a bug or not. I wonder about the possibility of adjusting the rules for caching delegations. Would it make sense to remember that a referral is insecure for the lifetime of the NS RRset, instead of the lifetime of the negative DS answer? This idea requires updating RFC 2308. I'm afraid that when newly registered DS RR will be used if the negative DS answer is cached. -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ 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] draft-fujiwara-dnsop-ds-query-increase-02
From: Olafur Gudmundsson o...@ogud.com Your calculations on the amplification are good illustration, but assume that the resolvers use the parental provided NS set, not the child side provided NS set. In the case of google.co.jp. JP side NS has TTL of 1 day but google.co.jp side has is 96 hours (4 days) Unbound resolver has by default of MaxTTL 1 day thus it does not matter in the case of google.co.jp which NS set is stored, but other resolvers do different things. Thanks. Some domain names use shorter NS TTL values. In short I think the simple conclusion is signed domain will see increased DS traffic for unsigned child domains Agree. I would like to know whether the increase of DS queries are observed commonly or not. (with small NCACHE TTL value) -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
On Fri, Mar 07, 2014 at 03:03:40AM +0900, fujiw...@jprs.co.jp wrote: ... I would like to know whether the increase of DS queries are observed commonly or not. (with small NCACHE TTL value) We are observing around the same % of qps but still need to confirm the other characteristics. Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-dns-onion-00.txt
Hi all, We had an idea in the bar. We wrote it up. Comments welcome. Joe Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-jabley-dnsop-dns-onion-00.txt Date: 6 March 2014 at 19:24:34 GMT To: Joao Luis Silva Damas jda...@dyn.com, Roy Arends r...@nominet.org.uk, Joe Abley jab...@dyn.com A new version of I-D, draft-jabley-dnsop-dns-onion-00.txt has been successfully submitted by Joe Abley and posted to the IETF repository. Name: draft-jabley-dnsop-dns-onion Revision: 00 Title:DNS Privacy with a Hint of Onion Document date:2014-03-05 Group:Individual Submission Pages:14 URL: http://www.ietf.org/internet-drafts/draft-jabley-dnsop-dns-onion-00.txt Status: https://datatracker.ietf.org/doc/draft-jabley-dnsop-dns-onion/ Htmlized: http://tools.ietf.org/html/draft-jabley-dnsop-dns-onion-00 Abstract: The Domain Name System (DNS) has no inherent capability to protect the privacy of end users. The data associated with DNS queries and responses can be observed by intermediate systems, and such observations could provide a source of metadata relating to end user behaviour. This document describes an approach which separates the data in DNS queries and responses from the identity of the DNS resolver used by DNS clients. This approach does not address privacy concerns between a stub resolver and a recursive resolver. This approach imposes no requirement for modification of authority servers, and does not depend upon widespread deployment of DNSSEC signing or validation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings
DNSOP members, Given our session today talking about protecting DNS privacy, I found an interesting bit of synchronicity upon going back to my room and seeing this article in my feeds about a compromise of at least 300,000 small office / home office (SOHO) home routers by a variety of attacks in which their DNS server values were changed and consumers were redirected to other pages as a result: http://www.circleid.com/posts/widespread_compromised_routers_discovered_with_altered_dns_configurations/ (and http://www.circleid.com/posts/20140305_dynamic_dns_customers_check_your_router_settings/ ) The actual report from Team Cymru was announced just this past Monday - https://twitter.com/teamcymru/status/440488571666198528 and is available at: https://www.team-cymru.com/ReadingRoom/Whitepapers/2013/TeamCymruSOHOPharming.pdf Now, in this case the attackers compromised the local network devices and took over control of the local recursive resolvers. In this case of the attacker controlling the recursive resolver, I don't know that any of the various solutions thrown around today would do anything to help with this. I don't even see DNSSEC helping much here, either, given that the attacker could just strip out the DNSSEC info (unless, perhaps, the home computers were running full (vs stub) recursive resolvers that also did DNSSEC-validation). I just thought it was an interesting example of a type of attack against DNS that is out there now. Dan -- Dan York Senior Content Strategist, Internet Society y...@isoc.org mailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.org mailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings
Dan, I guess you have to separate the problem of compromising device with the case where we are looking for only confidentiality or privacy. IMHO, this is somewhat out of scope. However, we cannot ignore it. In this special case, just the admin of that recursive resolver needs to react to that attack and without that nobody can understand what's going on there but the important thing is how to re-establish the trust with all the other recursive resolvers that already used that node. I think this is important because it might not be clear how many nodes already used this resolver but for the first case you can do nothing except waiting for immediate action of rescue team. Hosnieh From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Dan York Sent: Friday, March 07, 2014 12:10 AM To: dnsop@ietf.org Subject: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings DNSOP members, Given our session today talking about protecting DNS privacy, I found an interesting bit of synchronicity upon going back to my room and seeing this article in my feeds about a compromise of at least 300,000 small office / home office (SOHO) home routers by a variety of attacks in which their DNS server values were changed and consumers were redirected to other pages as a result: http://www.circleid.com/posts/widespread_compromised_routers_discovered_with _altered_dns_configurations/ (and http://www.circleid.com/posts/20140305_dynamic_dns_customers_check_your_rout er_settings/ ) The actual report from Team Cymru was announced just this past Monday - https://twitter.com/teamcymru/status/440488571666198528 and is available at: https://www.team-cymru.com/ReadingRoom/Whitepapers/2013/TeamCymruSOHOPharmin g.pdf Now, in this case the attackers compromised the local network devices and took over control of the local recursive resolvers. In this case of the attacker controlling the recursive resolver, I don't know that any of the various solutions thrown around today would do anything to help with this. I don't even see DNSSEC helping much here, either, given that the attacker could just strip out the DNSSEC info (unless, perhaps, the home computers were running full (vs stub) recursive resolvers that also did DNSSEC-validation). I just thought it was an interesting example of a type of attack against DNS that is out there now. Dan -- Dan York Senior Content Strategist, Internet Society y...@isoc.org mailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.org mailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings
On Thu, Mar 06, 2014 at 11:09:33PM +, Dan York wrote: this case of the attacker controlling the recursive resolver, I don't know that any of the various solutions thrown around today would do anything to help with this. But this was exactly the question I (among others) was trying to ask at the mic. From whom exactly are we trying to protect ourselves? If one of the answers is, our immediate upstream resolver, there's actually a possible answer to that: either don't have one, or prove that the one you're talking to is one you can trust. But to start that discussion, we first have to figure out from whom we are protecting ourselves. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-grothoff-iesg-special-use-p2p-names-02
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello list, the authors of *Special-Use Domain Names of Peer-to-Peer Systems* I-D are inviting you to review the latest version (02) of our draft. It includes changes prompted by community feedback, many coming from the DNSOP list. Among them: - a recomposed abstract (see below), - removal of the out-of-scope noconnect pTLD, - a split per domain of the IANA considerations. The latter accounts for the inflation of pages, and the authors are aware of the repetitions in sub-sections of title 5. We hope it will ease peer review and allow for finer-grained comments and improvements. Diff: http://www.ietf.org/rfcdiff?url1=draft-grothoff-iesg-special-use-p2p-names-01url2=draft-grothoff-iesg-special-use-p2p-names-02 Datatracker Entry: http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ Abstract: * This is an IESG Approval document requesting the reservation of six Top-Level Domains for special use, in conformance with the registration procedure defined in RFC 6761, section 4. Peer-to-Peer systems use specific decentralized mechanisms to allocate, register, manage, and resolve names. Those mechanisms operate entirely outside of DNS, independently from the DNS root and delegation tree. In order to avoid interoperability issues with DNS as well as to address security and privacy concerns, this document describes six pseudo Top-Level Domain names (pTLDs), reserved for special use. The following six domains relate to security-focused peer-to-peer systems. They are: .gnu, .zkey, .onion, .exit, .i2p, and .bit. * Thank you for your attention and consideration, Hellekin O. Wolf, editor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJTGUubXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg96F8P/2kS5X733/D4jEo7t8uAykp1 rsrI33eJ770uRyWFuNWJ9ULUtuviprKr9B20HVeZXwLSVMQEofBqNjqY6/7YaMpw YfWJkArX+rPw5shFyyEnvQG3aBPBOYymXhUTJadKym2hHnQywFYl1h2+VGFa9woP F5Cwmxdynp+59UaM7X9yqgqsGYomyXPmPHBwebcPtE6DCL0dfmH7C74Jx7bLpXXV 5RkXGvHEt3aQlnvJ/67O3D3fYmezj2FZnV6cAATy1++cW3PRGI9IqmfwDrpaHsUp VLwTjLPh2/kf4p0+hQMgboRdOsU7bHhXLmVW1YHAZrGwyFEfWbNAhhHuG4sA6IyY ErSJdv4EYLQBHD3getKt6PcxRuMgyr8DiKHDA3OlqysXGyQ8RkSVEfo6GgJmpmII AEYBjm55O0LzfyBuIdvBVi5md7EHzDtSypObAVtNbisdxUp99M1CMkpORAv+O3Dj 2E6+O5QD1y8c1StsgZjhTVmX4Ay6AlGPSGNGKeP63PumFqjuAz2V1eP4515qACCg eVvZnkMA6JMAUU2OTxE6FIpLlIVieMhm5HhonpgdsyFSqcn/Dl5hPR0T62Jneo5s mgkh6/6agDldpR+QgilTe5Sbnkvq6URkFu81LJUHHQbbqMnxG62x4iDv/fjzCwSf eVbIlXFeoepsnROBQ4o5 =y/bQ -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
