Paul Hoffman | 7 Feb 01:36 2016

Setting the AD bit in the query changes whether you get the AD bit in the response?

Greetings again. While doing some testing, I came across something that 
is both consistent across implementations but that I do not find in RFC 
4033, 4034, or 4035. If a query for a properly-signed zone is sent to 
BIND-as-recursor, Unbound, or Google DNS, and the AD bit in the request 
is set to 1, the answer returned has the AD bit set to 1. However, if 
the query has the AD bit set to 0, the response always has the AD bit 
set to 0, even though the requested zone is properly signed.

This happens regardless of whether or not there is an EDNS0 extension 
with the DO bit set to 1.

I can't find anywhere in 403[3:5] that says that the AD bit in the 
request means anything. Did I miss that? Or is it specified in a 
different RFC?

--Paul Hoffman

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

Jiankang Yao | 6 Feb 09:05 2016
Picon

New Non-WG Mailing List: Bundled-domain-names -- Discussion of"bundled domain names"


Dear all,

    There is a New Non-WG Mailing List: Bundled-domain-names -- Discussion of"bundled domain names".
    Welcome to join this list for a discussion.
    To subscribe: https://www.ietf.org/mailman/listinfo/bundled-domain-names


Thanks.

Jiankang Yao


发件人: "IETF Secretariat";<ietf-secretariat <at> ietf.org>;
发送时间: 2016年2月4日(星期四) 下午3:03
收件人: "IETF Announcement List"<ietf-announce <at> ietf.org>;
抄送: "yaojk"<yaojk <at> cnnic.cn>; "bundled-domain-names"<bundled-domain-names <at> ietf.org>;
主题: New Non-WG Mailing List: Bundled-domain-names -- Discussion of"bundled domain names"


A new IETF non-working group email list has been created.

List address: bundled-domain-names <at> ietf.org.
Archive: https://mailarchive.ietf.org/arch/search/?email_list=bundled-domain-names

To subscribe: https://www.ietf.org/mailman/listinfo/bundled-domain-names


Purpose:

This list is for discussion of DNS identical resolution for mapping one name entirely to another name
(bundled names). CNAME maps one name to another name. DNAME maps its descendants to another domain name.
If a domain wants to map itself *and* its descendants to another domain name, what should we do? This list
(Continue reading)

Tony Finch | 5 Feb 23:10 2016
Picon

draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

