From Ted.Lemon@nominum.com Fri Jul 5 11:01:14 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7472921F9FBE for ; Fri, 5 Jul 2013 11:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJOIS7f2WNco for ; Fri, 5 Jul 2013 11:01:08 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 52C0F21F9F71 for ; Fri, 5 Jul 2013 11:01:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUdcJ0hP5iW71QUdV0QSKcH+QYc6E/BG+@postini.com; Fri, 05 Jul 2013 11:01:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 822671B81C2 for ; Fri, 5 Jul 2013 11:00:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7A913190060 for ; Fri, 5 Jul 2013 11:00:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 11:00:50 -0700 From: Ted Lemon To: "dns-dir@ietf.org" Thread-Topic: Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? Thread-Index: AQHOeamUmjzjt8mrPkqzsdRgwvoIYg== Date: Fri, 5 Jul 2013 18:00:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775200A1E@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D5AE0152C90C4499835CBBEBE686B66@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 18:01:14 -0000 This is a document about how to disable IPv6 on corporate networks, for tho= se who swing that way. The bit of text I am concerned with is this: For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting their own DNS resolution. This will ensure that hosts which are on an IPv4-only network will only receive DNS A records, and they will be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations. This looks like bad advice to me. I'm not convinced that there is a safe = way to do what is proposed here. What do you all think? The complete document is here: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets= -05 Thanks! From bclaise@cisco.com Mon Jul 8 07:59:15 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E0721F9C86; Mon, 8 Jul 2013 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.596 X-Spam-Level: X-Spam-Status: No, score=-10.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db6FFyJoNzrl; Mon, 8 Jul 2013 07:59:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5F85F21F9808; Mon, 8 Jul 2013 07:59:08 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r68Ex7RC000825; Mon, 8 Jul 2013 16:59:07 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r68EwbJf002798; Mon, 8 Jul 2013 16:58:48 +0200 (CEST) Message-ID: <51DAD39D.2090309@cisco.com> Date: Mon, 08 Jul 2013 16:58:37 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20130704215858.3437.65849.idtracker@ietfa.amsl.com> In-Reply-To: <20130704215858.3437.65849.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130704215858.3437.65849.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040808060002010603040505" Subject: [dns-dir] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-07-11 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:59:15 -0000 This is a multi-part message in MIME format. --------------040808060002010603040505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Please find below the agenda of the July 11th IESG telechat. Please send your questions, comments and concerns before June 10th COB. Thanks and Regards, Benoit. -------- Original Message -------- Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-07-11 IESG Teleconference Date: Thu, 04 Jul 2013 14:58:58 -0700 From: IESG Secretary To: iesg-agenda-dist@ietf.org INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2013-07-11 IESG Teleconference 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ipfix-protocol-rfc5101bis-08 - IETF stream Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information (Internet Standard) Token: Joel Jaeggli IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-appsawg-rfc5451bis-09 - IETF stream Message Header Field for Indicating Message Authentication Status (Internet Standard) Token: Barry Leiba IANA Review: Version Changed - Review Needed Consensus: Unknown 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-lisp-mib-11 - IETF stream LISP MIB (Experimental) Token: Brian Haberman IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-l2vpn-pbb-vpls-pe-model-07 - IETF stream Extensions to VPLS PE model for Provider Backbone Bridging (Informational) Note: Giles Heron (giheron@cisco.com) is the document shepherd. Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Unknown o draft-ietf-ospf-manet-single-hop-mdr-03 - IETF stream Use of OSPF-MDR in Single-Hop Broadcast Networks (Experimental) Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Unknown 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items o draft-thornburgh-adobe-rtmfp-09 - IETF stream Adobe's Secure Real-Time Media Flow Protocol (Informational) Token: Martin Stiemerling IANA Review: Version Changed - Review Needed Consensus: Unknown 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o status-change-2050-to-historic-00 - IETF stream RFC 2050 to historic (None) Token: Jari Arkko 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items o conflict-review-kiyomoto-kcipher2-00 IETF conflict review for draft-kiyomoto-kcipher2 draft-kiyomoto-kcipher2-09 A Description of KCipher-2 Encryption Algorithm (ISE: Informational) Token: Stephen Farrell o conflict-review-irtf-samrg-sam-baseline-protocol-00 IETF conflict review for draft-irtf-samrg-sam-baseline-protocol draft-irtf-samrg-sam-baseline-protocol-04 Application Layer Multicast Extensions to RELOAD (IRTF: Experimental) Token: Brian Haberman 3.4.2 Returning Items o conflict-review-donley-nat444-impacts-00 IETF conflict review for draft-donley-nat444-impacts draft-donley-nat444-impacts-06 Assessing the Impact of Carrier-Grade NAT on Network Applications (ISE: Informational) Token: Joel Jaeggli Was deferred by Martin Stiemerling on 2013-06-26 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Security Automation and Continuous Monitoring (sacm) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Managed Incident Lightweight Exchange (mile) --------------040808060002010603040505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Please find below the agenda of the July 11th IESG telechat.
Please send your questions, comments and concerns before June 10th COB.

Thanks and Regards, Benoit.


-------- Original Message --------
Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-07-11 IESG Teleconference
Date: Thu, 04 Jul 2013 14:58:58 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
To: iesg-agenda-dist@ietf.org 


INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the 2013-07-11 IESG Teleconference

2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-ipfix-protocol-rfc5101bis-08  - IETF stream
    Specification of the IP Flow Information eXport (IPFIX) Protocol for
    the Exchange of Flow Information (Internet Standard)
    Token: Joel Jaeggli
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-appsawg-rfc5451bis-09  - IETF stream
    Message Header Field for Indicating Message Authentication Status
    (Internet Standard)
    Token: Barry Leiba
    IANA Review: Version Changed - Review Needed
    Consensus: Unknown

2.1.2 Returning Items

  NONE

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

2.3 Status Changes
2.3.1 New Items

  NONE

2.3.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  o draft-ietf-lisp-mib-11  - IETF stream
    LISP MIB (Experimental)
    Token: Brian Haberman
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-l2vpn-pbb-vpls-pe-model-07  - IETF stream
    Extensions to VPLS PE model for Provider Backbone Bridging
    (Informational)
    Note: Giles Heron (giheron@cisco.com) is the document shepherd.
    Token: Stewart Bryant
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown

  o draft-ietf-ospf-manet-single-hop-mdr-03  - IETF stream
    Use of OSPF-MDR in Single-Hop Broadcast Networks (Experimental)
    Token: Stewart Bryant
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown

3.1.2 Returning Items

  NONE

3.2 Individual Submissions Via AD
3.2.1 New Items

  NONE

