ietf | 26 Jan 05:04 2015

lame delegation of toos.ietf.org

2 of 5 NSs look like lame delegations.

% dnsq a tools.ietf.org ns0.amsl.com
1 tools.ietf.org:
156 bytes, 1+0+5+0 records, response, noerror
query: 1 tools.ietf.org
authority: tools.ietf.org 1800 NS grenache.levkowetz.com
authority: tools.ietf.org 1800 NS merlot.levkowetz.com
authority: tools.ietf.org 1800 NS zinfandel.levkowetz.com
authority: tools.ietf.org 1800 NS cabernet.levkowetz.com
authority: tools.ietf.org 1800 NS gamay.levkowetz.com
% dnsq a tools.ietf.org merlot.levkowetz.com
^C
% dnsq a tools.ietf.org grenache.levkowetz.com
^C
% dnsq a tools.ietf.org zinfandel.levkowetz.com
1 tools.ietf.org:
274 bytes, 1+2+3+6 records, response, authoritative, noerror
query: 1 tools.ietf.org
answer: tools.ietf.org 600 A 209.208.19.222
answer: tools.ietf.org 600 A 64.170.98.42
authority: tools.ietf.org 1209600 NS gamay.levkowetz.com
authority: tools.ietf.org 1209600 NS merlot.levkowetz.com
authority: tools.ietf.org 1209600 NS zinfandel.levkowetz.com
additional: gamay.levkowetz.com 600 A 209.208.19.222
additional: gamay.levkowetz.com 600 28 &\007\361p\200\000\025\000\000\000\000\000\000\000\000\336
additional: merlot.levkowetz.com 600 A 194.146.105.14
additional: merlot.levkowetz.com 600 28 *\001\003\360\000\000\0001\000\000\000\000\000\000\000\024
additional: zinfandel.levkowetz.com 600 A 64.170.98.42
additional: zinfandel.levkowetz.com 600 28 \040\001\030\220\022:\000\000\000\000\000\000\000\001\000*
(Continue reading)

Hugo Maxwell Connery | 25 Jan 14:32 2015
Picon
Picon

Complying with draft-grothoff-iesg-special-use-p2p-names

Hi,

Below I show a trivial amount of work for compliance with
draft-grothoff-iesg-special-use-p2p-names by caching
recursive resolvers which have implemented Response
Policy Zones (i.e BIND and numerous others).  I am not
claiming that this is the best solution, or that it
is the best way to do this with RPZ, only that it
works, is efficient, is a one time job, and is trivial.

Summary for BIND:

* copy and paste to create one new zone file
* copy and paste about 10 lines into named.conf
* rndc reload

Following the config presented, I add more verbiage.

named.conf:

options
{
  // much other stuff ....

  response-policy
  {
     // pseudo-TLDs
     zone "pTLD"       policy NXDOMAIN;
  }
}
(Continue reading)

hellekin | 24 Jan 16:15 2015
Picon

P2PNames Draft 04: we're adding MORECOWBELL


Dear list members,

today the French newspaper Le Monde published information on a secret
NSA program, MORECOWBELL [0], that reveals the agency has been using the
DNS infrastructure to monitor host and website activity across the Internet.

This monitoring also enable Battle Damage Indication [1], a military
term to say in this case that DNS activity is indicative of physical
damage at a geographic location, and thus can be used to determine
whether a target has been destroyed, in the case the bad guys'
government didn't already shut it down themselves, so that the good guys
can "repeat the attack".

Peer-to-peer name systems using pTLDs effectively protect the Internet
infrastructure by removing authoritarian censorship as well as attack
vectors leading to physical destruction of servers.  To serve resilient
names and protect the safety of fellow sysadmins in exposed datacenters,
to give a different beat to the Internet: please support P2P Names.
Here is draft-04:

https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/

As always, you criticism and constructive feedback are very welcome!

If you tweet, please use the #P2PNames hashtag.

Thank you for you attention,

==
(Continue reading)

IETF Secretariat | 22 Jan 19:25 2015
Picon

ID Tracker State Update Notice: <draft-ietf-dnsop-dnssec-key-timing-06.txt>

IESG state changed to Approved-announcement to be sent from IESG Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

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

Alexander Mayrhofer | 22 Jan 16:38 2015
Picon

Review of edns-tcp-keepalive-01

Hi,

I've reviewed the keepalive draft. Generally, i do like the concept a lot because:  a) there's certainly a
use case that covers real operational issues  b) it's a space-efficient and c) unobstrusive. However, i
think the document could improve on clarity in certain aspects - see below for details. I've tagged  my
feedback with "NIT", "EDITORIAL", "PROTOCOL" to indicate "severity" levels of the comments. 

* EDITORIAL: I think the Abstract could be cut down to the first sentence of the second paragraph.
Everything else should go into (or is already a copy of) the Introduction section. Personal taste, i know,
but i like short, to the point abstracts.

* NIT: API is not expanded on first use

