Stephane Bortzmeyer | 28 Feb 18:27 2015

[TCP] edns-tcp-keepalive, and 5966bis

[Reflections of the week-end.]

There have been some discussions
(<> or
<>) in
juanary on draft-ietf-dnsop-edns-tcp-keepalive and
draft-bellis-dnsop-connection-close. I've seen no discussion of their
interaction with draft-ietf-dnsop-5966bis. Basically, both
draft-ietf-dnsop-edns-tcp-keepalive and
draft-bellis-dnsop-connection-close try to improve signalling between
the DNS client and the server, while draft-ietf-dnsop-5966bis say that
clients and servers can do what they want with connections and the
other party should be ready to deal with it.

Since we always have to manage broken software and network glitches,
DNS programs will have to handle bad clients and servers, anyway. If
so, what is the point of having a better signalling? Is it worth the
cost (in implementation, and WG time)? Shouldn't we focus only on
5966bis and drop the two others?

Otherwise, three typos in

* "truncacated" instead of truncated

* "that that specific TCP session" (too many thats)

* "indefinately" instead of indefinitely

(Continue reading)

Stephane Bortzmeyer | 28 Feb 17:46 2015

Agenda for Dallas?

I see <> we have a
slot on Tuesday but I cannot find a discussion about an agenda. It's
specially important since we have a _lot_ of work on the bench

I believe that draft-hoffman-dns-terminology, although not WG item,
deserves a slot since it is a very important work, everything else
potentially depending on it.

I do not ask immediately a slot for
draft-ietf-dnsop-qname-minimisation since it seems the biggest
problems are the lack of reviews (and the lack of running code but I'm
working on it). Reviewers, please go ahead!

DNSOP mailing list
DNSOP <at>

Stephane Bortzmeyer | 28 Feb 17:20 2015

[Qname minimisation] Tony Finch's algorithm on zone cut finding implemented

For those who want to play with the zone cuts (finding them is
necessary for qname minimisation), here is a simple implementation of
appendix A of draft-ietf-dnsop-qname-minimisation-01:

