Paul Vixie | 20 Oct 23:25 2014

namecheap to the white courtesy phone, please

it's not april 1. please stop.

vixie

re:

$ dig  <at> dns1.registrar-servers.com +short thereitwas.com CNAME
thereitwas.com.s3-website-us-east-1.amazonaws.com.

$ dig +trace thereitwas.com

; <<>> DiG 9.8.2 <<>> +trace thereitwas.com
;; global options: +cmd
.                       74554   IN      NS      h.root-servers.net.
.                       74554   IN      NS      k.root-servers.net.
.                       74554   IN      NS      g.root-servers.net.
.                       74554   IN      NS      d.root-servers.net.
.                       74554   IN      NS      f.root-servers.net.
.                       74554   IN      NS      j.root-servers.net.
.                       74554   IN      NS      m.root-servers.net.
.                       74554   IN      NS      e.root-servers.net.
.                       74554   IN      NS      b.root-servers.net.
.                       74554   IN      NS      l.root-servers.net.
.                       74554   IN      NS      i.root-servers.net.
.                       74554   IN      NS      c.root-servers.net.
.                       74554   IN      NS      a.root-servers.net.
;; Received 509 bytes from 10.62.200.11#53(10.62.200.11) in 158 ms

com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
(Continue reading)

Stephane Bortzmeyer | 20 Oct 11:27 2014
Picon

IETF working group on DNS privacy

Yes, I know, it is not really operations. But it may have an influence
on DNS operations so I prefer the operations people to be aware of it:
IETF just created a working group on DNS privacy, named DPRIV :-)

The charter of the working group, if you want to know what this group
is up to, is <http://datatracker.ietf.org/wg/dprive/charter/>

If you want to participate and do not know IETF rules, you should
first read the Tao <http://www.ietf.org/newcomers.html> Otherwise, the
group's official mailing list is
<https://www.ietf.org/mailman/listinfo/dns-privacy>

Do note that some possible tools for improving DNS privacy are not
discussed in this DPRIVE working group but in other groups. For
instance, QNAME minimisation is currently proposed for adoption by the
DNSOP working group (deadline is today).

Paul Hoffman | 19 Oct 04:10 2014

Source data about root server anycast locations?

Greetings again. The map and lists at <http://www.root-servers.org/index.html> have a lot of data that
would be valuable to analyze, particularly how close recursives are to root nodes (even if that's just
geographic/political closeness). RSSAC is just getting started with publishing reports, and anycast
location and proliferation has not been covered in the reports covered so far.

Has anyone (maybe DNS-OARC?) kept snapshots of this type of data? Any clues would be appreciated.

--Paul Hoffman
Bernhard Schmidt | 16 Oct 10:35 2014
Picon

DNSSEC Validation Errors with Wildcards

Hi,

we have recently enabled outbound TLSA/DANE on our Postfix MTAs and have
come across a number of validation errors. These have the following in
common:

- The zone where the mailserver (right side of the MX record of the
target domain) resides in is signed
- there is a wildcard record on the zone level
- lookup of mailserver A/AAAA works fine and is authenticated
- lookup of _25._tcp.mailserver TLSA leads to SERVFAIL on our resolver
(BIND 9.9.5), Google DNS and both DNS-OARC resolvers

Examples:

_25._tcp.vdlc.nl
_25._tcp.mail.plexx.eu
_25._tcp.relay01.tt-mb.nl
_25._tcp.mail.cdv.cz

Sometimes DNSVIZ shows errors in the NSEC chaining (i.e. on the tt-mb.nl
zone), but for example the mail.cdv.cz one looks fine. Yet I cannot
validate the response.

Can anyone shed some light on this issue? Is there a signing error or a
validation error? If there is a signing error, is this a bug of some
commonly used software?

Thanks,
Bernhard
(Continue reading)

Lyle Giese | 15 Oct 00:08 2014
Picon

need someone else to look at these servers

A customer is trying to send email to a customer that is using 
secureserver.net for email.

Their MX record points to presmtp.ex3.secureserver.net.

This is where things get screwy.

Dig(+trace) shows that presemtp.ex3.secureserver.net has the following 
auth servers:

gns1.secureserver.net
gns2.secureserver.net
gns3.secureserver.net

However when I query these servers directly using dig, I get back No 
servers could be reached.
(dig  <at> gns1.secureserver.net presmtp.ex3.secureserver.net)

When I use +notcp option, I get back:

Warning: EDNS query returned status FORMERR - retry with '+noedns'.

If I use +notcp and +noedns, it works and I get the A record.

If I use +noedns, it works and I get the A record.

Am I doing something wrong or are their servers/load balancers screwed 
up?  I know something is wrong, but would like someone with a bit more 
knowledge to look at this and give their opinion.

(Continue reading)

Stephane Bortzmeyer | 14 Oct 09:00 2014
Picon

ShellShock exploit through the DNS

Funny: an OS sends the result of some DNS queries to bash, allowing
the DNS operator to attack DNS clients with ShellShock:

http://packetstormsecurity.com/files/128650

What about an evil AS 112 operator attacking 168.192.in-addr.arpa
users?
Franck Martin | 14 Oct 08:39 2014
Picon

Explaining DNSSEC issues

I found this tool quite good to report the most common DNSSEC issues. It looks at SOA, A, AAAA, and MX records
of a zone and is visually nearly intuitive.

http://dnsviz.net/d/dns-oarc.net/dnssec/

The type of errors I see are like:
http://dnsviz.net/d/eucom.mil/dnssec/

Where an important record is not signed