3.2.2 Returning Items

  o draft-thornburgh-adobe-rtmfp-09  - IETF stream
    Adobe's Secure Real-Time Media Flow Protocol (Informational)
    Token: Martin Stiemerling
    IANA Review: Version Changed - Review Needed
    Consensus: Unknown

3.3 Status Changes
3.3.1 New Items

  NONE

3.3.2 Returning Items

  NONE

3.3.3 For Action

  o status-change-2050-to-historic-00  - IETF stream
    RFC 2050 to historic (None)
    Token: Jari Arkko

3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items

  o conflict-review-kiyomoto-kcipher2-00
    IETF conflict review for draft-kiyomoto-kcipher2
      draft-kiyomoto-kcipher2-09
      A Description of KCipher-2 Encryption Algorithm (ISE:
    Informational)
    Token: Stephen Farrell

  o conflict-review-irtf-samrg-sam-baseline-protocol-00
    IETF conflict review for draft-irtf-samrg-sam-baseline-protocol
      draft-irtf-samrg-sam-baseline-protocol-04
      Application Layer Multicast Extensions to RELOAD (IRTF:
    Experimental)
    Token: Brian Haberman

3.4.2 Returning Items

  o conflict-review-donley-nat444-impacts-00
    IETF conflict review for draft-donley-nat444-impacts
      draft-donley-nat444-impacts-06
      Assessing the Impact of Carrier-Grade NAT on Network Applications
    (ISE: Informational)
    Token: Joel Jaeggli
    Was deferred by Martin Stiemerling on 2013-06-26

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  NONE

4.1.2 Proposed for Approval

  o Security Automation and Continuous Monitoring (sacm)

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  NONE

4.2.2 Proposed for Approval

  o Managed Incident Lightweight Exchange (mile)
--------------040808060002010603040505-- From Ted.Lemon@nominum.com Tue Jul 9 06:18:45 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9DE11E80FB for ; Tue, 9 Jul 2013 06:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt+pWj89sVvq for ; Tue, 9 Jul 2013 06:18:38 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 57BD411E80E1 for ; Tue, 9 Jul 2013 06:18:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUdwNrOLTgqSRL8z0yXRpeLZXg7v5JLaS@postini.com; Tue, 09 Jul 2013 06:18:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BD36C1B8222 for ; Tue, 9 Jul 2013 06:18:36 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1CA53190052 for ; Tue, 9 Jul 2013 06:18:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 06:18:36 -0700 From: Ted Lemon To: "dns-dir@ietf.org" Thread-Topic: Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? Thread-Index: AQHOfKbQ9VqBkBf9F0SETyJ2n+Ya+A== Date: Tue, 9 Jul 2013 13:18:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775205E09@mbx-01.win.nominum.com> References: <17E8FC11-7BDD-404C-98BA-B7CE073AD221@nominum.com> In-Reply-To: <17E8FC11-7BDD-404C-98BA-B7CE073AD221@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1437989B1CD93C4D8801665B4412C28E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:18:45 -0000 On Jul 5, 2013, at 2:00 PM, Ted Lemon wrote: > For this reason, networks attempting to prevent IPv6 traffic from > traversing their devices should consider configuring their local > recursive DNS servers to respond to queries for AAAA DNS records with > a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such > queries, and should even consider filtering AAAA records at the > network ingress point to prevent the internal hosts from attempting > their own DNS resolution. This will ensure that hosts which are on > an IPv4-only network will only receive DNS A records, and they will > be unlikely to attempt to use (likely broken) IPv6 connectivity to > reach their desired destinations. So, nobody is going to object to the above text, aside from calling it "dum= bass?" I hear people complaining on dnsop all the time about middleboxes = doing stuff like this; are we going to codify it in an RFC? From mark@townsley.net Tue Jul 9 06:50:53 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0777621F9DEE for ; Tue, 9 Jul 2013 06:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6IwByK5Y+tb for ; Tue, 9 Jul 2013 06:50:48 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id E3CE121F99FB for ; Tue, 9 Jul 2013 06:50:47 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id l10so3605624eei.16 for ; Tue, 09 Jul 2013 06:50:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=PjV7OnVxbDzwF8+JbMnQEJSN8U7nv6meOXxDil8jHJU=; b=GGGwbWdT7T0t1cHs/lqtfYPEM8SZ0mtmfRcROV7qTaEPHIlvqbcgP1wfzVYYkIqqCH 3hNTxurSwrVhdufMeroPwwQ+sxbf4ry5UGPoRPewIjX+D+1kTFGgaiML91eGz9RVAFK9 UIIC26ncxDGrLhqTQT0RsPSDElJxrTP9TPIC57GnCCKnYWYB+ksQk0lP97EYvl4Qtbqo tubBw2YRb+z/Pl3b+Qe3Nd+rLA0GMGcCBQMA0X6wj/sqxudw9i2BVUWy+/5FAO6jbCja 8PbNQe7DlGp3E36+Bc/di5TAGpdvmOoHIS7fKH0u/u9Ebw4/3PzU9yeviZDbB6bpTo7v xjlw== X-Received: by 10.14.32.197 with SMTP id o45mr31119373eea.9.1373377840950; Tue, 09 Jul 2013 06:50:40 -0700 (PDT) Received: from [10.148.10.180] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id y1sm51257215eew.3.2013.07.09.06.50.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 06:50:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775200A1E@mbx-01.win.nominum.com> Date: Tue, 9 Jul 2013 15:50:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7ACC4C2E-3D83-41D9-8794-AF2D9DE04701@townsley.net> References: <8D23D4052ABE7A4490E77B1A012B630775200A1E@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnCdnv6Dojo0qbJqdcX2KWdKfOsaPsNsuRo9Tcqn4ld2J3dNwqxfsV8fQTOLwCztubRYDQJ Cc: "dns-dir@ietf.org" Subject: Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:50:53 -0000 On Jul 5, 2013, at 8:00 PM, Ted Lemon wrote: > This is a document about how to disable IPv6 on corporate networks, = for those who swing that way. The bit of text I am concerned with is = this: >=20 > For this reason, networks attempting to prevent IPv6 traffic from > traversing their devices should consider configuring their local > recursive DNS servers to respond to queries for AAAA DNS records = with > a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such > queries, and should even consider filtering AAAA records at the > network ingress point to prevent the internal hosts from attempting > their own DNS resolution. This will ensure that hosts which are on > an IPv4-only network will only receive DNS A records, and they will > be unlikely to attempt to use (likely broken) IPv6 connectivity to > reach their desired destinations. >=20 > This looks like bad advice to me. I'm not convinced that there is a = safe way to do what is proposed here. What do you all think? Safe in what sense? Are there security dangers in it? I can state a lot of reasons why I don't *like* it: - Please just deploy IPv6 instead - Users that want to get around this, can (8.8.8.8) - Inconsistency in DNS is hard to diagnose, troubleshoot, etc.... That said, 6to4 and Teredo are as rampant as they are broken. Perhaps = the focus should be on ridding these from codebases entirely rather than = pussyfooting around about it as we have in the past.=20 - Mark >=20 > The complete document is here: >=20 > = http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets= -05 >=20 > Thanks! >=20 > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From mark@townsley.net Tue Jul 9 06:52:26 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F921F9CE8 for ; Tue, 9 Jul 2013 06:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQg6It27AjVS for ; Tue, 9 Jul 2013 06:52:20 -0700 (PDT) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF7C21F9F27 for ; Tue, 9 Jul 2013 06:52:19 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g15so3776027eak.18 for ; Tue, 09 Jul 2013 06:52:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer:x-gm-message-state; bh=fGhk9AgZZwarD3TWoAtR+QVJw4ix5sMKcwy4GGESZEI=; b=REcfCnCG77yDukjbRvYcIQ31YTn/JvChvUT6x25ENaBTSSzvhXmMi+W3KXs5aJwNw0 QRS/aID6oAjFj9f0cXexSN+2H2h2SBuXbCY/RVPfqYNxfVuaIK0UQNPQG6wnUvgpGVMd 9P5Me74qPVTUYOHMQMLq3g/++YdXvHGYUvhGP7eQ/MKP+1EzddzBb38MZITHv0/qOrMS UEyv1Ic5PpaUAR3w56+URQKSVMreXW1Kf8qbO2DQ6b2c5+G4Ev9KLwUQncjkc5/wIZBS cYOvOoMiF0Rp0UJk6xPUsuCxrzGPK+0iOYPVs9D7CpvvxhpC/UIAAbTKiUFr0HeZlAki 0CGA== X-Received: by 10.14.8.197 with SMTP id 45mr30431882eer.66.1373377938554; Tue, 09 Jul 2013 06:52:18 -0700 (PDT) Received: from [10.148.10.180] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id e44sm51172752eeh.11.2013.07.09.06.52.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 06:52:15 -0700 (PDT) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_673A667E-5C48-40FE-B9E1-8BC4B37695D0" Date: Tue, 9 Jul 2013 15:52:13 +0200 References: <952998C93684474BB1773498C21F6FEF01968BA87721@EXPEXCVS1.hughes.com> To: dns-dir@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlJBlMFxOUpLA/JTmyzrvxyOVWT87ZX+W5RjVHXBIOnMx/viv4eKxUNDLOaefn3gXqQ0aDx Subject: [dns-dir] Fwd: [V6providers] Question on order of IPv6 website rollout X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:52:26 -0000 --Apple-Mail=_673A667E-5C48-40FE-B9E1-8BC4B37695D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Possibly relevant for the opsec discussion. Begin forwarded message: > From: Rob Torres > Subject: [V6providers] Question on order of IPv6 website rollout > Date: July 9, 2013 3:40:19 PM GMT+02:00 > To: "v6providers@test-ipv6.com" >=20 > If this has been covered before, please feel free to redirect me to an = older > thread. >=20 > Some websites seem to have the strategy when rolling out IPv6 to first > advertise a AAAA before their website is IPv6 capable. Then after = some time, > they turn on IPv6 on their servers. If fact, we've seen some cases = where this > is done only for port 80 and not port 443. >=20 > Is there a recommendation for the order in which this sort of rollout = is > done? >=20 > When there is a valid AAAA returned, it at least delays the loading of = the > webpage (depending on many factors and different implementations) = before > fallback to IPv4. >=20 > As a satellite internet provider, we are obviously very sensitive to > additional roundtrips before a webpage is painted. As a general = internet > provider we are sensitive to pages that break and are blamed on our = transport. > Ignorantly, it would seem that making the website IPv6 capable first = and > testing with local name-IP resolutions before advertising the AAAA = would be a > better rollout order. Is there a downside to this approach? >=20 > Thanks, > -Rob Torres > _______________________________________________ > V6providers mailing list > V6providers@test-ipv6.com > http://lists.test-ipv6.com/mailman/listinfo/v6providers > http://archives.test-ipv6.com/v6providers=20 --Apple-Mail=_673A667E-5C48-40FE-B9E1-8BC4B37695D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Rob Torres <Rob.Torres@hughes.com>
Subject: [V6providers] Question on order of IPv6 website = rollout
Date: July 9, 2013 3:40:19 PM = GMT+02:00

