Paul Hoffman | 29 Mar 19:30 2015

Summary of the two options in draft-ietf-dnsop-cookies?

Greetings again. Can one of you summarize the differences between sections 4/5 and 6/7 in the recent -01
draft? It seems that the error code processing in 4/5 might either be useful or overkill.

A related question for Don: how close are you to getting draft-eastlake-fnv published? For me, it is
mandatory for that draft to be stable (and hopefully published) before we publish
draft-ietf-dnsop-cookies in order to make developers comfortable in deploying cookies without
possibly opening servers and clients to CPU DoS attacks.

--Paul Hoffman
DNSOP mailing list
DNSOP <at>

David C Lawrence | 26 Mar 19:44 2015

Seeking edns-client-subnet implementers

At IETF this week it was decided to refocus the effort on the
edns-client-subnet draft on only documenting the existing behaviour of
deployed implementations.

To clarify some areas that were un/under-specified I am looking for
implementers of both recursive and authoritative servers at the
following "Participants" companies listed at

  * EdgeCast
  * CDNetworks
  * BitGravity
  * Comodo
  * Incapsula
  * Tencent
  * DNSPod
  * Amazon / AWS

I've got contacts for others on the list already.

If you have an implementation but are not on that Participants page I
would like to hear from you too.

Apologies for those of you who got double copies of this message
because of the two lists that I've sent it to.

Thank you.

(Continue reading)

Suzanne Woolf | 26 Mar 00:51 2015

meeting materials links


We'll be getting out the formal minutes ASAP but I had a request yesterday for the pointer to the meeting
materials, and since the URL is not that obvious, I'm sending it here:

The materials page can be reached from the "Meeting Materials" link on

Also, per some conversation earlier today on the list, pointers to jabber logs and other resources can be
found at:

There's a pointer to the main agenda from the page as well, and the version with the pointers to
jabber logs etc. can be reached as the "tools-style agenda" from there.


DNSOP mailing list
DNSOP <at>

Evan Hunt | 25 Mar 21:50 2015

another way to minimize ANY responses

Last night the dumb-idea fairy visited me as I was falling asleep, and
suggested that another way to reduce the impact of ANY queries would be
to pick *one* rrset and return just that. (Probably the numerically
smallest rrtype present at the node, plus RRSIGs if any.)

