internet-drafts | 31 Jul 22:11 2014
Picon

I-D Action: draft-ietf-dnsop-rfc6304bis-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           : AS112 Nameserver Operations
        Authors         : Joe Abley
                          William F. Maton
	Filename        : draft-ietf-dnsop-rfc6304bis-04.txt
	Pages           : 30
	Date            : 2014-07-31

Abstract:
   Many sites connected to the Internet make use of IPv4 addresses that
   are not globally-unique.  Examples are the addresses designated in
   RFC 1918 for private use within individual sites.

   Devices in such environments may occasionally originate Domain Name
   System (DNS) queries (so-called "reverse lookups") corresponding to
   those private-use addresses.  Since the addresses concerned have only
   local significance, it is good practice for site administrators to
   ensure that such queries are answered locally.  However, it is not
   uncommon for such queries to follow the normal delegation path in the
   public DNS instead of being answered within the site.

   It is not possible for public DNS servers to give useful answers to
   such queries.  In addition, due to the wide deployment of private-use
   addresses and the continuing growth of the Internet, the volume of
   such queries is large and growing.  The AS112 project aims to provide
   a distributed sink for such queries in order to reduce the load on
   the corresponding authoritative servers.  The AS112 project is named
(Continue reading)

Mark Andrews | 31 Jul 06:14 2014

DNS URI code point wire format


	When DNS code points are issued based on the request template
	the wire and presentation values are supposed to be fixed.

	URI was issued against draft-faltstrom-uri-05/06.  The wire
	format has been changed in draft-faltstrom-uri-08 in
	particular how the target field is encoded.

	named implemented URI as per draft-faltstrom-uri-05/06
	unbound implemented URI as per draft-faltstrom-uri-08

	We now have two incompatible implementations in the wild.

	We are going to change named to implement draft-faltstrom-uri-08.
	The changes were just committed and will be available in
	the upcoming maintainence releases.

	I would suggest that IANA update or otherwise make a note
	that the wire encoding is that from draft-faltstrom-uri-08
	or else there will be future incompatibilities.

	Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
(Continue reading)

Fernando Gont | 28 Jul 14:24 2014
Picon

DNS, fragmentation, and IPv6 extension headers

Folks,

(Apologies if this has been debated to death already).

At the last IEPG meeting we presented some results regarding the
filtering of packets that employ IPv6 extension headers (please see:
<http://www.iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>).
The packet drop rates range from 10% to over 50%, depending on the
dataset (FWIW, these packets drops have nothing to do with DNS-specific
packet-drops caused by sloppy firewalls or the like).

This essentially raises the question of "What's the plan for
transporting DNS queries/responses in IPv6?"

At different venues (including the IETF), I've received/listened_to
different opinions. Quite a few folks usually argue "oh, that's simple:
we'll use TCP", while others tend to argue that "one should be careful
when thinking about relying on TCP for DNS queries/responses" (e.g. see
<http://www.iepg.org/2013-11-ietf88/2013-11-Time-Value-DNS.pdf>).

While this issue/question may be currently masqueraded by the fact that
we still have IPv4, I wonder what's "the plan" for the IPv6 case (at
some point, we'll have to rely on whatever such plan is).

If the answer is "fall-back to TCP if UDP doesn't work", my next
question would be "does popular DNS server software implement
mitigations for TCP-based attacks?" (zero-windows, FIN-WAIT-X flooding,
etc.)

Thoughts?
(Continue reading)

Edward Lewis | 27 Jul 00:53 2014
Picon
Picon

Re: Changing NSEC3 salts regularly is useless

There’s a lot of guidance needed for operators and tools developers (who set defaults) with regards to
DNSSEC.  (I.e., Define and quantify “useless.”)

Three old presentations on studies (involving operations TLDs only) I have done on this topic in 2012:

http://iepg.org/2012-03-ietf83/IETF83IEPGLewis.pdf
(how the protocol engineer’s expectations differed from what operators were doing)

https://ripe64.ripe.net/presentations/46-RIPE64PlenaryTLDDNSSEC.pdf
(began to analyze the difference between protocol engineering and operations)

https://www.nanog.org/meetings/nanog56/presentations/Tuesday/tues.general.lewis.14.pdf
(same, based on more data)

If you are going to produce such a document, cover a range of choices being made, including the salt change
frequency.  There’s been a strong need for a DNSSEC implementers guide covering cryptographic
parameter selection ever since well, forever.  Yes we have NIST 800-81 (http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf).

One issue with the salt (in particular) is that the RFC recommendation is (RFC 5155  Appendix C.1) says this:

"The salt SHOULD be changed periodically to prevent pre-computation using a single salt.  It is
RECOMMENDED that the salt be changed for every re-signing."

This was written without dynamically updated zones in mind (or so I’m guessing - 5155 is “not my
fault” ;) ).