Or like:
http://dnsviz.net/d/au/dnssec/

Where the delegation is not set (DS). For dot au, it is on purpose so testing can occur before going live by the
end of this month: http://www.auda.org.au/industry-information/au-domains/dnssec/
I found this tool quite good to report the most common DNSSEC issues. It looks at SOA, A, AAAA, and MX records
of a zone and is visually nearly intuitive.

http://dnsviz.net/d/dns-oarc.net/dnssec/

The type of errors I see are like:
http://dnsviz.net/d/eucom.mil/dnssec/

Where an important record is not signed

Or like:
http://dnsviz.net/d/au/dnssec/

(Continue reading)

han feng | 11 Oct 07:43 2014
Picon

DNS BoF <at> DNS OARC 2014 Fall LA

Hi all:

We are working on organizing a DNS BoF at DNS OARC 2014 Fall in LA, and we wanted to  
share the test report regarding to DNS dynamic update and xfr (please refer to the 
attachment), and ask your opinions on the topics that we should cover on this BoF.

Some interesting topics we thought of: 
- What approach you are using to perform zone updation, replication and synchronization
- Why dynamic update and xfr is or isn't your choice

looking forward to hear your thoughts.

Date : 12th Orc 2014 (Sunday)
Time : 6pm to 9pm 
Room : TBD 

feng

Attachment (DNS Dynamic Update Performace Study.ppt): application/vnd.ms-powerpoint, 2064 KiB
Hi all:

We are working on organizing a DNS BoF at DNS OARC 2014 Fall in LA, and we wanted to  
share the test report regarding to DNS dynamic update and xfr (please refer to the 
attachment), and ask your opinions on the topics that we should cover on this BoF.

Some interesting topics we thought of: 
- What approach you are using to perform zone updation, replication and synchronization
- Why dynamic update and xfr is or isn't your choice
(Continue reading)

Franck Martin | 10 Oct 23:56 2014
Picon

How to tell bind to ignore DNSSEC for a domain/zone

I see that unbound has a statement to tell, this domain dnssec does not work, ignore dnssec validation for it.

How do you do the same with bind?
I see that unbound has a statement to tell, this domain dnssec does not work, ignore dnssec validation for it.

How do you do the same with bind?
Davey Song | 10 Oct 23:11 2014
Picon

Comments welcome : draft-song-dnsop-ipv6only-dns-00

Hi everyone,

I have recently proposed a draft on the IPv6-only DNS deployment. Here is the abstract of this draft:

Abstract

   Focused on the IPv6 transition scenarios with IPv6-only networks,
   this memo revisits the behavior and implicit inertia of DNS which may
   hinder the IPv6-only DNS deployment.  To ease the situation, this
   memo intend to introduce a second infrastructure to support IPv6-only
   DNS experiment and development, especially in the newly developed
   IPv6 only network.

It is still an early version of a simple idea. I'm writing this letter to collect the comments and feedback from the community, pro or con, which will help us to better understand this issue and better preparation for a IETF draft. 

Anyone who will contribute this discussion, thank you in advance.

Best regards,
Davey

DNSOP Working Group                                              L. Song
Internet-Draft                                                       BII
Intended status: Standards Track                                P. Vixie
Expires: April 13, 2015                          Farsight Security, Inc.
                                                                    D. Ma
                                                                    ZDNS
                                                        October 10, 2014

                    Considerations on IPv6-only DNS
                    draft-song-dnsop-IPv6only-DNS-00

Abstract

   Focused on the IPv6 transition scenarios with IPv6-only networks,
   this memo revisits the behavior and implicit inertia of DNS which may
   hinder the IPv6-only DNS deployment.  To ease the situation, this
   memo intend to introduce a second infrastructure to support IPv6-only
   DNS experiment and development, especially in the newly developed
   IPv6 only network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 13, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Song, et al.             Expires April 13, 2015                 [Page 1]

Internet-Draft                IPv6-only DNS                 October 2014

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Revisit to current situation  . . . . . . . . . . . . . . . .   4
     3.1.  DNS Referral Response Size limitation . . . . . . . . . .   4
     3.2.  Additional section in IPv4/IPv6 Environments  . . . . . .   4
     3.3.  DNS proxy . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  An additional DNS architecture  . . . . . . . . . . . . . . .   6
     4.1.  IANA function and operation . . . . . . . . . . . . . . .   6
     4.2.  IPv6-only Root server . . . . . . . . . . . . . . . . . .   8
     4.3.  IPv6-only Recursive Resolver  . . . . . . . . . . . . . .   9
     4.4.  Relations with Existing 13 root . . . . . . . . . . . . .   9
   5.  Risk and Impact Considerations  . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   It's commonly believed that the dual-stack model is the best practice
   for IPv6 transition in which IPv4 and IPv6 function can work in
   parallel without mutual interference.  Based on this model, most
   things are expected to be converted into IPv6 smoothly when IPv4
   address pool run out.  However dual-stack approach not only gives
   IPv4/IPv6 capability on end system, network devices, DNS and
   application servers, but also brings some problems (IPv4
   fallback)[RFC6555] or even IPv4/IPv6 competition as a side effect
   which makes the dual stack model complicated.

   To accelerate the transition to a fully connected IPv6 network, there
   are some works on IPv6-only experiments [RFC6586] and IETF standards
   [RFC6333], [RFC7040] which verify IPv6 capability and support the
   IPv6-only deployment.  Particularly on domain name system in ISP
   network, it's expected that more and more DNS resolvers or modules
   will be provisioned with only IPv6 address.  It is mainly due to
   three aspects:

   1) To save more free IPv4 addresses in deploying new DNS resolvers;