If this has been covered before, please feel = free to redirect me to an older
thread.

Some websites seem to = have the strategy when rolling out IPv6 to first
advertise a AAAA = before their website is IPv6 capable.  Then after some = time,
they turn on IPv6 on their servers.  If fact, we've seen = some cases where this
is done only for port 80 and not port = 443.

Is there a recommendation for the order in which this sort = of rollout is
done?

When there is a valid AAAA returned, it at = least delays the loading of the
webpage (depending on many factors = and different implementations) before
fallback to IPv4.

As a = satellite internet provider, we are obviously very sensitive = to
additional roundtrips before a webpage is painted. As a general = internet
provider we are sensitive to pages that break and are blamed = on our transport.
Ignorantly, it would seem that making the website = IPv6 capable first and
testing with local name-IP resolutions before = advertising the AAAA would be a
better rollout order.  Is there = a downside to this approach?

Thanks,
-Rob = Torres
_______________________________________________
V6providers = mailing list
V6providers@test-ipv6.comhttp://lists.test-ipv6.com/mailman/listinfo/v6providers
http://archive= s.test-ipv6.com/v6providers =

= --Apple-Mail=_673A667E-5C48-40FE-B9E1-8BC4B37695D0-- From Ted.Lemon@nominum.com Tue Jul 9 07:17:47 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2378721F9EBE for ; Tue, 9 Jul 2013 07:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPV7agUexO3J for ; Tue, 9 Jul 2013 07:17:40 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 58DC721F9EA8 for ; Tue, 9 Jul 2013 07:17:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUdwbhMERFTaGoNzS5PLxIhaKt08z5Xvd@postini.com; Tue, 09 Jul 2013 07:17:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 049E21B81AC for ; Tue, 9 Jul 2013 07:17:40 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F1067190052; Tue, 9 Jul 2013 07:17:39 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 07:17:39 -0700 From: Ted Lemon To: Mark Townsley Thread-Topic: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? Thread-Index: AQHOeamUmjzjt8mrPkqzsdRgwvoIYplc2JkAgAAHjQA= Date: Tue, 9 Jul 2013 14:17:39 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775206126@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630775200A1E@mbx-01.win.nominum.com> <7ACC4C2E-3D83-41D9-8794-AF2D9DE04701@townsley.net> In-Reply-To: <7ACC4C2E-3D83-41D9-8794-AF2D9DE04701@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <352F3C2B32AD62439F567CACBA4274A5@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dns-dir@ietf.org" Subject: Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:17:47 -0000 On Jul 9, 2013, at 9:50 AM, Mark Townsley wrote: > Safe in what sense? Are there security dangers in it? It certainly breaks DNSSEC. Silently ignoring queries on a name can lead = to long timeouts. They were going to return NXDOMAIN, which would have be= en really exciting, but they at least agreed to take that out. > I can state a lot of reasons why I don't *like* it: >=20 > - Please just deploy IPv6 instead > - Users that want to get around this, can (8.8.8.8) > - Inconsistency in DNS is hard to diagnose, troubleshoot, etc.... Actually I think they want to also intercept DNS queries at the firewall, s= o querying against google's name service wouldn't work. > That said, 6to4 and Teredo are as rampant as they are broken. Perhaps the= focus should be on ridding these from codebases entirely rather than pussy= footing around about it as we have in the past.=20 Breaking 6to4 and Teredo at the enterprise firewall is pretty easy. This = is a document about how to run enterprise networks where you aren't doing I= Pv6. Personally I think it's bad because it encourages enterprises to pos= tpone upgrading to IPv6, when in fact enterprises are one of the easiest pl= aces in the world to do IPv6, and there are substantial benefits to switchi= ng. But my main concern about this document is that it will be read as th= e IETF generally supporting the techniques it describes, even though the in= troduction says it's specifically for corporate environments. So if there is something about the paragraph I quoted that would cause genu= ine breakage, but that I have missed, that's what I'm hoping someone will t= ell me. The paragraph gives me an uneasy feeling, but having gotten rid o= f the NXDOMAIN bug, there is nothing specific that I can point to, with my = limited operational experience, as being clearly broken. From mark@townsley.net Tue Jul 9 07:49:47 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230FF11E80EE for ; Tue, 9 Jul 2013 07:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbsVVSH37LpI for ; Tue, 9 Jul 2013 07:49:42 -0700 (PDT) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id BB4C221F9EC3 for ; Tue, 9 Jul 2013 07:49:41 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id d10so3850103eaj.13 for ; Tue, 09 Jul 2013 07:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DUg4ssAKNa1z0ZTeLtWUsVMZqoFoTunV+HrvFn2JfnM=; b=Uia5aT+OdadTGcRQZOdbE+bjpFhdQ22iNHEWxjIXcnX5Tlu74cisOmIMcsytj1MGVq VcE7JVnOOB+dhr506uYqXIix1YZUHTbpcEH1eXA7114NS8LU55RmXcghRgtNd8dU3GiC 6mb5ekLLpZwgK0FMo2e4iezoVU9YL47jUMpJ8/lckMWkUxh9bCauZ72uomlNgTTNcYB9 Rv5atbtjaTHt1/Net1vE+biuRsJ4tr0I4yHqUkpqvd47UnsbOQB6pasWbq7L07marhy+ ScsJspVdEAL/wblke1895/9C46lv/Mrh5KLNRe0HPSkl9yYoxNtXmMlE8L56Y+rugFhy DN8Q== X-Received: by 10.14.122.201 with SMTP id t49mr31330712eeh.26.1373381380625; Tue, 09 Jul 2013 07:49:40 -0700 (PDT) Received: from ?IPv6:2001:420:44f0:1004:ec3e:8be2:7015:16d6? ([2001:420:44f0:1004:ec3e:8be2:7015:16d6]) by mx.google.com with ESMTPSA id m1sm51492239eex.17.2013.07.09.07.49.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 07:49:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775206126@mbx-01.win.nominum.com> Date: Tue, 9 Jul 2013 16:49:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0DAE62F3-FA49-4F17-8E1B-6223ABE27673@townsley.net> References: <8D23D4052ABE7A4490E77B1A012B630775200A1E@mbx-01.win.nominum.com> <7ACC4C2E-3D83-41D9-8794-AF2D9DE04701@townsley.net> <8D23D4052ABE7A4490E77B1A012B630775206126@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkqCDDMcHMaccwMs/I3cKtbV1TCDx4yMlVIx0/YfJzCn55Bo2IKtSW78HClpDRym6NSkf1H Cc: "dns-dir@ietf.org" Subject: Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:49:47 -0000 On Jul 9, 2013, at 4:17 PM, Ted Lemon wrote: > On Jul 9, 2013, at 9:50 AM, Mark Townsley wrote: >> Safe in what sense? Are there security dangers in it? >=20 > It certainly breaks DNSSEC. =20 Well, if the request isn't being responded to at all, I suppose that = goes without saying. > Silently ignoring queries on a name can lead to long timeouts. Even if only for AAAA requests with a host that (presumably) doesn't = even have an IPv6 address configured (because by definition in the paper = it is supposed to be connected to an IPv4 only network)?=20 > They were going to return NXDOMAIN, which would have been really = exciting, but they at least agreed to take that out. >=20 >> I can state a lot of reasons why I don't *like* it: >>=20 >> - Please just deploy IPv6 instead >> - Users that want to get around this, can (8.8.8.8) >> - Inconsistency in DNS is hard to diagnose, troubleshoot, etc.... >=20 > Actually I think they want to also intercept DNS queries at the = firewall, so querying against google's name service wouldn't work. lovely. >=20 >> That said, 6to4 and Teredo are as rampant as they are broken. Perhaps = the focus should be on ridding these from codebases entirely rather than = pussyfooting around about it as we have in the past.=20 >=20 > Breaking 6to4 and Teredo at the enterprise firewall is pretty easy. =20= Yes, but that also leads to timeouts.=20 > This is a document about how to run enterprise networks where you = aren't doing IPv6. Personally I think it's bad because it encourages = enterprises to postpone upgrading to IPv6, when in fact enterprises are = one of the easiest places in the world to do IPv6, and there are = substantial benefits to switching. But my main concern about this = document is that it will be read as the IETF generally supporting the = techniques it describes, even though the introduction says it's = specifically for corporate environments. I completely agree that we shouldn't be giving advice on how to run = IPv4-only and IPv6-hostile networks - on philosophical grounds.=20 But, you asked if this was "safe", and its in an "opsec" WG. I'm trying = to understand what's unsafe here, what the target is for the doc, etc. >=20 > So if there is something about the paragraph I quoted that would cause = genuine breakage, but that I have missed, that's what I'm hoping someone = will tell me. The paragraph gives me an uneasy feeling, but having = gotten rid of the NXDOMAIN bug, there is nothing specific that I can = point to, with my limited operational experience, as being clearly = broken. Yeah, I'm not seeing what this breaks, aside of IPv6. But, that seems to = be the intent.... - Mark >=20 From Ted.Lemon@nominum.com Tue Jul 9 07:54:04 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2FE21F961F for ; Tue, 9 Jul 2013 07:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mei5qMJdlK8D for ; Tue, 9 Jul 2013 07:53:57 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id B8BA021F9FA4 for ; Tue, 9 Jul 2013 07:53:57 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUdwkBCuJeLra2TKEUaQRykYy/85okBPK@postini.com; Tue, 09 Jul 2013 07:53:57 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 57E011B8222 for ; Tue, 9 Jul 2013 07:53:56 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0BDF8190052; Tue, 9 Jul 2013 07:53:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 07:53:55 -0700 From: Ted Lemon To: Mark Townsley Thread-Topic: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? Thread-Index: AQHOeamUmjzjt8mrPkqzsdRgwvoIYplc2JkAgAAHjQCAAAjwgIAAATGA Date: Tue, 9 Jul 2013 14:53:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775206257@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B630775200A1E@mbx-01.win.nominum.com> <7ACC4C2E-3D83-41D9-8794-AF2D9DE04701@townsley.net> <8D23D4052ABE7A4490E77B1A012B630775206126@mbx-01.win.nominum.com> <0DAE62F3-FA49-4F17-8E1B-6223ABE27673@townsley.net> In-Reply-To: <0DAE62F3-FA49-4F17-8E1B-6223ABE27673@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <8044EA70D6BCBC479C3ACDA24CD43BE3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dns-dir@ietf.org" Subject: Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:54:05 -0000 On Jul 9, 2013, at 10:49 AM, Mark Townsley wrote: > Yeah, I'm not seeing what this breaks, aside of IPv6. But, that seems to = be the intent.... Yup. They even want to filter it at layer 2. :} Anyway, thanks for the second pair of eyes. From ogud@ogud.com Tue Jul 9 09:01:35 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64BC21F8793 for ; Tue, 9 Jul 2013 09:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KosbUxyYkY7n for ; Tue, 9 Jul 2013 09:01:31 -0700 (PDT) Received: from smtp82.ord1c.emailsrvr.com (smtp82.ord1c.emailsrvr.com [108.166.43.82]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9121F9C21 for ; Tue, 9 Jul 2013 09:01:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 75BF1501BC; Tue, 9 Jul 2013 12:01:08 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5ECE85020A; Tue, 9 Jul 2013 12:00:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775205E09@mbx-01.win.nominum.com> Date: Tue, 9 Jul 2013 12:00:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C13A79F-E9BD-4E8D-9B10-0DB2BBA24DD0@ogud.com> References: <17E8FC11-7BDD-404C-98BA-B7CE073AD221@nominum.com> <8D23D4052ABE7A4490E77B1A012B630775205E09@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1508) Cc: "dns-dir@ietf.org" Subject: Re: [dns-dir] Help reviewing draft-ietf-opsec-ipv6-implications-on-ipv4-nets for bad DNS advice? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:01:35 -0000 Ted,=20 While this will not work with DNSSEC there is no "serious harm" in doing = this.=20 basically they are saying "deny existence of AAAA".=20 which is fine if they want traffic to go via V4 only, the same technique = can be used=20 to migrate traffic to v6.=20 I see no DNS harm in doing this, as a matter of fact this is better than = just blocking the connections.=20 just my take on the issue, in my liberal old days.=20 Olafur On Jul 9, 2013, at 9:18 AM, Ted Lemon wrote: > On Jul 5, 2013, at 2:00 PM, Ted Lemon wrote: >> For this reason, networks attempting to prevent IPv6 traffic from >> traversing their devices should consider configuring their local >> recursive DNS servers to respond to queries for AAAA DNS records = with >> a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such >> queries, and should even consider filtering AAAA records at the >> network ingress point to prevent the internal hosts from attempting >> their own DNS resolution. This will ensure that hosts which are on >> an IPv4-only network will only receive DNS A records, and they will >> be unlikely to attempt to use (likely broken) IPv6 connectivity to >> reach their desired destinations. >=20 > So, nobody is going to object to the above text, aside from calling it = "dumbass?" I hear people complaining on dnsop all the time about = middleboxes doing stuff like this; are we going to codify it in an RFC? >=20 > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From ajs@anvilwalrusden.com Mon Jul 15 08:09:11 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4626511E8133 for ; Mon, 15 Jul 2013 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn5OmDnp5uVE for ; Mon, 15 Jul 2013 08:09:06 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3644811E8167 for ; Mon, 15 Jul 2013 08:09:03 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4408C8A031 for ; Mon, 15 Jul 2013 15:09:03 +0000 (UTC) Date: Mon, 15 Jul 2013 11:09:10 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20130715150910.GC14831@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dns-dir] Review of SPFBIS draft X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:09:11 -0000 Hi all, Someone should doubtless review the SPFBIS draft (http://tools.ietf.org/html/draft-ietf-spfbis-4408bis), since that's what's going to IESG. Note that this draft deprecates the SPF RRTYPE (TYPE 99) in favour of using TXT all the time. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From bclaise@cisco.com Wed Jul 17 00:34:38 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6A821F8956; Wed, 17 Jul 2013 00:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWMHh--6Puxv; Wed, 17 Jul 2013 00:34:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 54BFA21F9A18; Wed, 17 Jul 2013 00:34:33 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H7YWrv016366; Wed, 17 Jul 2013 09:34:32 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H7YGkE007829; Wed, 17 Jul 2013 09:34:26 +0200 (CEST) Message-ID: <51E648F8.7020107@cisco.com> Date: Wed, 17 Jul 2013 09:34:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors o , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> In-Reply-To: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010807020206070902040808" Subject: [dns-dir] IESG telechat: Agenda and Package for the July 18, 2013 Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 07:34:39 -0000 This is a multi-part message in MIME format. --------------010807020206070902040808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, We have back to back formal telechat. Please find below the agenda of the July 18th IESG telechat. Please send your questions, comments and concerns before July 17th COB. Sorry for the short notice. Thanks and Regards, Benoit. -------- Original Message -------- Subject: UPDATED Agenda and Package for the July 18, 2013 Teleconference Date: Mon, 15 Jul 2013 15:19:30 -0700 From: IESG Secretary To: The IESG CC: avezza@amsl.com, cmorgan@amsl.com, iesg-scribes@ietf.org, rse@rfc-editor.org 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-payload-vp8-09 - IETF stream RTP Payload Format for VP8 Video (Proposed Standard) Note: Ali Begen (abegen@cisco.com) is the document shepherd. Token: Richard Barnes IANA Review: Version Changed - Review Needed Consensus: Unknown o draft-ietf-abfab-eapapplicability-05 - IETF stream Update to the EAP Applicability Statement for ABFAB (Proposed Standard) Note: Klaas Wierenga (kwiereng@cisco.com) is the doc shepherd. Token: Stephen Farrell IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 - IETF stream RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) of Discarded Packets (Proposed Standard) Note: Shida Schubert (shida@ntt-at.com) is the document shepherd. Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-jcardcal-jcard-05 - IETF stream jCard: The JSON format for vCard (Proposed Standard) Token: Pete Resnick IANA Review: IANA - Review Needed Consensus: Yes Last call expires: 2013-07-18 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-multimob-pmipv6-ropt-07 - IETF stream Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 (Experimental) Note: The document went through IETF Last Call as Informational, but has since been re-classified as Experimental. Token: Brian Haberman IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-dhc-dhcpv6-failover-requirements-06 - IETF stream DHCPv6 Failover Requirements (Informational) Note: Bernie Volz (volz@cisco.com) is the document shepherd. Token: Ted Lemon IANA Review: IANA OK - No Actions Needed Consensus: Yes Last call expires: 2013-07-17 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Transparent Interconnection of Lots of Links (trill) 4.2.2 Proposed for Approval NONE --------------010807020206070902040808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

