internet-drafts | 25 Apr 06:04 2015
Picon

I-D Action: draft-ietf-dnsop-negative-trust-anchors-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Definition and Use of DNSSEC Negative Trust Anchors
        Authors         : Paul Ebersman
                          Chris Griffiths
                          Warren Kumari
                          Jason Livingood
                          Ralf Weber
	Filename        : draft-ietf-dnsop-negative-trust-anchors-04.txt
	Pages           : 17
	Date            : 2015-04-24

Abstract:
   DNS Security Extensions (DNSSEC) is now entering widespread
   deployment.  However, domain signing tools and processes are not yet
   as mature and reliable as those for non-DNSSEC-related domain
   administration tools and processes.  Negative Trust Anchors
   (described in this document) can be used to mitigate DNSSEC
   validation failures.

   [RFC Editor: Please remove this before publication.  This document is
   being stored in github at https://github.com/wkumari/draft-livingood-
   dnsop-negative-trust-anchors . Authors accept pull requests, and keep
   the latest (edit buffer) versions there, so commenters can follow
   along at home.]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/
(Continue reading)

Paul Hoffman | 25 Apr 02:57 2015

Terminology: policy-implementing resolver

Greetings again. Based on input from St├ęphane and Hugo, I came up with the following to replace the current
two terms. Does this work for people?

--Paul Hoffman

   Policy-implementing resolver -- A resolver acting in recursive mode
   that changes some of the answers that it returns based on policy
   criteria, such as to prevent access to malware sites or objectionable
   content.  In general, a stub resolver has no idea whether or not
   upstream resolvers implement such policy or, if they do, the exact
   policy about what changes will be made.  In some cases, the user of
   the stub resolver has selected the policy-implementing resolver with
   the explicit intention of using it to implement the policies.  In
   other cases, policies are imposed without the user of the stub
   resolver being informed.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Hoffman | 25 Apr 02:55 2015

Terminology: forwarding and forwarder

Greetings again. After the active discussion on these terms, we propose the following, which tries to hew
closely to both RFCs. Comments are certainly welcome.

--Paul Hoffman

   Forwarding -- The process of one server sending a DNS query with the
   RD bit set to 1 to another server to resolve that query.  Forwarding
   is a function of a DNS resolver; it is different than simply blindly
   relaying queries.

   [RFC5625] does not give a specific definition for forwarding, but
   describes in detail what features a system that forwards need to
   support.  Systems that forward are sometimes called "DNS proxies",
   but that term has not yet been defined (even in [RFC5625]).

   Forwarder -- Section 1 of [RFC2308] describes a forwarder as "a
   nameserver used to resolve queries instead of directly using the
   authoritative nameserver chain".  [RFC2308] further says "The
   forwarder typically either has better access to the internet, or
   maintains a bigger cache which may be shared amongst many resolvers."
   That definition appears to suggest that forwarders normally only
   query authoritative servers.  In current use, however, forwarders
   often stand between stub resolvers and recursive servers.  [RFC2308]
   is silent on whether a forwarder is iterative-only or can be a full
   resolver.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(Continue reading)

Paul Hoffman | 24 Apr 20:33 2015

Terminology: primary, secondary, master, slave

Greetings again. Based on Casey's proposal, I would like to make the following changes. Thoughts?

--Paul Hoffman

CURRENT:

Primary servers and secondary servers --- These are synonyms for "master server" and "slave server",
which were the terms used in the early DNS RFCs, and defined below. The current common usage has
shifted to "primary" and "secondary".

Slave server --- An authoritative server which uses zone transfer to retrieve the zone.
(Quoted from {{RFC1996}}, section 2.1)
{{RFC2182}} describes slave servers in detail.

Master --- Any authoritative server configured to be the source of zone transfer
for one or more slave servers. (Quoted from {{RFC1996}}, section 2.1)
{{RFC2136}} defines "master" as "an authoritative server configured to be the source of AXFR or IXFR
data for one or more slave servers".

================================

PROPOSED:

Secondary server --- "An authoritative server which uses zone transfer to retrieve the
zone" (quoted from {{RFC1996}}, section 2.1).  {{RFC2182}} describes secondary servers in
detail.  Although early DNS RFCs such as {{RFC1996}} referred to this as a "slave", the
current common usage has shifted to calling it a "secondary".

Slave server --- See secondary server.

(Continue reading)

Warren Kumari | 23 Apr 18:39 2015
Picon

Requesting WGLC of draft-ietf-dnsop-negative-trust-anchors.

Hi there,

We believe that "Definition and Use of DNSSEC Negative Trust Anchors"
( draft-ietf-dnsop-negative-trust-anchors  -
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/
)  is ready for WGLC.

We believe we have incorporated all comments, and that the document
has received significant review.

W

--

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 23 Apr 01:40 2015
Picon

I-D Action: draft-ietf-dnsop-negative-trust-anchors-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Definition and Use of DNSSEC Negative Trust Anchors
        Authors         : Paul Ebersman
                          Chris Griffiths
                          Warren Kumari
                          Jason Livingood
                          Ralf Weber
	Filename        : draft-ietf-dnsop-negative-trust-anchors-03.txt
	Pages           : 17
	Date            : 2015-04-22