* EDITORIAL: The second paragraph on page 4 lists DNSSEC and crypto-related RRTypes as the culprits for the
prevalence of truncated responses. However, it misses the main point that increased response sizes are
the primary problem. So changing the text into something "The increasing size of response packets, (for
example due to deployment of DNSSEC and crypto-related RRTypes)... " would be better.

* EDITORIAL: Mention somewhere that the re-use of TCP connections to nameservers would even benefit more
in case DNS over TLS would be introduced. (Sidenote: From the architectural perspective, i think a
TLS-DNS spec should actually  REQUIRE  a TLS enabled DNS client to support the Keepalive option)

* PROTOCOL: I'm missing a normative and clear definition of how to interpret "TIMEOUT" values. The Option
format says "a timeout value for the TCP connection" (which is way underspecified, given the various
timeouts in TCP). 3.2.1 on the other hand says it's "representative of the minimum expected time an
individual session should remain established for it to be used..." (Which i interpret as the absolute
session duration from the time of establishment) - other sections of the document make me believe it's the
maximum interval between two subsequent queries ...

That needs to be fixed, because it will cause interop problems if not clearly defined. My proposal would be
(Continue reading)

Stephen Farrell | 22 Jan 16:11 2015
Picon
Picon

Stephen Farrell's No Objection on draft-ietf-dnsop-dnssec-key-timing-06: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-dnssec-key-timing-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I wish I'd had time to read this properly and ballot yes, but
I didn't, sorry;-) This is however good and useful work.

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

Kathleen Moriarty | 22 Jan 02:54 2015
Picon

Kathleen Moriarty's No Objection on draft-ietf-dnsop-dnssec-key-timing-06: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for
draft-ietf-dnsop-dnssec-key-timing-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please move Appendix A into section 1.3 as it would be better to have all
terms, symbols, and variables used in the draft defined in the
terminology section.  Russ Housley noticed this and I agree with him in
that it would be good to fix.

In 1.4 should this include key sizes as well since they are not
discussed?  I see the explanation in section 5 and am just wondering if
the procedures are the same when key properties change as opposed to
expiration and revocation, which are both mentioned in the draft.

The SecDir review found a few nits you should probably fix as well:
https://www.ietf.org/mail-archive/web/secdir/current/msg05318.html

(Continue reading)

internet-drafts | 22 Jan 02:37 2015
Picon

I-D Action: draft-ietf-dnsop-rfc6304bis-05.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 Sotomayor
	Filename        : draft-ietf-dnsop-rfc6304bis-05.txt
	Pages           : 25
	Date            : 2015-01-21

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)

The IESG | 20 Jan 16:52 2015
Picon

Protocol Action: 'Child To Parent Synchronization in DNS' to Proposed Standard (draft-ietf-dnsop-child-syncronization-07.txt)

The IESG has approved the following document:
- 'Child To Parent Synchronization in DNS'
  (draft-ietf-dnsop-child-syncronization-07.txt) as Proposed Standard

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Joel Jaeggli and Benoit Claise.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/

Technical Summary

This document specifies how a child zone in DNS can publish records
indicating to the parent zone to process and act on these records. It
does this by introducing a new Resource Record Type named CSYNC

Working Group Summary

Initially the WG attempting to combine this work with the
draft-ietf-dnsop-delegation-trust-maintainance document. However, it
became clearer they were two different approaches, and the request was
dropped.

Document Quality

Currently there are no implementations for the handling of this
RRType. It was implied that some of the public domain software
packages will deploy this, but have not so far.
(Continue reading)

Tim Wicinski | 20 Jan 16:37 2015
Picon

Followup Discussion on TCP keepalive proposals

All

Way back, we had a draft that was adopted by the working group on TCP 
Keepalives (draft-ietf-dnsop-edns-tcp-keepalive).   Prior to IETF91, we 
received an alternative proposal that was then presented 
(draft-bellis-dnsop-connection-close).  There was some discussion during 
the meeting, but the consensus of the room was to return the discussion 
to the group and review the choices and make a decision.

The author of the tcp-keepalive draft has stated they do not see a use 
case anymore, but was approached by others who had a need for it.

The chairs are wondering:
	1) if their is still have a need for such an option,  and

	2) if there is consensus on competing proposals.

If you see a use case for the EDNS tcp-keepalive option as originally 
discussed, please say so, on the list, by February 4, 2015.

If you want to pursue the connection-close draft, please say so, on the 
list, by February 4, 2015, especially if you're willing to work on it.

If we don't hear anything about either, we drop them both.

For the chairs,
tim

_______________________________________________
DNSOP mailing list
(Continue reading)

Paul Hoffman | 19 Jan 23:16 2015

New version of the DNS terminology draft

Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on
the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version
and give feedback. Thanks!

Name:		draft-hoffman-dns-terminology
Revision:	01
Title:		DNS Terminology
Document date:	2015-01-19
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt
Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/
Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-terminology-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01

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


Gmane