On Jul 24, 2014, at 18:02, Mark Andrews <marka <at> isc.org> wrote:

> 
> I just sent the following to bind-users.  We need to kill the myth
(Continue reading)

Mark Andrews | 25 Jul 00:02 2014

Changing NSEC3 salts regularly is useless


I just sent the following to bind-users.  We need to kill the myth
that changing NSEC3 salt provides any real benefit.

"Actually it is useless to change the salt regularly.  Changing the
salt provides no real benefit against discovering the names in a
zone which is the reason people were saying to change the salt.

The attacker uses cached NSEC3 records.  When it gets a cache miss
it asks the servers for the zone, puts the answer in the cache and
continues.  When the salt changes it just maintains multiple nsec3
chains eventually discarding the old nsec3 chain eventually.  I
would wait until the new NSEC3 chain has as many cached records as
the old NSEC3 chain.  Changing the salt slows things up miniminally
for a very short period of time after the change.  Additionally
once you have some names you ask for those names for a non-exisisting
type to quickly pull in part of the new NSEC3 chain you know exists.

The only reason to change the salt is if you have a collision of
the hashed names.  This will be a very very very rare event."

Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
(Continue reading)

David Conrad | 22 Jul 16:22 2014

Masataka Ohta's 2004 draft...

Since I mentioned it and some folks said "where is it?":

http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03

Regards,
-drc

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Suzanne Woolf | 22 Jul 13:12 2014
Picon

scribes, notetakers

As usual…..desperately needed. Any volunteers in advance will be welcome.

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

Stephane Bortzmeyer | 21 Jul 03:10 2014
Picon

AD bit with DNS64

The resolver on the IETF NAT64 network at the Royal York hotel in
Toronto sets the AD bit when the zone is signed, even when we ask it
about a AAAA record... which does not exist in the zone.

I checked the RFC on DNS64, RFC 6147 (specially section 3). The IETF
resolver is "security-aware" and "validating". RFC 6147 says "the
resolver should also set the Authentic Data (AD) bit on the response"
For me, it seems obvious for me that it is true only if the data has
been actually validated, which is not possible for the synthetized
AAAA record. Do I read the RFC correctly?

Unsigned domain, AD is absent, which is expected:

% dig AAAA twitter.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> AAAA twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30741
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;twitter.com.		IN AAAA

;; ANSWER SECTION:
twitter.com.		30 IN AAAA 64:ff9b::c710:9c46
twitter.com.		30 IN AAAA 64:ff9b::c710:9c66
twitter.com.		30 IN AAAA 64:ff9b::c710:9cc6
(Continue reading)

Tim Wicinski | 20 Jul 22:39 2014
Picon

Final Agenda Uploaded (probably)


All

I've uploaded the final agenda for Tuesday Morning.  If you have not 
sent us slides you should make it an effort to do so before we shame you 
into doing so.

And thank you to the few who have sent us your slides. We'll start 
uploading them tonight.

See you Tuesday Morning Bright and Early!

tim

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

Andrew Sullivan | 18 Jul 20:05 2014

draft-ietf-dnsop-dnssec-key-timing

Dear colleagues,

I've had a look at draft-ietf-dnsop-dnssec-key-timing-04.  I have no
objections to the alterations to the document, and I say again what
I've been saying for, I think, two years now (maybe more): giving
useful advice, even if not perfect, on this topic will be more helpful
than producting perfect advice.  It ought to be easy to update the
document if we see that some things need improvement.  Many people are
deeply confused about key rollovers.  If we get the document out and
people start complaining about what's wrong with it, at least we'll
have evidence about what to improve.

Please publish it.

Best regards,

A

--

-- 
Andrew Sullivan
ajs <at> anvilwalrusden.com

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

The IESG | 15 Jul 16:34 2014
Picon

Last Call: <draft-ietf-dnsop-rfc6304bis-03.txt> (AS112 Nameserver Operations) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'AS112 Nameserver Operations'
  <draft-ietf-dnsop-rfc6304bis-03.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-07-29. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Many sites connected to the Internet make use of IPv4 addresses that
   are not globally-unique.  Examples are the addresses designated in
   RFC 1918 for private use within individual sites.

   Devices in such environments may occasionally originate Domain Name
   System (DNS) queries (so-called "reverse lookups") corresponding to
   those private-use addresses.  Since the addresses concerned have only
   local significance, it is good practice for site administrators to
   ensure that such queries are answered locally.  However, it is not
   uncommon for such queries to follow the normal delegation path in the
   public DNS instead of being answered within the site.

   It is not possible for public DNS servers to give useful answers to
   such queries.  In addition, due to the wide deployment of private-use
   addresses and the continuing growth of the Internet, the volume of
   such queries is large and growing.  The AS112 project aims to provide
(Continue reading)


Gmane