We have back to back formal telechat.
Please find below the agenda of the July 18th IESG telechat.
Please send your questions, comments and concerns before July 17th COB.
Sorry for the short notice.

Thanks and Regards, Benoit.


-------- Original Message --------
Subject: UPDATED Agenda and Package for the July 18, 2013 Teleconference
Date: Mon, 15 Jul 2013 15:19:30 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
To: The IESG <iesg@ietf.org>
CC: avezza@amsl.com, cmorgan@amsl.com, iesg-scribes@ietf.org, rse@rfc-editor.org 



2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-payload-vp8-09  - IETF stream
    RTP Payload Format for VP8 Video (Proposed Standard)
    Note: Ali Begen (abegen@cisco.com) is the document shepherd.
    Token: Richard Barnes
    IANA Review: Version Changed - Review Needed
    Consensus: Unknown

  o draft-ietf-abfab-eapapplicability-05  - IETF stream
    Update to the EAP Applicability Statement for ABFAB (Proposed
    Standard)
    Note: Klaas Wierenga (kwiereng@cisco.com) is the doc shepherd.
    Token: Stephen Farrell
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes

  o draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06  - IETF stream
    RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length
    Encoding (RLE) of Discarded Packets (Proposed Standard)
    Note: Shida Schubert (shida@ntt-at.com) is the document shepherd.
    Token: Gonzalo Camarillo
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-jcardcal-jcard-05  - IETF stream
    jCard: The JSON format for vCard (Proposed Standard)
    Token: Pete Resnick
    IANA Review: IANA - Review Needed
    Consensus: Yes
    Last call expires: 2013-07-18