Song, et al.             Expires April 13, 2015                 [Page 2]

Internet-Draft                IPv6-only DNS                 October 2014

   2) To reduce the cost and risk of management in dual stack
   environment;

   3) To follow the inherent requirement in the IPv6 transition
   scenarios, such as DS-Lite [RFC6333];

   It's worthwhile to mention that the tunnel technology provides an
   approach that allow IPv6-only network deployment become independent
   from the rest of the world which makes the IPv6-only strategy much
   porpular.  In the IPv6-only network, the ISPs only provision IPv6
   address to the end system, network and DNS element via DHCPv6.
   However, IPv6-only resolver will face an Internet which are partly
   running in IPv4 only environment and partly in dual-stack, yet with
   IPv4-prefered paradigm.  As a result, the DNS element in IPv6-only
   environment is suggested to adopt proxy function and rely on the
   upstream dual-stack DNS recursive server section 5.5 [1] in
   [RFC6333].  However, using DNS proxy mechanism is a compromise in
   IPv6 transition context, which still has implicit limitations
   [RFC5625].

   This memo revisits the behavior and implicit inertia of DNS in
   existing architecture which may hinder the IPv6-only DNS deployment.
   Given there are an increasing number of DNS resolvers who only speak
   IPv6, this memo intends to introduce an additional DNS infrastructure
   to break through the inertia such as the usage of DNS proxy and
   response paradigm, which can support IPv6-only DNS experiment and
   development, especially in the newly developed IPv6 only network.

2.  Terminology

   A: A resource record type used to specify an IPv4 address [RFC1034]

   AAAA: A resource record type used to specify an IPv6 address
   [RFC3596]

   EDNS0: Version 0 of Extension mechanisms for DNS [RFC6891]

   DNSSEC: DNS Security Extensions [RFC4033]

   MTU: Maximum Transmission Unit, the maximum size for a datagram to be
   forwarded on an interface without needing fragmentation [RFC0791],
   [RFC2460]

   Additional Section: Section in DNS query/response carrying RRs which
   may be helpful in using the RRs in the other sections [RFC1034].
   Note that in this memo the data in additional section is the A/AAAA
   information of NS server, particular for root zone.

Song, et al.             Expires April 13, 2015                 [Page 3]

Internet-Draft                IPv6-only DNS                 October 2014

3.  Revisit to current situation

3.1.  DNS Referral Response Size limitation

   Due to the required minimum IP reassembly limit for IPv4, the
   original DNS standard [RFC1034/1035] limited the UDP message size to
   512 octets.  It became a historical and practical hard DNS protocol
   limit, no matter EDNS0 [RFC6891] was introduced.  This limit presents
   some special problems for zones wishing to (1) add more authority
   servers or (2) advertise the IPv6 addresses of newly updated dual-
   stack NS name servers, or (3) use DNSSEC.

   In the context of this memo, the limitation is relaxed a little bit
   due to the larger MTU of IPv6 (1280 octets) which will be taken as a
   premise when we consider the new infrastructure.

3.2.  Additional section in IPv4/IPv6 Environments

   Given there is hard limitation in the DNS referral response size, the
   implementations preferably decide to keep as much data as possible in
   the UDP responses no matter it is "critical" or "courtesy"
   Appendix B.2 in [RFC4472] .  It is a typical case in priming exchange
   between recursive resolver and root server.  When a name server
   resolver bootstrap, it performs the NS lookup for root zone.  In the
   response packet from root server, the additional section is supposed
   to contain all the A & AAAA records of NS domain name.  Ultimately,
   when all 13 root name servers are assigned IPv6 addresses, the
   priming response will increase in size to 800 bytes.

   There are different strategies for root server operators to choose
   which RRset (A or AAAA) should be in the additional data if not all
   of the glue information can be included.  Note that in dual-stack
   environment, IPv4 glue and IPv6 glue of same zone are actually
   competing for the room of DNS UDP packets.  For example, in the
   implementation of L root server which is run by ICANN, prefers to
   return more IPv4 glues as much as possible.  In that case only 2 out
   10 IPv6 glues are included.

   If we execute dig . ns  <at> l.root-servers.net , we can simply found the
   content in additional section as follows, no matter via IPv4 or IPv6
   DNS transport.

   ;; ADDITIONAL SECTION:

   a.root-servers.net.  518400 IN A 198.41.0.4

   b.root-servers.net.  518400 IN A 192.228.79.201

Song, et al.             Expires April 13, 2015                 [Page 4]

Internet-Draft                IPv6-only DNS                 October 2014

   c.root-servers.net.  518400 IN A 192.33.4.12

   d.root-servers.net.  518400 IN A 199.7.91.13

   e.root-servers.net.  518400 IN A 192.203.230.10

   f.root-servers.net.  518400 IN A 192.5.5.241

   g.root-servers.net.  518400 IN A 192.112.36.4

   h.root-servers.net.  518400 IN A 128.63.2.53

   i.root-servers.net.  518400 IN A 192.36.148.17

   j.root-servers.net.  518400 IN A 192.58.128.30

   k.root-servers.net.  518400 IN A 193.0.14.129

   l.root-servers.net.  518400 IN A 199.7.83.42

   m.root-servers.net.  518400 IN A 202.12.27.33

   a.root-servers.net.  518400 IN AAAA 2001:503:ba3e::2:30

   b.root-servers.net.  518400 IN AAAA 2001:500:84::b

   In the context of this memo, it is much less being right to follow
   the existing response paradigm, when we consider the IPv6-only
   resolver deployment.  It's will be unrecoverable and become a
   disaster, if (1)major part of IPv6 NS servers for Root zone are
   absent and (2)the resolver did not issue one or more additional
   queries for performance consideration.

   It is also proposed that it will be wiser to take the transport of
   DNS query as a hint to decide which additional data should be set.
   There are two reasons why it is not adopted as an optimization.  One
   is that it breaks the model of independence of DNS transport and
   resource records section 1.2 [2] in [RFC4472].  Another is that it
   will bring unpredictable risk to the performance and stability of
   current root server system.