This avoids poisoning caches with false NODATA, it works for both DNSSEC
and non-DNSSEC zones, meets djb's requirements, makes ANY responses small,
and we don't need to argue about what rrtype to use for synthesized
responses in non-DNSSEC answers.  Still leaks some data (which admittedly
undermines the motivation of Olafur's draft) but not as much and what gets
leaked would be trivial to acquire by other means anyway.


Evan Hunt -- each <at>
Internet Systems Consortium, Inc.

DNSOP mailing list
DNSOP <at>

kato | 25 Mar 06:19 2015


Sorry for most of the following comments on
draft-ietf-dnsop-root-loopback-01 applicable to its appendices.

It is better to describe that the update of the zone can be delayed a
little bit as no NOTIFY message is sent to the root-on-loopback.

In Appendix A, the root servers listed allow AXFR currently, but I am
afraid they don't guarantee it in the future. It may be necessary to
confirm it with the operator of each root server listed.

In Appendix B, most of the IP addresses of the root DNS servers are
anycasted. They are not suitable for the target to pull the zone data
in AXFR over TCP.

Also it must be noted that these addresses may change over time (while
the frequency is not high), it may need to give a warning to
periodically check if the addresses are valid. Generating the
configuration after priming query? (this is a joke)

IMHO, it may necessary to establish an infrastructure to distribute
root zone in scalable/reliable manner.

-- Akira Kato

DNSOP mailing list
DNSOP <at>

(Continue reading)

Richard Lamb | 24 Mar 22:24 2015

Re: MIXFR: Smaller IXFR in the DNSSEC case

Fwiw i believe there is a clear need for this work.  Having been involved with various early DNSSec deployment efforts, the diminished value of ixfr has resulted in a few different home grown hybrid solutions to capture the efficiency of rsync with added notification functionality.  It would be good if we just "fixed" ixfr.  -Rick

On Thursday, January 15, 2015, Matthijs Mekking <matthijs <at>> wrote:
Hi wg,

IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
this? Olafur and I have some ideas on keeping those zone transfers
small. Your feedback is appreciated.

Best regards,

DNSOP mailing list
DNSOP <at>
DNSOP mailing list
DNSOP <at>
Dave Lawrence | 24 Mar 23:02 2015

DNS terminology draft

Paul, would you consider adding something like these, with whatever
modifications seem necessary?  Maybe under Resource Records, since
that is where OPT is.

One thing that has been experience by many of us in different
organizations, and which actually has shown its head within
discussions with IETF people this week who are not in the DNS
community, is that they very, very commonly think of the EDNS
client-subnet option as being "EDNS0".  Those of us involved with ECS
constantly try to educate people about this, especially since there
are currently very few EDNS options and this is the only one that
seems to be known by people outside of the DNS community.


EDNS / EDNS0 -- The Extension Mechanisms for DNS, defined by
[RFC6891], are an addition to the original message format to allow DNS
agents [which I acknowledge is not defined, but by which I mean to
indicate "any software which speaks DNS"] to specify message sizes
larger than the original 512 octet limit, to expand the response code
space, and to potentially carry additional options that affect the
handling of a query.  EDNS can be versioned, but currently the only
version in public use is EDNS0.

ECS / EDNS client-subnet -- An EDNS option principally for carrying
information from a resolver to an authoritative server about
the general network location of a client of the resolver.  This is
generally used by full service resolves who serve clients from a
diverse network topography to get response from authoritative servers
that tailor their responses based on client location.

[This also seems to be missing as a commonly seen token:]

RRTYPE [RRType?] -- A mnemonic or numeric value representing the type
of data carried in an RR, as defined in [RFC1035] section 3.2, which
impacts how its RDATA is interpreted.  The full set of assigned values
is listed at [IANA reference].

RDATA -- The data portion of an RR, as defined in [RFC1035].  Its
format and semantics varies by RRTYPE.


PS: I tend to use NXRRSET as slightly more expressive than NODATA,
though it is an extended rcode for dynamic update.  Worth mentioning
along with the NODATA definition, or am I pretty much solo in using
the term this way?

DNSOP mailing list
DNSOP <at>

Francis Dupont | 24 Mar 21:39 2015

go further about DNS over TCP?

As we have more and more DNS over TCP (large responses, response
rate limitation, even TLS for privacy) I think we should fix the
way DNS over TCP is supposed to be handled by servers.
Quoting RFC 1035 4.2.2 "TCP usage":

   - The server should assume that the client will initiate
     connection closing, and should delay closing its end of the
     connection until all outstanding client requests have been

   - If the server needs to close a dormant connection to reclaim
     resources, it should wait until the connection has been idle
     for a period on the order of two minutes.  In particular, the
     server should allow the SOA and AXFR request sequence (which
     begins a refresh operation) to be made on a single connection.
     Since the server would be unable to answer queries anyway, a
     unilateral close or reset may be used instead of a graceful

A 2mn timeout simply has no chance to scale.

So I propose:
 - make clear that TCP support is mandatory.
 - allow servers to use the timeout they like, even a zero timeout
  (the last point should be discussed). Note a zero timeout doesn't
  mean "send the response and close" but "send the response, check
  there is not pending query, and close".

Now there are the not technical questions to solve first:
 - is DNSOP chartered to do this? Point 4 says "protocol maintenance"
  and point 5 allows more if the area director agree.

 - is 5966bis the right place? I don't think so but another
  document means the 5966bis will be delayed...


Francis.Dupont <at>

PS: I'll try to raise this at the mic if there is still enough time
(as this message is sent during the DNSOP session at the 92th IETF).

DNSOP mailing list
DNSOP <at>

Shumon Huque | 24 Mar 21:03 2015

comments on DNS terminology draft

Some comments on draft-hoffman-dns-terminology

>    NODATA -- This is not an actual response code, but instead is the
>    combination of an RCODE of 0 (NOERROR) and an Answer section that is
>    empty.  That is, it indicates that the response is no answer, but
>    that there was not supposed to be one.  [72]Section 1 of [RFC2308]
>    defines it as "a pseudo RCODE which indicates that the name is valid,
>    for the given class, but are no records of the given type."

I don't think this definition is precise enough. Under this stated
definition, "referral responses" from authority servers qualify to be
called NODATA responses, because they also have a combination of
RCODE 0 and an empty answer section. Referrals can be excluded from
this definition by adding the constraint that NODATA responses from
authority servers have the AA bit set.

I'd also recommend starting the definition with a clear statement of
what it means first, followed by how it is represented in terms of packet
attributes. The current definition is in the reverse order which is
more difficult to read (at least for me). Here's my suggested rewrite:

    NODATA -- This is not an actual response code, but is a particular
    type of response from a server that indicates that the queried domain
    name exists for the given class, but the resource record type being
    queried for doesn't exist. They are a combination of an RCODE of 0
    (NOERROR) and an Answer section that is empty. In addition, NODATA
    responses from authoritative servers have the authoritative answer
    (AA bit) set to one. Section 1 of [RFC2308] defines it as "a pseudo
    RCODE which indicates that the name is valid, for the given class,
    but are no records of the given type.

Should we also mention that NODATA responses usually include a SOA record
in the authority section to indicate to resolvers how long to do negative
caching for?

> [73]5.  Resource Records
>    RR -- A short form for resource record.  ([74]RFC 1034, section 3.6.)
>    RRset -- A set of resource records with the same label, class and
>    type, but with different data.  (Definition from [75]RFC 2181) Also
>    spelled RRSet in some documents.  As a clarification, "same label" in
>    this definition means "same owner name".

I think the 'same TTL' constraint is important enough to restate specifically
as part of this definition. I suggest adding:

     In addition, RFC 2181 states that "the TTLs of all RRs in an RRSet
     must be the same."

>    SOA field names -- DNS documents, including the definitions here,
>    often refer to the fields in the RDATA an SOA resource record by
>    field name.  Those fields are defined in [78]Section 3.3.13 of RFC 1035.
>    The names (in the order they appear in the SOA RDATA) are MNAME,
>    meaning of MINIMUM field is updated in [79]Section 4 of RFC 2308; the new
>    definition is that the MINIMUM field is only "the TTL to be used for
>    negative responses".

"Negative responses" is used here without a clear definition anywhere
earlier (or later) in the document. I think that definition needs to be
added. Is it only NXDOMAIN and NODATA responses? Or does it also include
failure responses (SERVFAIL, NOTIMP, or any of the extended response codes)?

The "Negative Caching" definition provided later in the document, quoting
RFC 2308 ("The storage of knowledge that something does not exist, cannot
give an answer, or does not give an answer") seems to imply that negative
responses include SERVFAIL, NOTIMP, etc.

> [80]6.  DNS Servers

"DNS Servers and Clients" - immediately below we state that the
section talks about both.

>    This section defines the terms used for the systems that act as DNS
>    clients, DNS servers, or both.  Some terms about servers describe
>    servers that do and do not use DNSSEC; see [81]Section 8 for those
>    definitions.
>    [[ There is a request to "first describe the iterative and recursive
>    resolution processes, and mention the expected values of the RD,RA,AA
>    bits.  Then you can describe the distinctions between recursive and
>    iterative clients, and between recursive and authoritative servers,
>    in terms of the roles they play in the different resolution
>    processes."  This would require the section to be quite different
>    than the other sections in the document. ]]

That is one approach. I agree this section probably needs a significant
rewrite for clarity and precision. I find the current definitions of
the family of resolvers to be quite convoluted.


>    Authoritative server -- A system that responds to DNS queries with
>    information about zones for which it has been configured to answer
>    with the AA flag in the response header set to 1.  It is a server
>    that has authority over one or more DNS zones.  Note that it is
>    possible for an authoritative server to respond to a query without
>    the parent zone delegating authority to that server.

Missing from this definition is the fact that Authoritative Servers
also provide "referrals" (with AA=0 and referral data) to child zones
delegated from them.

>    Slave -- An authoritative server which uses zone transfer to retrieve
>    the zone.  (Quoted from [88][RFC1996], section 2.1)

Is this the only definition? I believe it's possible for there to be
slave servers which transfer a copy of the zone data in some other
manner (i.e. not using the DNS zone transfer protocol).

Is "Secondary Server" (also fairly commonly used) a synonym for this?

>    DNS forwarder -- A system receives a DNS query, possibly changes the
>    query, sends the resulting query to a recursive resolver, receives
>    the response from a resolver, possibly changes the response, and
>    sends the resulting response to the stub resolver.  Section 1 of [94]RFC
>    [95]2308 describes a forwarder as "a nameserver used to resolve queries
>    instead of directly using the authoritative nameserver chain".  RFC
>    further says "The forwarder typically either has better access to the
>    internet, or maintains a bigger cache which may be shared amongst
>    many resolvers."
>    [RFC5625] does not give a specific definition for DNS forwarder, but
>    describes in detail what features they need to support.  The protocol
>    interfaces for DNS forwarders are exactly the same as those for
>    recursive resolvers (for interactions with DNS stubs) and as those
>    for stub resolvers (for interactions with recursive resolvers).

Perhaps I'm not reading it right, but the 2 paragraphs above seem to me
to have contradictory definitions of forwarder.

Do we need to also define the terms "DNS proxy" and  "DNS ALG (application
layer gateways)"?

>    Authoritative data -- RRsets in the Answer section of a DNS response
>    that has the AA bit in the response header set to 1.
>    Delegation -- The process by which a separate zone is created in the
>    name space beneath a given domain.  Delegation happens when an NS
>    RRset is added in the parent zone for the child origin, and a
>    corresponding zone apex is created at the child origin.
>    Apex -- The SOA and NS RRsets at the origin of a zone.  This is also
>    called the "zone apex".

Why is it only the SOA and NS RRsets? I would suggest defining it in
terms of the domain name. Isn't this what the original RFCs defined as
the 'top node' (and not specific types of data sets that exist at the
top node)?

Shumon Huque

DNSOP mailing list
DNSOP <at>
Tim WIcinski | 24 Mar 19:08 2015

Status of current WG Documents

Status of current WG Documents

In an effort to expedite the agenda along during the DNSOP meeting, we 
wanted to give an update of Working Group Documents and where they stand.

	Now RFC 7477, complete with Errata!

draft-ietf-dnsop-as112-dname - In RFC Edit state
draft-ietf-dnsop-rfc6304bis - In RFC Edit

draft-ietf-dnsop-rfc6598-rfc6303  - WG Chair write up

	Need final discussion on updating Figure 5.

	Revived!! and ready for reviews

	Decision needed: Error Code in the option field or not?

	Ready to move to WGLC, only pushback from one reviewer

	Chair need to summarize the discussion from last month and
	determine next steps (this week)

Drafts that are being actively edited:

	Actively edited but some operational questions
	Question of adding another EDNS option

	Needs a kick from the authors.

Discussion Time during the meeting:

DNSOP mailing list
DNSOP <at>

Suzanne Woolf | 23 Mar 17:46 2015

admin for IETF 92


In the interests of keeping our packed agenda moving tomorrow….

Please let the chairs know ASAP if you're willing to be a notetaker or jabber scribe for the meeting. 

Please volunteer if you can-- it's a good way to learn in-depth what's going on in the WG. Also, I'm told there
are shiny stickers for your meeting badge.

Tim & Suzanne

DNSOP mailing list
DNSOP <at>