2.1.2 Returning Items

  NONE

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

2.3 Status Changes
2.3.1 New Items

  NONE

2.3.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  o draft-ietf-multimob-pmipv6-ropt-07  - IETF stream
    Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
    (Experimental)
    Note: The document went through IETF Last Call as Informational, but
    has since been re-classified as Experimental.
    Token: Brian Haberman
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-dhc-dhcpv6-failover-requirements-06  - IETF stream
    DHCPv6 Failover Requirements (Informational)
    Note: Bernie Volz (volz@cisco.com) is the document shepherd.
    Token: Ted Lemon
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes
    Last call expires: 2013-07-17

3.1.2 Returning Items

  NONE

3.2 Individual Submissions Via AD
3.2.1 New Items

  NONE

3.2.2 Returning Items

  NONE

3.3 Status Changes
3.3.1 New Items

  NONE

3.3.2 Returning Items

  NONE

3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items

  NONE

3.4.2 Returning Items

  NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  NONE

4.1.2 Proposed for Approval

  NONE

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  o Transparent Interconnection of Lots of Links (trill)

4.2.2 Proposed for Approval

  NONE
--------------010807020206070902040808-- From ogud@ogud.com Mon Jul 22 12:20:43 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0A611E80D2 for ; Mon, 22 Jul 2013 12:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU+XgAwFJZDg for ; Mon, 22 Jul 2013 12:20:40 -0700 (PDT) Received: from smtp90.ord1c.emailsrvr.com (smtp90.ord1c.emailsrvr.com [108.166.43.90]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD621F9011 for ; Mon, 22 Jul 2013 12:20:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id ED5581402E8; Mon, 22 Jul 2013 15:20:24 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 51B05140161; Mon, 22 Jul 2013 15:20:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <20130521205348.GA14960@gw01.ehlo.wurstkaes.de> Date: Mon, 22 Jul 2013 15:20:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5627CC67-1579-417F-B57A-6DCD64A328D0@ogud.com> References: <171C1602-F6CC-4A29-B5CA-EDB44B247995@ogud.com> <515AA78F.7000202@neclab.eu> <20130521205348.GA14960@gw01.ehlo.wurstkaes.de> To: Sebastian Kiesel X-Mailer: Apple Mail (2.1508) Cc: Ted Lemon , IETF DNS Directorate , Martin Stiemerling Subject: Re: [dns-dir] Review request X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 19:20:44 -0000 Dear Sebastian,=20 sorry for my many delays in getting back to you.=20 see text below to follow up on my review and your answers.=20 Olafur On May 21, 2013, at 4:53 PM, Sebastian Kiesel = wrote: > Dear Olafur, >=20 > first of all, thanks for the extensive review of the Third-Party ALTO = Server > Discovery draft. Martin Stiemerling, who is very busy these days, has > forwarded your comments to me as I am the main author. >=20 > Let's start with your question #6 because it may have an impact > on the other questions: >=20 >> This boat has probably sailed but I will ask it anyway: >> Question #6 Why not place the NAPTR records in the reverse tree? >=20 > There were two reasons why we chose a two-step lookup > IP address --(PTR lookup)--> host name(s) --(U-NAPTR lookup(s))--> = ALTO URI(s) >=20 >=20 > First, this draft is a spin-off from draft-ietf-alto-server-discovery. > Because of different deployment scenarios with different requirements, > the original plan was to specify a two-stage discovery procedure with > three options for the first stage: >=20 > 1) Get a domain name by means of > 1a) manual configuration > 1b) DHCP option > 1c) PTR or SOA-mname lookup in in-addr.arpa. / ip6.arpa. > 2) Do a U-NAPTR lookup for the name yielded by step 1 >=20 > Some WG members raised doubts whether 1c) would be feasible at all. > Therefore, it was decided to move 1c) into a seperate draft in order = to > allow working on and finalizing the documents at different paces. >=20 >=20 >=20 > Second, we (the draft authors) had some hallway discussions with DNS > operators at IETF meetings about two years ago, and we were told that > putting non-PTR records in the reverse tree has deployment issues, = e.g., > with management software that creates the reverse tree automatically > from the forward tree. On the other hand, RFCs 4025, 4255, and 4322 > already do specify non-PTR records in the reverse trees. >=20 >=20 >=20 > Now that the first argument does not apply anymore we don't feel = strong > about the second one. We have running proof-of-concept client-side = code > and BIND 9 based server-side configuration files for both variants = (see > flow charts at the end of this email), but what is the DNS experts' > advise regarding deployment issues? Should we stick with the PTR+NAPTR > variant, or switch to searching the NAPTR in the reverse tree? >=20 >=20 Thank you for the clear answer, I think your approach is fine,=20 with the exception that the SOA MNAME is useless field unless you are=20 at the lowest level of a address allocation and will not work with most = network=20 allocation that are not one of /16 /24 /32=20 >=20 > For more answers and counter questions, please see inline: >=20 >=20 > On Tue, Apr 02, 2013 at 11:40:31AM +0200, Martin Stiemerling wrote: >>=20 >>=20 >>=20 >> -------- Original Message -------- >> Subject: Re: [dns-dir] Review request >> Date: Fri, 29 Mar 2013 10:13:37 -0400 >> From: Olafur Gudmundsson >> To: Brian Haberman >> CC: IETF DNS Directorate , Ted Lemon >> , Martin Stiemerling >> >>=20 >> I reviewed the document and this is a well written clear document >> with some deficiencies. >>=20 >> The introduction is real good at explaining what the document is = attempting. >=20 > thanks. >=20 >> The procedure(s) proposed are based of the implicit assumption that >> provisioning of reverse DNS is >> somehow related to service provision for another protocol, which may >> or may not be the case. >=20 > Our point of view is that for the ALTO application we need a = delegation > hierarchy for ALTO servers, which corresponds to the delegation of > IP address ranges to ISPs or other organisations. >=20 > As the DNS reverse tree delegation already follows the address space > delegation (more or less), we think it is natural to use it as a basis > for our discovery problem. We sequentially try two different = discovery > approaches: first PTR/NAPTR to allow fine-grained discovery, then > SOA/NAPTR to allow function without having to add many resource = records > to the DNS. >=20 IMHO ALTO server MUST have a PTR record if as I think the=20 SOA fallback is unlikely to work in the real world,=20 In my research of open DNS responders/resolvers, I have been able to in many cases create a map of address ranges used by ISP's and that is not a pretty picture or a consistent range.=20 >> Question #1: How is dual stack handled in queries? >> in sequence or in parallel ? >> if sequence which one first ? >>=20 >> Question #2 What about hosts with multiple links? >=20 > The short answer is: >=20 > Dual stack and multihoming basically is the same situation: > The third party usually will use 3pdisc only after receiving an > inbound connection from the actual client. It uses the connection's > source address as parameter for 3pdisc and it will not be aware > of the fact that the client has other addresses as well. >=20 >=20 > For a longer discussion, please see Section 3.1.2. of > draft-kist-alto-3pdisc-03, which we have published recently > (you have reviewed the -02 version; the -03 version has several > clarifications and deployment considerations but the algorithm > didn't change). >=20 Looks good=20 >=20 >> The procedures expect hope to get back PTR records and the name in >> the PTR record >> is used for further lookups. (good) >> The fundamental question is are all attempts to find PTR exhausted >> before going to next step? >>=20 >> Question #3: what about the case when there are multiple PTR records >> in the answer? >=20 > The algorithm is called with one IP address as parameter, even in the > case of multihoming/dual stack (see above). Finding the PTRs = associated > with said IP address is one lookup. Then, we do a NAPTR lookup on = every > yielded host name. This is the only loop in the algorithm. If all of > that fails, we do at most two more lookups for the SOA/NAPTR-based > "Plan B". So, if there are N PTR records associated with an IP = address, > the procedure causes at most N+3 DNS lookups. >=20 Q: if one or more PTR lookup is positive does that abort the SOA = lookups?=20 =20 >> If the lookup fails the procedure hopes to find SOA record in the >> negative answer, >> extracts from the SOA record the name of the "Master DNS server" = MNAME, >> and uses that name to do further lookups. >>=20 >> Comment #1: Master DNS servers are not always reachable, as they are >> hidden masters or >> traffic protected.=20 >=20 > We are fully aware of that. Indeed, we never try to contact the = master > server. We just use its name for further lookups. We decided to use > the SOA-MNAME instead of the NS records for the respective > in-addr.arpa/ip6.arpa. zone, because there is only one SOA but there > could be several NS, which would cause even more iterating over lists. >=20 >> Frequently there is no correlation between the >> zone name and the Mname >> I did a randomly selected reverse lookup on 185.55.55.55 >> 185.in-addr.arpa. 3600 IN SOA pri.authdns.ripe.net. = dns.ripe.net. ??. >>=20 >> In this case it is obvious (to a human) the SOA is useless and the >> algorithm should terminate, >=20 > Why do you think this name is obviously useless? According to whois, > 185/8 is managed by RIPE. Maybe they will provide an ALTO server in = the > future. Anyway, it is a single NAPTR lookup to find out. =46rom that block there are over 1500 delegations to over 70 different = countries,=20 yes but this might become a high load for the RIR's to deal with,=20 =20 >=20 >> what the procedure as specified will do is to cause many queries to >> the RIR name servers for lots of names that have >> no PTR records and no delegations. >=20 > We have no data on the percentage of IP addresses that have PTRs in = the > reverse tree. The first optimization target for ALTO is P2P > applications, with the peers mostly in DSL/cable access networks. At > least in the U.S. and Europe most of these IP addresses seem to have = PTRs. >=20 > In the worst case the algorithm causes 3+N DNS lookups, with N being = the > number of PTR records assigned to an IP address (usually 0 or 1). >=20 > Do you think this procedure will cause a significant burden for the = DNS > as a whole? >=20 I have no problem with the PTR lookup only the SOA hack when the SOA is = for=20 /8 delegation. or put differently=20 "if owner name of the SOA in the negative answer has has 3 or fewer = labels the SOA SHOULD be ignored"=20 eg. 185.in-addr.arpa should not cause a lookup.=20 >=20 >> Question #4: Why MNAME but not the owner name of the SOA ? (explain >> or point to explanation) >=20 > What is "the owner name of the SOA"? >=20 > Do you mean the RNAME field defined in RFC 1035, Sec 3.3.13? If so, > that would be an option as well but we think the MNAME is the more > natural choice as this is a real host name. >=20 See section 3.6 of RFC 1034. All RR's are stored at a NAME/CLASS/TYPE,=20 the name is commonly referred as the owner name.=20 >> Question #5: What is the point of the explicit SOA query for reverse >> name and why do editors expect to get a different answer than in the >> PTR question ? >=20 > The explicit SOA query is used only if the answer to the PTR query did > not contain an authority section (and there were no PTRs or they did > not produce ALTO-specific U-NAPTR lookup results). Unless there is a terminal delegation (for /32 or /128 respectively) you = will not get any more information.=20 Upon reflection on the result of PTR lookup here is a rough algorithm as = what todo: RCODE =3D=3D 0 and AnswerCount > 0 =3D=3D=3D> Success RCODE=3D0 and empty answer is a special case that you should not = see as that says "The name exists but there is no PTR record here"=20 =3D=3D> Possible to lookup SOA and get something=20= RCODE =3D=3D 3 (NXDomain)=20 =3D=3D> you can use the SOA if present in Authority = section if label count is <=3D 3=20 in all other non-zero RCODE's you can not use the result of PTR = lookup =3D=3D> Not useful=20 >=20 >> Section #4: >> there is no mention about the expected extra traffic to RIR (and or >> ISP) DNS server when the PTR lookup fails, >> I would like to see some text on how to abort the algorithms early = I.e. >> SOA present --- useful SOA ---> do lookup >> +-------- useless SOA ---> algorithm failed >>=20 >=20 > If we are in the "second half" of the algorithm, i.e., the PTR stuff > has failed, we do at most two further lookups: one to get the SOA if > we don't already have it, the second to check whether there are NAPTR > records associated with the SOA's MNAME. There are no loops around = it! >=20 >> This boat has probably sailed but I will ask it anyway: >> Question #6 Why not place the NAPTR records in the reverse tree? >=20 > see above. >=20 >> Editing comment: It would be helpful if the text from section 3 >> bullet 1 about what address to look up was included in section 2 >> before the >> diagrams of the algorithms (or at least pointer to address = selection). >>=20 >> Olafur >>=20 >> On Mar 28, 2013, at 6:01 PM, Brian Haberman >> wrote: >>=20 >>> Hi all, >>> The ALTO WG is considering the adoption of a draft focused on the = discovery of an ALTO server using DNS (but not SRV records). Martin = (TSV AD) has requested an early DNS Directorate review. Could I get a = volunteer (or two) to review the draft for DNS sanity? >>>=20 >>> https://datatracker.ietf.org/doc/draft-kist-alto-3pdisc/ >>>=20 >>> Regards, >>> Brian >>> _______________________________________________ >>> dns-dir mailing list >>> dns-dir@ietf.org >>> https://www.ietf.org/mailman/listinfo/dns-dir >=20 > = ------------------------------------------------------------------------ > Flow chart taken from draft-kist-alto-3pdisc-03 =20 > (equivalent to variant 1 in -02, but more detailed): >=20 > (-------------------------------------) > ( START 3pdisc with parameters ) > ( IP address IP, Service Parameter SP ) > (------------------+------------------) > V > +- T1 -------------+------------------+ > | R:=3D.in-addr.arpa./.ip6.arpa.| > | X:=3Dlookup(PTR,R) | > +------------------+------------------+ > V > / B1 --------+------------\ > /----< One or more PTR(s) in X >----\ > | yes \-------------------------/ no | > | V > +- T2 --------|-------------+ /----------------->+ > | V | | V > | /-> FOREACH Y:=3DPTR in X | | /- B3 -------+------------\ > | | +--------+-----------+ | | < AuthSect with SOA RR in X > > | | |lookup(U-NAPTR,Y,SP)| | | \--+---------+------------/ > | | |add results to Z | | | yes | V no > | | +--------+-----------+ | | | +- T3 -+-------------+ > | \-----------+ | | | | X:=3Dlookup(SOA,R) = | > +-------------|-------------+ | | +------+-------------+ > V | | V > /- B2 -------+------------\ | | /- B4 +------------\ = no > < One or more results in Z >----/ | -\ > \------------+------------/ no | \-----+------------/ = | > | \-------->V yes = | > | yes +- T4 --------+-------------+ = | > | | Y:=3Dextract MNAME from X = | | > V | Z:=3Dlookup(U-NAPTR,Y,SP) = | | > +<-----------------\ +-------------+-------------+ = | > V | V = | > +- T5 --------+-------------+ | /- B5 -------+------------\ = | > | sort Z acc. to order,pref | \----< One or more results in Z > = | > +-------------+-------------+ yes \------------+------------/ = | > V no = V<--------------/ > (-------------+-------------) (-------------+-------------) > ( END 3pdisc with result Z ) ( 3pdisc FAILED, no result ) > (---------------------------) (---------------------------) >=20 >=20 >=20 >=20 > = ------------------------------------------------------------------------ > Alternative solution with NAPTR records in the reverse tree > (see discussion above): >=20 > (---------------------------------------) > ( START 3pdisc with parameters ) > ( IP_address IP, Service_Parameter SP ) > (-------------------+-------------------) > V > +- T1 --------------+-------------------+ > | R:=3D.in-addr.arpa. / .ip6.arpa.| > +-------------------+-------------------+ > V > +- T2 --------------+-------------------+ > | X:=3DDNSlookup(R,U-NAPTR,SP) | > +-------------------+-------------------+ > V > / B1 --------------+------------------\ > /---------< One or more U-NAPTR results in X > > | yes \------------------+------------------/ > | V no > | /- B2 -------------+------------------\ > | /----< Authority sect. with SOA record in X > > | | yes \------------------+------------------/ > | | V no > | | +- T3 --------------+-------------------+ > | | | X:=3DDNSlookup(R,SOA) | > | | +-------------------+-------------------+ > | | V > | | /- B3 -------------+------------------\ > | | < Lookup OK, SOA record present in X >----\ > | | \------------------+------------------/ no | > | | V yes | > | \----------------------->+ | > | V | > | +- T4 --------------+-------------------+ | > | | M:=3Dextract MNAME from SOA record in X | | > | | X:=3DDNSlookup(M,U-NAPTR,SP) | | > | +-------------------+-------------------+ | > | V | > | /- B4 -------------+------------------\ V > \--->+<---< One or more U-NAPTR results in X >--->+ > | yes \-------------------------------------/ no | > V V > (-------+-------) (-------+-------) > ( END, result X ) ( END, failure ) > (---------------) (---------------) >=20 > = ------------------------------------------------------------------------ >=20 >=20 > Thanks again > Sebastian