Implemented in France, so I can safely ignore
<> (see

This code implements the "aggressive" strategy (the most
privacy-efficient) of section 2 of

Here are some interesting examples. Remember that this ultra-simple
program has no cache at all so it is the equivalent of a cold
resolver. First, a trivial case,

% ./zonecut -q=1 -v
Searching 1 for

Zone cut at "."
Querying type 2 for name org. at server
Result for "org.": Referral(s)

Zone cut at "org."
Querying type 2 for name at server
Result for "": Referral(s)

Zone cut at ""
(Continue reading)

Allison Mankin | 26 Feb 17:24 2015

IPR disclosure related to draft-ietf-dnsop-root-loopback

Expected that this would create an automatic mail to the WG but it apparently is not going to, so here is a signal boost for a disclosure filed yesterday:

DNSOP mailing list
DNSOP <at>
Wang Wei | 25 Feb 02:55 2015

New Version Notification for draft-wang-dnsop-cachesurvey-00.txt

Hi all,


Enlightened by Workshop on DNS Future Root Service Architecture in Hongkong, Dec,2014, we submitted a draft about the DNS cache survey in China.

We hope the survey results may provide some useful information to better understand the current cache service model.

Any comments and feedbacks are all welcome.





Zhiwei YAN


DNSOP mailing list
DNSOP <at>
Paul Hoffman | 24 Feb 23:21 2015

Definitions of foo-centric

Greetings again. People have asked us to define "delegation-centric", "child-centric", and
"parent-centric" for draft-hoffman-dns-terminology. None of them are defined in RFCs, even though
"delegation-centric" appears in RFCs 4956, 5155, and 7129. The terms are used in various places, so they
seem like good candidates for the terminology document.

Proposals for definitions are welcome.

--Paul Hoffman
DNSOP mailing list
DNSOP <at>

Joel Jaeggli | 24 Feb 21:06 2015

Re: revisiting outstanding dicusses for 6304bis

Working group, 

I would direct your attention to the current discuss, here:

Should we consider recommendations with respect to treatment of logging or storage of queries or the extent to which such queries should be protected? 


Sent from my iPhone

On Feb 23, 2015, at 08:25, Kathleen Moriarty <kathleen.moriarty.ietf <at>> wrote:

On Mon, Feb 23, 2015 at 10:21 AM, Paul Hoffman <paul.hoffman <at>> wrote:
On Feb 23, 2015, at 7:13 AM, Kathleen Moriarty <kathleen.moriarty.ietf <at>> wrote:
> Thanks for bringing this to my attention.  The updated text points out the risk, but it would have been nice seeing it phrased in a way to encourage mitigation of that risk (recommend not to log).  It'd easier to attack a system and gain access to logs than to observe session traffic.

AS112 operators do so for the public benefit. There are very good operational reasons why they *should* log, in order to help find bugs and to provide better service. You are asking that the very tiny chance of a privacy breach should trump that operational benefit.

As an FYI - I wouldn't put this in the privacy bucket, but rather security as it reveals information about a network that could be used in future attacks against the organization leaking their data. 

The mention of the privacy issue with logging is sufficient, and going further would have negative consequences to the operations of this service.

Mitigating the risks could be helpful and might mean protecting access to logs in cases where logs must be generated. 


--Paul Hoffman


Best regards,
DNSOP mailing list
DNSOP <at>
Hosnieh Rafiee | 23 Feb 14:00 2015

DNS terminology


Is there any single document for all DNS terms to be used as a reference in order to avoid defining them in a
document. The terms I am looking for is all general DNS terms -- authoritative name server, resolver,
client, host, etc.? 


DNSOP mailing list
DNSOP <at>

internet-drafts | 23 Feb 05:01 2015

I-D Action: draft-ietf-dnsop-cookies-01.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           : Domain Name System (DNS) Cookies
        Authors         : Donald E. Eastlake
                          Mark Andrews
	Filename        : draft-ietf-dnsop-cookies-01.txt
	Pages           : 34
	Date            : 2015-02-22

   DNS cookies are a lightweight DNS transaction security mechanism that
   provides limited protection to DNS servers and clients against a
   variety of increasingly common denial-of-service and amplification /
   forgery or cache poisoning attacks by off-path attackers. DNS Cookies
   are tolerant of NAT, NAT-PT, and anycast and can be incrementally

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

DNSOP mailing list
DNSOP <at>

Daniel Kahn Gillmor | 20 Feb 20:12 2015

OpenSSH 6.8 will default UseDNS to "no"

Hi dnsops folks--

This is a minor thing, but something i'd like to see happen more often.

At the WG meeting in November of last year, there was a clear sense in
the room that everyone agreed (and maybe had for years?) that OpenSSH's
sshd should not be using reverse DNS lookups on client IP addresses as
any sort of security check.

I reported that discussion to the OpenSSH development mailing list.  The
next version of OpenSSH (v6.8) is now set to be released with the
following change:

 * sshd(8): UseDNS now defaults to 'no'. Configurations that match
   against the client host name (via sshd_config or authorized_keys)
   may need to re-enable it or convert to matching against addresses.

If there are other instances of popular software that does unreasonable
or unsafe things with the DNS by default, please reach out to the
developers of that software and encourage them to change.  Developers do
listen, and we can improve the state of the network by engaging with
other implementors. :)

If you're not sure who to contact for a particular piece of software,
I'm happy to help you try to find the right channels for discussion.



(i'm not subscribed to dnsops, please cc me on replies you want me to

DNSOP mailing list
DNSOP <at>

Edward Lewis | 20 Feb 16:17 2015

Is there a concise and comprehensive definition of a "zone file"?

I’m hoping to be able to use terms like “canonical zone file” (to define a
file that has lines like FQDN/TTL/CLASS/TYPE/RDATA) - as opposed to other
‘equivalent’ versions of a zone file.  I’d also like to see a delineation
of all of the “dollar-directives” (like $TTL, $ORIGIN, $INCLUDE and
$GENERATE) defined in a document.

Not to mention escape rules.

This just flashed back at me.  Two RFCs had examples of SIP DNS entries.
One presented the line with escapes according to (what I’ll call) BIND’s
parsing rules and the other presented the line with how a person would
normally write it.  This was called to my attention when a SIP implementer
was confused over the differences because the escape rules were not that
obvious to a non-BIND-experienced person.

(And I’d like to distinguish between preferred encodings - is \075 or ‘K’

Does such a thing exist (in one document)?

Where I am going with this is - when one wants to automate looking at zone
files today, there are many varied formats to consider.  (Kind of like
WhoIs.)  With the inclusion of S-labels in some zone files I have seen,
what was once simple parsing means loading in IDNA2008 libraries.

And given the flashback I just related, it would be good to recommend how
DNS records are shown in RFCs - for the sake of consistency between

IMHO, it would be good to (ahem) ‘clarify’ what is meant by a zone file.
And how to write or document a DNS record.

I’m been thinking that this is needed - or maybe I’ve overlooked a
document that’s already in use.  So I’m asking if anyone knows of a

Attachment (smime.p7s): application/pkcs7-signature, 6226 bytes
DNSOP mailing list
DNSOP <at>