Abstract:
   DNS Security Extensions (DNSSEC) is now entering widespread
   deployment.  However, domain signing tools and processes are not yet
   as mature and reliable as those for non-DNSSEC-related domain
   administration tools and processes.  Negative Trust Anchors
   (described in this document) can be used to mitigate DNSSEC
   validation failures.

   [RFC Editor: Please remove this before publication.  This document is
   being stored in github at https://github.com/wkumari/draft-livingood-
   dnsop-negative-trust-anchors . Authors accept pull requests, and keep
   the latest (edit buffer) versions there, so commenters can follow
   along at home.]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/
(Continue reading)

IESG Secretary | 22 Apr 23:10 2015
Picon

DNSOP WG Virtual Interim Meeting: 12 May 2015

The DNS Operations (DNSOP) Working Group will hold a virtual meeting to
discuss the questions around RFC 6761 and the "Special Names" Registry.

Date: Tuesday, 12 May 2015
Time: 1600-1800 UTC (1200-1400 EDT)

JOIN WEBEX MEETING:
https://ietf.webex.com/ietf/j.php?MTID=me1390ebc21ee8ab1b9dfe4a4363cff17
Meeting number: 649 835 476
Meeting password: 1234

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 649 835 476

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Yuri Schaeffer | 22 Apr 13:49 2015
Picon

draft-ietf-dnsop-edns-client-subnet-00 Birthday Attack


Please correct me if I'm wrong. I think there is a problem in this
draft.

Although the draft explicitly addresses Birthday Attacks it is still
vulnerable. Section 10.2 (Birthday Attacks) states:

> To counter this, every edns-client-subnet option in a response 
> packet MUST contain the FAMILY and SOURCE NETMASK fields from the 
> corresponding request, along with identical ADDRESS bits for
> SOURCE NETMASK length. Intermediate Nameservers processing a
> response MUST verify that these match, and MUST discard the entire
> reply if they do not.

So far so good, ECS as part of the q-tuple. But then Section 6.3.:

> Replies coming from servers not supporting edns-client-subnet or 
> otherwise not containing an edns-client-subnet option SHOULD be 
> considered as containing a SCOPE NETMASK of 0 (e.g., cache the 
> result for 0.0.0.0/0 or ::/0) for all the supported families.

These two excerpts directly contradict in my opinion and DO make ECS
enabled resolvers vulnerable for cache poisoning.

Scenario:
1) attacker sends a flood of N queries to the resolver with the same
q-tuple but different source addresses or ECS options.
2) Resolver is not able to deduplicate queries since we are doing ECS
and thus will send N queries to the authority.
3) attacker sends flood of spoofed responses with evil content and
(Continue reading)

internet-drafts | 20 Apr 23:47 2015
Picon

I-D Action: draft-ietf-dnsop-rfc6598-rfc6303-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Add 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry.
        Author          : M. Andrews
	Filename        : draft-ietf-dnsop-rfc6598-rfc6303-03.txt
	Pages           : 5
	Date            : 2015-04-20

Abstract:
   RFC6598 specified that: "Reverse DNS queries for Shared Address Space
   addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS
   infrastructure."

   This document formally directs IANA to add the associated zones to
   the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries
   accidently leaking to the global DNS infrastructure.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6598-rfc6303/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-rfc6598-rfc6303-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc6598-rfc6303-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
(Continue reading)

Tim WIcinski | 17 Apr 12:48 2015
Picon

Adoption and Working Group Last Call for draft-ietf-dnsop-dns-terminology/


Greetings,

While we've never had a formal call for adoption, this draft has had a 
lot of comments about the contents, but never about the need for this 
document. The need has been clear.

The chairs made the move of adopting the document directly, and we're 
now opening a Working Group Last Call on this document.

The draft can be found here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/

http://www.ietf.org/id/draft-ietf-dnsop-dns-terminology-00.txt

Please review the draft and offer relevant comments. Remember: This 
draft is not attempting to redefine any definitions, but to collect and 
formalize the definitions which do exist.

Because of the nature of the WGLC, we're making this a three week 
window.  The working group last call will end on Friday May 8th.

thanks
tim

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(Continue reading)

Alec Muffett | 16 Apr 19:25 2015

draft-appelbaum-dnsop-onion-tld-01 - seeking consideration and advice

Hello All,

So a couple of days ago I posted draft-appelbaum-dnsop-onion-tld-01:


Again, the diffs are minimal from -00:


…and I am cognizant of (planned, delayed) interim meetings to cover broader RFC6761 discussion points.  However I also have an elderly systems administrator’s eye towards extremely hard (and CABForum-sourced) deadlines and process, and I also hereby will admit my complete ignorant newbie-ness towards established procedure for DNSOP and RFC adoption.  

“Everybody has to be a learner-driver at least once.”  :-)

So I would like to invite the community, please, to pass comment and consideration on draft-appelbaum-dnsop-onion-tld-01 which (if necessary) can be addressed in one last round of edits-to and review-of the document; and if someone would also kindly point me towards the process for seeking a “call to adoption”, I would be most grateful. 

I hope to see all of the DNSOP processes - both established and ad-hoc - interlock in a graceful and well-oiled manner.

Many thanks and best wishes,

    - alec

Alec Muffett
Security Infrastructure
Facebook Engineering
London

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Gmane