3.3.  DNS proxy

   In IPv6-only networking, DNS proxy approach is recommended for
   IPv6-only DNS element.  On one hand, it benefits by avoiding the
   difficulty to perform all DNS resolution over IPv6, given the fact
   that NS server are still IPv4 only for large website which already
   provide IPv6 services for their users, such as google, Yahoo and

Song, et al.             Expires April 13, 2015                 [Page 5]

Internet-Draft                IPv6-only DNS                 October 2014

   Wikipedia.  On another hand, it lose the opportunity to perform a
   full recursive resolver function via IPv6, at least in Root and TLD
   level which is mainly IPv6-enabled.

   In additional, as described in the beginning of [RFC5625], the DNS
   proxy function is not an optimal solution to serve the IPv6-only
   resolver requirement.  Large packets cause by priming request or
   DNSSEC validation packets will be blocked due to the proxy
   implementation.  It is suggested that: "To ensure full DNS protocol
   interoperability it is preferred that client stub resolvers should
   communicate directly with full-feature, upstream recursive resolvers
   wherever possible."

   As more and more NS servers updated to IPv6-enabled, the direct IPv6
   resolution will be preferable in IPv6-only resolver.  But regarding
   the long-tail feature of IPv6 adoption in NS servers, certain back-
   forward compatible mechanism should be designed, which indeed make an
   incentive model for IPv6 adoption over IPv4 as well.

4.  An additional DNS architecture

   To support IPv6-only public testing and deployment in a wide scale
   and avoid destabilizing the current root server system in the same
   while, this memo proposes to setup a second infrastructure which is
   basically composed of three parts : new IANA operations, IPv6-only
   root servers and DNS resolvers.

4.1.  IANA function and operation

Song, et al.             Expires April 13, 2015                 [Page 6]

Internet-Draft                IPv6-only DNS                 October 2014

                   +------------+
                   |TLD operator|
                   +-----+------+
                         | TLD update
            +------------v------------+
            |                         |
            |Vetting and Authorizing  |
            |                         |
            +-----------+-------------+
                        |
         +--------------v----------------+
         |                               |
         |         Editing and Signing   |
         |                               |
         +----+--------------------+-----+
              |                    |
      +-------v-------+   +--------v--------+
      |               |   |                 |
      | Existing Root |   | IPv6-only Root  |
      | Zone Data     |   | Zone Data       |
      |               |   |                 |
      +-------+-------+   +--------+--------+
              |                    |
   +----------v------+    +--------v--------+
   |                 |    |                 |
   | Root servers:   |    | IPv6-only Root: |
   | A,B,C,D,...,M   |    | X1,X2,X3...     |
   |                 |    |                 |
   +-----------------+    +-----------------+

   Figure 1 New DNS Root architecture with IPv6-only Root zone

   In the current practice of root zone management, IANA first receives
   the TLD updates from TLD operators.  After vetting and authorizing
   process to confirm the changes to the Root zone, the Zone maintainer
   (currently Verisign) will be notified to edit and sign the zone file,
   then distribute to the 12 root server operators.  In the current
   architecture, one intuitive approach is to ask IANA to add at least
   two additional letters "N" and "O" into the current 13 ones with
   dedicated IPv6-only NS servers.

   There are two reasons why it is not preferable.  First, following the
   DNS response mechanism from current Root servers, it is large
   possibility that the newly added IPv6 glue information will not be
   advertised via additional data.  The second is that this approach
   will bring the impact and risk to the current root server system
   which is breaking our principle.

Song, et al.             Expires April 13, 2015                 [Page 7]

Internet-Draft                IPv6-only DNS                 October 2014

   In this memo we suggest IANA to produce an additional form of the DNS
   root zone (variant root zone) as we depict in figure 1.  The new DNS
   root zone means there should be an additional forms of hint file and
   new root zone file with different apex NS record set.  Note that the
   additional ZSK/KSK in DNSSEC process is optional for IANA.

   The following example show the apex NS record set for IPv6-only
   variant Root zone including address glue.  This data would be
   included in a variant root zone before DNSSEC signing, and would be
   also be published as a "root hint" file.

   .  IN NS X1.iana-servers.net.

   .  IN NS X2.iana-servers.net.

   $ORIGIN iana-servers.net.

   X1 IN AAAA 2001:?:3::1

   X2 IN AAAA 2001:?:4::2

   In this case, although there exists two root zones, they are all
   vetted and signed by unique IANA function which guarantee the "One
   Internet" principle.