Last weekend one of our authoritative name servers
(authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
rather unhappy. Over the last week I have developed a patch for BIND to
implement draft-ietf-dnsop-refuse-any which should allow us to handle
ANY flood attacks better. http://fanf.livejournal.com/140566.html

I still have a potential problem with RRSIG queries, which work a lot like
ANY queries. Cloudflare's approach is to simply refuse them, which makes a
lot of sense because RRSIG queries don't have the same interop concerns as
ANY queries. However, in an attack like the ones we had last weekend where
the queries arrived at our authoritative servers from lots of real
recursive servers, a refusal will cause retries and make the attack worse.

Would it be reasonable as an alternative to follow the refuse-any approach
and just return the RRSIG(s) for one RRset? If so, I think this suggestion
should be included in the draft.

Tony.
--

-- 
f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
Thames, Dover: Southwest 5 to 7, occasionally gale 8 later, perhaps severe
gale 9 later. Moderate, occasionally rough later. Occasional rain or drizzle.
Moderate or good, occasionally poor.

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

(Continue reading)

Olafur Gudmundsson | 5 Feb 00:31 2016

SecDIr review: draft-holmberg-dispatch-pani-abnf-02

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The document is short and to the point, it has no security issues and is ready for publication.

Olafur

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Mukund Sivaraman | 4 Feb 13:46 2016

Re: Cache utilization review and suggestion for EDNS client-subnet

Hi Yuri

On Thu, Feb 04, 2016 at 12:57:52PM +0100, Yuri Schaeffer wrote:
> Hi Mukund,
> 
> > The draft doesn't state that the answer is for the SOURCE
> > PREFIX-LENGTH when SCOPE > SOURCE. At all other times, the answer
> > is meant to be cached at the SCOPE PREFIX-LENGTH.
> 
> I indeed use SCOPE to determine where the answer would fit in the tree
> in my cache. But that doesn't mean I discard SOURCE. I still need
> SOURCE to determine if this cache entry is applicable to the next
> query. There's no contradiction here.

I don't follow. Are you saying you are saving the SOURCE PREFIX-LENGTH
from the original query (responsible for the cache entry) alongside the
cache entry? If so, I don't follow why this is required. Can you
explain?

Or do you mean the use of SOURCE PREFIX-LENGTH from a subsequent query
when looking into the cache?

		Mukund
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
RFC Errata System | 2 Feb 16:21 2016

[Technical Errata Reported] RFC7719 (4611)

The following errata report has been submitted for RFC7719,
"DNS Terminology".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7719&eid=4611

--------------------------------------
Type: Technical
Reported by: Nikolai Malykh <nmalykh <at> gmail.com>

Section: 2

Original Text
-------------
CNAME:  "It is traditional to refer to the owner of a CNAME record as
   'a CNAME'.  This is unfortunate, as 'CNAME' is an abbreviation of
   'canonical name', and the owner of a CNAME record is most certainly
   not a canonical name."  (Quoted from [RFC2181], Section 10.1.1)

Corrected Text
--------------
CNAME:  "It is traditional to refer to the label of a CNAME record as
   'a CNAME'.  This is unfortunate, as 'CNAME' is an abbreviation of
   'canonical name', and the label of a CNAME record is an alias, not
   a canonical name."  (Quoted from [RFC2181], Section 10.1.1)

Notes
-----
Incorrect quote from RFC 2181.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7719 (draft-ietf-dnsop-dns-terminology-05)
--------------------------------------
Title               : DNS Terminology
Publication Date    : December 2015
Author(s)           : P. Hoffman, A. Sullivan, K. Fujiwara
Category            : INFORMATIONAL
Source              : Domain Name System Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

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

Ted Hardie | 28 Jan 18:23 2016
Picon

ARCING BoF and mailing list

Howdy,

Andrew Sullivan, Suzanne Woolf and I have put a request in for a BoF at IETF 95 (arcing) that is trying to take a slightly different squint at how to manage alternative resolution contexts like that of mDNS, .onion, or similar.  We're trying to look beyond recent issues about RFC 6761 and special use name
​ to see if there are different architectural approaches to the general problem.

There's a stab at a problem statement draft available, building off of work that's already been done  here in DNSOP and other places.  There is also a mailing list set up for early discussion (arcing <at> ietf.org), and we'd appreciate anyone interested in the topic joining the discussion there.

Apologies if you get multiple copies; it must mean we *really* want you to join.

thanks,

Ted, Andrew, Suzanne 
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Giovane C. M. Moura | 28 Jan 12:29 2016
Picon

ENTRADA goes open source (.nl Hadoop platform)

*************************************************************
ENTRADA GOES OPEN SOURCE
http://entrada.sidnlabs.nl/
*************************************************************

SIDN Labs [1] is happy to announce that we are releasing our ENTRADA
platform as an open source project [2]. ENTRADA is a Hadoop-based
platform designed to ingest and quickly analyze large amounts of network
data. More technically, it is a high-performance data streaming
warehouse (DSW).

Please refer to our research paper [3] for a performance evaluation and
more details.

WHO CAN USE IT:

* Internet measurement researchers who are in need of a
high-performance analytics platform
* Domain name registries and other network operators interested in
developing DNS big data applications (e.g:[4])

MAIN FEATURES:

* Performance: analyze the Parquet equivalent of 50 TB of pcap data
in under 3.5 minutes, with a small 6-node cluster (4 data processing
nodes).
* Interface: benefit from easy SQL statements to analyze your data
* Scalable: add more nodes for faster processing and more storage
* Built-in support for DNS (and TCP/UDP/IP fields too) and ICMP
network data; other protocols may be added too.

DEPLOYMENT:

We have been using ENTRADA at SIDN Labs for the past 1.5 years. It
currently runs on a relatively small 6 node cluster (with 4 data-nodes),
which store DNS traffic from the .nl authoritative servers. In total,
ENTRADA has more than 100 billion queries and responses stored, and 400
million are added on a daily basis. It can also be deployed on a cloud
environment.

We also make available open aggregated datasets at [5].

ABOUT SIDN AND SIDN LABS

SIDN [6] manages .nl, the country code TLD of the Netherlands.
SIDN Labs [1] is SIDN's R&D team, which develops
and evaluates new technologies and systems to improve both stability and
security of .nl zone.

References:

[1] https://www.sidnlabs.nl/
[2] http://entrada.sidnlabs.nl/
[3] https://www.sidnlabs.nl/sidn-noms2016.pdf
[4] http://iepg.org/2015-11-01-ietf94/iepg-moura.pdf
[5] http://stats.sidnlabs.nl
[6] https://sidn.nl

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

Mark Andrews | 22 Jan 12:19 2016

EDNS COOKIE now supported by some TLD servers


See https://ednscomp.isc.org/compliance/ts/tld.optwhat.html

--

-- 
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
https://www.ietf.org/mailman/listinfo/dnsop

Paul Hoffman | 22 Jan 04:22 2016

DNSSEC in draft-ietf-dnsop-resolver-priming

In Warren's review of the draft, he says:

I think that resolvers SHOULD send DO, and should try validate (if it 
gets signed responses). This is pointless at the moment, but if / when 
we end up with signed root-servers.net (or foo.bar) it would be nice if 
the right things were already being done.

This seems like a good start for a discussion.

--Paul Hoffman

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

Paul Hoffman | 22 Jan 04:07 2016

Setting of the RD bit in queries in draft-ietf-dnsop-resolver-priming-06.txt

This is the summary of the thread about the following sentence in the 
section on priming queries:

The RD bit MAY be set to 0 or 1, although the meaning of it being set to 
1 is
undefined for priming queries.

There were four replies with what seems like four different takes on it. 
Can others in the WG weigh in so we might get consensus?

--Paul Hoffman

On 15 Jan 2016, at 2:50, Stephane Bortzmeyer wrote:

> On Thu, Jan 14, 2016 at 11:09:36AM -0800,
> Paul Hoffman <paul.hoffman <at> vpnc.org> wrote
> a message of 34 lines which said:
>
>> Setting the RD bit to 1 could result in non-authoritative answers.
>
> Today, all root name servers are not recursive. It seems good
> practice, even if I'm not sure it's formally written somewhere (I do
> not find it in RFC 7720).
>
>> If the response to a priming query is non-authoritative, should the
>> resolver reject it and try more queries?
>
> I would say yes, since it is supposed to be sent to authoritative
> servers.
>
> If a name server is deprecated and replaced by a resolver, not
> authoritative for the root, I tend to think that its response cannot
> be trusted.

On 15 Jan 2016, at 5:03, Tony Finch wrote:

> Paul Hoffman <paul.hoffman <at> vpnc.org> wrote:
>>
>> If the response to a priming query is non-authoritative, should the
>> resolver reject it and try more queries? Or is it OK for a priming
>> response to be non-authoritative?
>
> If you are unlucky enough to be on a network that intercepts DNS 
> queries
> and diverts them to a recursive server, you are likely to get RA=1 
> AA=0
> answers to priming queries. Your resolver ought to soldier on as best 
> it
> can in this situation.

On 15 Jan 2016, at 5:59, Stephane Bortzmeyer wrote:

> On Fri, Jan 15, 2016 at 01:03:41PM +0000,
> Tony Finch <dot <at> dotat.at> wrote
> a message of 22 lines which said:
>
>> If you are unlucky enough to be on a network that intercepts DNS
>> queries and diverts them to a recursive server, you are likely to
>> get RA=1 AA=0 answers to priming queries. Your resolver ought to
>> soldier on as best it can in this situation.
>
> If the resolver validates with DNSSEC, it may go on in such a case. If
> it doesn't, I'm tempted to say that it should give in and tell the
> sysadmin that it cannot do its job properly and safely.
>
> At the very minimum, such problem should be escalated to the sysadmin.

On 15 Jan 2016, at 9:52, Darcy Kevin (FCA) wrote:

> It's not really a "normal" query, in the sense that it's not coming 
> from a stub resolver, typically, and the initiator wouldn't normally 
> assume that recursion is required to fetch the answer.
>
> So, in the typical case I'd expect RD=0.
>
> Not sure that the "although" verbiage below really adds any value, 
> though. If you've already declared that something is a "MAY", what's 
> the practical effect of then saying that its meaning is "undefined"? 
> Either it's allowable per the standard or it's not.
>

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


Gmane