4.2.  IPv6-only Root server

   According to our goal in this memo, the new Root servers (Root
   operator) will adopt the new strategies and technologies to better
   serve the IPv6-only network.  For example, the new server will return
   the full IPv6 glue with higher priority in the priming response.

   As to the operation requirement for IPv6-only Root server, there is
   no particular difference from current practice of 13 root servers.
   The only notable change is that the IPv6-only Root servers are
   expected to subscribe the IPv6-only Root zone from IANA which will
   transfer the Zone data via AXFR/IXFR as well.  The users (resolver)
   will following the guide of new hint file to find the IPv6-only Root
   server as its entrance.

   Although it is out of scope in this memo to discuss how to choose
   IPv6-only operators to host the new root zone.  But it is worthwhile
   to mention how many operators can be present in the new root server
   list.  Based on that IPv6 MTU is 1280 octets, we can calculate that 7
   more authority server can be added in the root zone if the DNS
   referral response contain all the IPv4 and IPv6 address.  Considering
   the case that DNS referral response contain only IPv6 address for

Song, et al.             Expires April 13, 2015                 [Page 8]

Internet-Draft                IPv6-only DNS                 October 2014

   each NS server, the number of authority server for the root zone can
   be expanded to 27.

4.3.  IPv6-only Recursive Resolver

   Given that IANA provides two forms of root zone, IPv6-only resolver
   has the choice to different hint files.  If they choose the new
   IPv6-only hint file and make a priming request when it bootstrap,
   they will get consistent information of IPv6 glue.  It is important
   especially when IPv6 network is not fully connected as IPv4.  More
   IPv6 glue received in resolver side means much more stable in this
   regard.

   As to the behavior of IPv6-only resolver, it receives all the IPv6
   glue information from Root level via IPv6-only root.  But when it
   comes to TLD and second level domain which has no AAAA record for its
   NS server, IPv6-only resolver should make a patch to fall back to
   Proxy function to continue the services.  It can run the two modes
   simultaneous making the proxy as a backup or using happy
   eyeballs[RFC6555] approach.

4.4.  Relations with Existing 13 root

   It is encouraging that current 12 root operators can allocate new
   servers to host the IPv6-only root zone in parallel with existing
   IPv6 dual stack servers.

5.  Risk and Impact Considerations

   TBD

   1) IANA root zone management doubled.  Single DNSSEC key or two keys?

   2) Introduce new server/operator will cause risk to unstable
   situation

   3) Make recursive resolver complicated.  Pro and Con analysis are
   necessary.  Is it worth for IPv6-only resolver to do so?

6.  Security Considerations

   TBD

7.  IANA Considerations

   IANA should produce an additional form of the DNS root zone (variant
   root zone) to allow IPv6-only public testing and deployment in a wide
   scale.

Song, et al.             Expires April 13, 2015                 [Page 9]

Internet-Draft                IPv6-only DNS                 October 2014

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [I-D.ietf-dnsop-respsize]
              Vixie, P., Kato, A., and J. Abley, "DNS Referral Response
              Size Issues", draft-ietf-dnsop-respsize-15 (work in
              progress), February 2014.

   [I-D.lee-dnsop-scalingroot]
              Lee, X., Vixie, P., and Z. Yan, "How to scale the DNS root
              system?", draft-lee-dnsop-scalingroot-00 (work in
              progress), July 2014.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472, April
              2006.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines", BCP
              152, RFC 5625, August 2009.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.

Song, et al.             Expires April 13, 2015                [Page 10]

Internet-Draft                IPv6-only DNS                 October 2014

   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

   [RFC7040]  Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
              IPv4-over-IPv6 Access Network", RFC 7040, November 2013.

9.2.  URIs

   [1] http://tools.ietf.org/html/rfc6333#section-5.5

   [2] http://tools.ietf.org/html/rfc4472#section-1.2

Authors' Addresses

   Linjian Song
   BII
   2508 Room, 25th Floor, Tower A, Time Fortune
   Beijing  100028
   P. R. China

   Email: songlinjian <at> gmail.com

   Paul Vixie
   Farsight Security, Inc.
   155 Bovet Road, #476
   San Mateo, CA  94402
   USA

   Phone: +1 650 489 7919
   Email: vixie <at> farsightsecurity.com

   Di Ma
   ZDNS
   Beijing
   P. R. China

   Email: madi <at> zdns.cn

Song, et al.             Expires April 13, 2015                [Page 11]

DNSOP Working Group                                              L. Song
Internet-Draft                                                       BII
Intended status: Standards Track                                P. Vixie
Expires: April 13, 2015                          Farsight Security, Inc.
                                                                    D. Ma
                                                                    ZDNS
                                                        October 10, 2014

                    Considerations on IPv6-only DNS
                    draft-song-dnsop-IPv6only-DNS-00

Abstract

   Focused on the IPv6 transition scenarios with IPv6-only networks,
   this memo revisits the behavior and implicit inertia of DNS which may
   hinder the IPv6-only DNS deployment.  To ease the situation, this
   memo intend to introduce a second infrastructure to support IPv6-only
   DNS experiment and development, especially in the newly developed
   IPv6 only network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 13, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Song, et al.             Expires April 13, 2015                 [Page 1]

Internet-Draft                IPv6-only DNS                 October 2014

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Revisit to current situation  . . . . . . . . . . . . . . . .   4
     3.1.  DNS Referral Response Size limitation . . . . . . . . . .   4
     3.2.  Additional section in IPv4/IPv6 Environments  . . . . . .   4
     3.3.  DNS proxy . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  An additional DNS architecture  . . . . . . . . . . . . . . .   6
     4.1.  IANA function and operation . . . . . . . . . . . . . . .   6
     4.2.  IPv6-only Root server . . . . . . . . . . . . . . . . . .   8
     4.3.  IPv6-only Recursive Resolver  . . . . . . . . . . . . . .   9
     4.4.  Relations with Existing 13 root . . . . . . . . . . . . .   9
   5.  Risk and Impact Considerations  . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   It's commonly believed that the dual-stack model is the best practice
   for IPv6 transition in which IPv4 and IPv6 function can work in
   parallel without mutual interference.  Based on this model, most
   things are expected to be converted into IPv6 smoothly when IPv4
   address pool run out.  However dual-stack approach not only gives
   IPv4/IPv6 capability on end system, network devices, DNS and
   application servers, but also brings some problems (IPv4
   fallback)[RFC6555] or even IPv4/IPv6 competition as a side effect
   which makes the dual stack model complicated.

   To accelerate the transition to a fully connected IPv6 network, there
   are some works on IPv6-only experiments [RFC6586] and IETF standards
   [RFC6333], [RFC7040] which verify IPv6 capability and support the
   IPv6-only deployment.  Particularly on domain name system in ISP
   network, it's expected that more and more DNS resolvers or modules
   will be provisioned with only IPv6 address.  It is mainly due to
   three aspects:

   1) To save more free IPv4 addresses in deploying new DNS resolvers;

Song, et al.             Expires April 13, 2015                 [Page 2]

Internet-Draft                IPv6-only DNS                 October 2014

   2) To reduce the cost and risk of management in dual stack
   environment;

   3) To follow the inherent requirement in the IPv6 transition
   scenarios, such as DS-Lite [RFC6333];

   It's worthwhile to mention that the tunnel technology provides an
   approach that allow IPv6-only network deployment become independent
   from the rest of the world which makes the IPv6-only strategy much
   porpular.  In the IPv6-only network, the ISPs only provision IPv6
   address to the end system, network and DNS element via DHCPv6.
   However, IPv6-only resolver will face an Internet which are partly
   running in IPv4 only environment and partly in dual-stack, yet with
   IPv4-prefered paradigm.  As a result, the DNS element in IPv6-only
   environment is suggested to adopt proxy function and rely on the
   upstream dual-stack DNS recursive server section 5.5 [1] in
   [RFC6333].  However, using DNS proxy mechanism is a compromise in
   IPv6 transition context, which still has implicit limitations
   [RFC5625].

   This memo revisits the behavior and implicit inertia of DNS in
   existing architecture which may hinder the IPv6-only DNS deployment.
   Given there are an increasing number of DNS resolvers who only speak
   IPv6, this memo intends to introduce an additional DNS infrastructure
   to break through the inertia such as the usage of DNS proxy and
   response paradigm, which can support IPv6-only DNS experiment and
   development, especially in the newly developed IPv6 only network.

2.  Terminology

   A: A resource record type used to specify an IPv4 address [RFC1034]

   AAAA: A resource record type used to specify an IPv6 address
   [RFC3596]

   EDNS0: Version 0 of Extension mechanisms for DNS [RFC6891]

   DNSSEC: DNS Security Extensions [RFC4033]

   MTU: Maximum Transmission Unit, the maximum size for a datagram to be
   forwarded on an interface without needing fragmentation [RFC0791],
   [RFC2460]

   Additional Section: Section in DNS query/response carrying RRs which
   may be helpful in using the RRs in the other sections [RFC1034].
   Note that in this memo the data in additional section is the A/AAAA
   information of NS server, particular for root zone.

Song, et al.             Expires April 13, 2015                 [Page 3]

Internet-Draft                IPv6-only DNS                 October 2014

3.  Revisit to current situation

3.1.  DNS Referral Response Size limitation

   Due to the required minimum IP reassembly limit for IPv4, the
   original DNS standard [RFC1034/1035] limited the UDP message size to
   512 octets.  It became a historical and practical hard DNS protocol
   limit, no matter EDNS0 [RFC6891] was introduced.  This limit presents
   some special problems for zones wishing to (1) add more authority
   servers or (2) advertise the IPv6 addresses of newly updated dual-
   stack NS name servers, or (3) use DNSSEC.

   In the context of this memo, the limitation is relaxed a little bit
   due to the larger MTU of IPv6 (1280 octets) which will be taken as a
   premise when we consider the new infrastructure.

3.2.  Additional section in IPv4/IPv6 Environments

   Given there is hard limitation in the DNS referral response size, the
   implementations preferably decide to keep as much data as possible in
   the UDP responses no matter it is "critical" or "courtesy"
   Appendix B.2 in [RFC4472] .  It is a typical case in priming exchange
   between recursive resolver and root server.  When a name server
   resolver bootstrap, it performs the NS lookup for root zone.  In the
   response packet from root server, the additional section is supposed
   to contain all the A & AAAA records of NS domain name.  Ultimately,
   when all 13 root name servers are assigned IPv6 addresses, the
   priming response will increase in size to 800 bytes.

   There are different strategies for root server operators to choose
   which RRset (A or AAAA) should be in the additional data if not all
   of the glue information can be included.  Note that in dual-stack
   environment, IPv4 glue and IPv6 glue of same zone are actually
   competing for the room of DNS UDP packets.  For example, in the
   implementation of L root server which is run by ICANN, prefers to
   return more IPv4 glues as much as possible.  In that case only 2 out
   10 IPv6 glues are included.

   If we execute dig . ns  <at> l.root-servers.net , we can simply found the
   content in additional section as follows, no matter via IPv4 or IPv6
   DNS transport.

   ;; ADDITIONAL SECTION:

   a.root-servers.net.  518400 IN A 198.41.0.4

   b.root-servers.net.  518400 IN A 192.228.79.201

Song, et al.             Expires April 13, 2015                 [Page 4]

Internet-Draft                IPv6-only DNS                 October 2014

   c.root-servers.net.  518400 IN A 192.33.4.12

   d.root-servers.net.  518400 IN A 199.7.91.13

   e.root-servers.net.  518400 IN A 192.203.230.10

   f.root-servers.net.  518400 IN A 192.5.5.241

   g.root-servers.net.  518400 IN A 192.112.36.4

   h.root-servers.net.  518400 IN A 128.63.2.53

   i.root-servers.net.  518400 IN A 192.36.148.17

   j.root-servers.net.  518400 IN A 192.58.128.30

   k.root-servers.net.  518400 IN A 193.0.14.129

   l.root-servers.net.  518400 IN A 199.7.83.42

   m.root-servers.net.  518400 IN A 202.12.27.33

   a.root-servers.net.  518400 IN AAAA 2001:503:ba3e::2:30

   b.root-servers.net.  518400 IN AAAA 2001:500:84::b

   In the context of this memo, it is much less being right to follow
   the existing response paradigm, when we consider the IPv6-only
   resolver deployment.  It's will be unrecoverable and become a
   disaster, if (1)major part of IPv6 NS servers for Root zone are
   absent and (2)the resolver did not issue one or more additional
   queries for performance consideration.

   It is also proposed that it will be wiser to take the transport of
   DNS query as a hint to decide which additional data should be set.
   There are two reasons why it is not adopted as an optimization.  One
   is that it breaks the model of independence of DNS transport and
   resource records section 1.2 [2] in [RFC4472].  Another is that it
   will bring unpredictable risk to the performance and stability of
   current root server system.

3.3.  DNS proxy

   In IPv6-only networking, DNS proxy approach is recommended for
   IPv6-only DNS element.  On one hand, it benefits by avoiding the
   difficulty to perform all DNS resolution over IPv6, given the fact
   that NS server are still IPv4 only for large website which already
   provide IPv6 services for their users, such as google, Yahoo and

Song, et al.             Expires April 13, 2015                 [Page 5]

Internet-Draft                IPv6-only DNS                 October 2014

   Wikipedia.  On another hand, it lose the opportunity to perform a
   full recursive resolver function via IPv6, at least in Root and TLD
   level which is mainly IPv6-enabled.

   In additional, as described in the beginning of [RFC5625], the DNS
   proxy function is not an optimal solution to serve the IPv6-only
   resolver requirement.  Large packets cause by priming request or
   DNSSEC validation packets will be blocked due to the proxy
   implementation.  It is suggested that: "To ensure full DNS protocol
   interoperability it is preferred that client stub resolvers should
   communicate directly with full-feature, upstream recursive resolvers
   wherever possible."

   As more and more NS servers updated to IPv6-enabled, the direct IPv6
   resolution will be preferable in IPv6-only resolver.  But regarding
   the long-tail feature of IPv6 adoption in NS servers, certain back-
   forward compatible mechanism should be designed, which indeed make an
   incentive model for IPv6 adoption over IPv4 as well.

4.  An additional DNS architecture

   To support IPv6-only public testing and deployment in a wide scale
   and avoid destabilizing the current root server system in the same
   while, this memo proposes to setup a second infrastructure which is
   basically composed of three parts : new IANA operations, IPv6-only
   root servers and DNS resolvers.

4.1.  IANA function and operation

Song, et al.             Expires April 13, 2015                 [Page 6]

Internet-Draft                IPv6-only DNS                 October 2014

                   +------------+
                   |TLD operator|
                   +-----+------+
                         | TLD update
            +------------v------------+
            |                         |
            |Vetting and Authorizing  |
            |                         |
            +-----------+-------------+
                        |
         +--------------v----------------+
         |                               |
         |         Editing and Signing   |
         |                               |
         +----+--------------------+-----+
              |                    |
      +-------v-------+   +--------v--------+
      |               |   |                 |
      | Existing Root |   | IPv6-only Root  |
      | Zone Data     |   | Zone Data       |
      |               |   |                 |
      +-------+-------+   +--------+--------+
              |                    |
   +----------v------+    +--------v--------+
   |                 |    |                 |
   | Root servers:   |    | IPv6-only Root: |
   | A,B,C,D,...,M   |    | X1,X2,X3...     |
   |                 |    |                 |
   +-----------------+    +-----------------+

   Figure 1 New DNS Root architecture with IPv6-only Root zone

   In the current practice of root zone management, IANA first receives
   the TLD updates from TLD operators.  After vetting and authorizing
   process to confirm the changes to the Root zone, the Zone maintainer
   (currently Verisign) will be notified to edit and sign the zone file,
   then distribute to the 12 root server operators.  In the current
   architecture, one intuitive approach is to ask IANA to add at least
   two additional letters "N" and "O" into the current 13 ones with
   dedicated IPv6-only NS servers.

   There are two reasons why it is not preferable.  First, following the
   DNS response mechanism from current Root servers, it is large
   possibility that the newly added IPv6 glue information will not be
   advertised via additional data.  The second is that this approach
   will bring the impact and risk to the current root server system
   which is breaking our principle.

Song, et al.             Expires April 13, 2015                 [Page 7]

Internet-Draft                IPv6-only DNS                 October 2014

   In this memo we suggest IANA to produce an additional form of the DNS
   root zone (variant root zone) as we depict in figure 1.  The new DNS
   root zone means there should be an additional forms of hint file and
   new root zone file with different apex NS record set.  Note that the
   additional ZSK/KSK in DNSSEC process is optional for IANA.

   The following example show the apex NS record set for IPv6-only
   variant Root zone including address glue.  This data would be
   included in a variant root zone before DNSSEC signing, and would be
   also be published as a "root hint" file.

   .  IN NS X1.iana-servers.net.

   .  IN NS X2.iana-servers.net.

   $ORIGIN iana-servers.net.

   X1 IN AAAA 2001:?:3::1

   X2 IN AAAA 2001:?:4::2

   In this case, although there exists two root zones, they are all
   vetted and signed by unique IANA function which guarantee the "One
   Internet" principle.

4.2.  IPv6-only Root server

   According to our goal in this memo, the new Root servers (Root
   operator) will adopt the new strategies and technologies to better
   serve the IPv6-only network.  For example, the new server will return
   the full IPv6 glue with higher priority in the priming response.

   As to the operation requirement for IPv6-only Root server, there is
   no particular difference from current practice of 13 root servers.
   The only notable change is that the IPv6-only Root servers are
   expected to subscribe the IPv6-only Root zone from IANA which will
   transfer the Zone data via AXFR/IXFR as well.  The users (resolver)
   will following the guide of new hint file to find the IPv6-only Root
   server as its entrance.

   Although it is out of scope in this memo to discuss how to choose
   IPv6-only operators to host the new root zone.  But it is worthwhile
   to mention how many operators can be present in the new root server
   list.  Based on that IPv6 MTU is 1280 octets, we can calculate that 7
   more authority server can be added in the root zone if the DNS
   referral response contain all the IPv4 and IPv6 address.  Considering
   the case that DNS referral response contain only IPv6 address for

Song, et al.             Expires April 13, 2015                 [Page 8]

Internet-Draft                IPv6-only DNS                 October 2014

   each NS server, the number of authority server for the root zone can
   be expanded to 27.

4.3.  IPv6-only Recursive Resolver

   Given that IANA provides two forms of root zone, IPv6-only resolver
   has the choice to different hint files.  If they choose the new
   IPv6-only hint file and make a priming request when it bootstrap,
   they will get consistent information of IPv6 glue.  It is important
   especially when IPv6 network is not fully connected as IPv4.  More
   IPv6 glue received in resolver side means much more stable in this
   regard.

   As to the behavior of IPv6-only resolver, it receives all the IPv6
   glue information from Root level via IPv6-only root.  But when it
   comes to TLD and second level domain which has no AAAA record for its
   NS server, IPv6-only resolver should make a patch to fall back to
   Proxy function to continue the services.  It can run the two modes
   simultaneous making the proxy as a backup or using happy
   eyeballs[RFC6555] approach.

4.4.  Relations with Existing 13 root

   It is encouraging that current 12 root operators can allocate new
   servers to host the IPv6-only root zone in parallel with existing
   IPv6 dual stack servers.

5.  Risk and Impact Considerations

   TBD

   1) IANA root zone management doubled.  Single DNSSEC key or two keys?

   2) Introduce new server/operator will cause risk to unstable
   situation

   3) Make recursive resolver complicated.  Pro and Con analysis are
   necessary.  Is it worth for IPv6-only resolver to do so?

6.  Security Considerations

   TBD

7.  IANA Considerations

   IANA should produce an additional form of the DNS root zone (variant
   root zone) to allow IPv6-only public testing and deployment in a wide
   scale.

Song, et al.             Expires April 13, 2015                 [Page 9]

Internet-Draft                IPv6-only DNS                 October 2014

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [I-D.ietf-dnsop-respsize]
              Vixie, P., Kato, A., and J. Abley, "DNS Referral Response
              Size Issues", draft-ietf-dnsop-respsize-15 (work in
              progress), February 2014.

   [I-D.lee-dnsop-scalingroot]
              Lee, X., Vixie, P., and Z. Yan, "How to scale the DNS root
              system?", draft-lee-dnsop-scalingroot-00 (work in
              progress), July 2014.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472, April
              2006.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines", BCP
              152, RFC 5625, August 2009.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.

Song, et al.             Expires April 13, 2015                [Page 10]

Internet-Draft                IPv6-only DNS                 October 2014

   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

   [RFC7040]  Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
              IPv4-over-IPv6 Access Network", RFC 7040, November 2013.

9.2.  URIs

   [1] http://tools.ietf.org/html/rfc6333#section-5.5

   [2] http://tools.ietf.org/html/rfc4472#section-1.2

Authors' Addresses

   Linjian Song
   BII
   2508 Room, 25th Floor, Tower A, Time Fortune
   Beijing  100028
   P. R. China

   Email: songlinjian <at> gmail.com

   Paul Vixie
   Farsight Security, Inc.
   155 Bovet Road, #476
   San Mateo, CA  94402
   USA

   Phone: +1 650 489 7919
   Email: vixie <at> farsightsecurity.com

   Di Ma
   ZDNS
   Beijing
   P. R. China

   Email: madi <at> zdns.cn

Song, et al.             Expires April 13, 2015                [Page 11]
Matthew Pounsett | 10 Oct 22:49 2014

2014 Fall DNS-OARC Workshop PGP Keysigning


I've heard a couple reports that attendees at the meeting this weekend did not receive an email I sent
through Indico about the PGP keysigning at the meeting.  Apologies for that.. I'm using this email to
dns-operations to compensate.

The keysigning party will be during the second half of lunch on Sunday.   If you wish to participate, please
email your key(s) to matt.pounsett+keyparty@... and I'll
compile a keyring.  

Please bring a trusted source to read your fingerprint from (such as your PGP keyring on your laptop) and ID
suitable for identifying yourself to people from other countries.

Thanks all.  Apologies for the noise to those of you not attending.
- Matt


Gmane