[DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[Wiley, Glen]

I have seen the ISC EDNS compliance report (beautiful thing really), but it 
loks as though the focus is really on the name servers and name server 
operators.  Has a recent study been done to examine whether client side/ISP 
firewalls are interfering with EDNS?
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

[Wiley, Glen]

On 11/11/15, 5:01 PM, "Tony Finch"  wrote:


>Paul Vixie  wrote:
>> On Wednesday, November 11, 2015 04:41:27 PM Tony Finch wrote:
>> > Paul Vixie  wrote:
>> >
>> > > yes, that's flooding the channel. you're allowed one work-stream per
>> > > query, in order that timeouts and other loss are only felt as
>> > > backpressure by those apps who caused them.
>> >
>> > Where is that specified?
>>
>> it's written in tire tracks down my backside.
>
>Sounds painful :-)
>
>> > > i have no objection to multiple parallel outstanding upstream
>>queries
>> > > over a TCP stream.
>> >
>> > Why is TCP special?
>>
>> because it has per-flow congestion control.
>
>Which is perfectly fair, but there is a big difference between saying that
>high-volume DNS clients need congestion control, and saying that they must
>have at most one query outstanding at any time. If you say TCP is OK, you
>are implicitly saying that it's OK to have a window size greater than one
>packet. And that implies there are engineering questions about how that
>window size should be managed.
>
>And this implies it is unreasonable to forbid concurrent queries over UDP.
>(And it would be futile to break running code in every browser.)
>
>The upshot of all this is that how you use concurrent queries to improve
>performance without breaking things is a matter of engineering and
>implementation quality.
>
>And since (as far as I know) no-one has done that engineering, I think it
>is premature to try to deploy a protocol fix for a hypothetical problem.
>(adns's concurrency control is quite simplistic, for example.)
>
>What edns-chain-query says to DNSSEC users is, DNSSEC still isn't finished
>or ready for deployment on edge devices, and you have to wait another 5 or
>10 years for another protocol change to be deployed before you can get
>decent performance.
>
>This is wrong!

Another way to read the message of edns-chain-query is: DNSSEC has many use
cases and operation implications.  If you would like an alternate path
that may reduce latency under some conditions but not compromise the
security of the query/response here is one way to tackle it.

>
>In order to make edns-chain-query work, validators will need to be
>refactored to decouple the validation logic from the network chatter. At
>the moment there aren't APIs that let you present a chain of DNSKEY and DS
>RRsets to a validator and get an assessment. The current model is
>"validate this RRset please" and then wait for a dozen RTTs.

At this stage there aren¹t widely deployed validating stub resolvers.
This is
true of new technology in general - I don¹t think the bar for improvements
should be ³has this already been implemented?²

There are some budding ideas and implementations out there, but any
support 
for DNSSEC on the client/host currently requires changes to the host APIs.

>
>But once you have a validator API that works with edns-chain-query you
>also have a validator API that works with concurrent queries on the
>existing DNS.
>
>So really we should be trying to make that work first, since it has a much
>more compelling deployment story.
>
>And if well-informed engineering makes it clear that the existing DNS
>can't reliably handle 6 ish concurrent queries, then maybe it's time to
>think about upgrading everything with a new protocol feature.
>
>Tony.
>-- 
>f.anthony.n.finch    http://dotat.at/
>Northwest Fitzroy: Southwesterly 5 to 7, occasionally gale 8. Rough or
>very
>rough, becoming very rough or high. Occasional rain. Good, occasionally
>poor.
>
>___
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] terminology, additional language for bailiwick

[Wiley, Glen]

The draft-ietf-dnsop-dns-terminology draft will be helpful in normalizing
language in documentation and
for folks new to the industry, I like where it is heading.  I¹d like to
recommend adding a few sentences to in the paragraphs on bailiwick.  I
think the original text is pretty close but the additions below would make
it more helpful to a less familiar reader as bailiwick is particularly
confusing to some folks (as was noted in earlier exchanges on this list).

The current text reads:

In-bailiwick:

  (a) An adjective to describe a name server whose name is either
  subordinate to or (rarely) the same as the zone origin.  In-
  bailiwick name servers require glue in their parent zone.

  (b) Data for which the server is either authoritative, or else
  authoritative for an ancestor of the owner name.  This sense of
  the term normally is used when discussing the relevancy of glue
  records in a response.  For example, the server for the parent
  zone example.com might reply with glue records for
  ns.child.example.com.  Because the child.example.com zone is a
  descendant of the example.com zone, the glue records are in-
  bailiwick.

   Out-of-bailiwick:  The antonym of in-bailiwick.




Id like to suggest something like this:

(a) An adjective to describe a name server whose name is either
subordinate to or (rarely) the same as the zone origin. In-
bailiwick name servers require glue in their parent zone. For
example if the com. name server refers a query for a.example.com
to ns.example.com the resolver would consider ns.example.com
in-bailiwick.
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

http://vbsdcon.com

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy?

[Wiley, Glen]

Dan,

This looks as though it will be a really interesting exercise.  I will be there 
in spirit (and in corporeal form Sunday afternoon).
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

http://vbsdcon.com

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

From: Dan York y...@isoc.orgmailto:y...@isoc.org
Date: Wednesday, July 1, 2015 at 7:43 AM
To: dnsop dnsop@ietf.orgmailto:dnsop@ietf.org
Subject: [DNSOP] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or 
DNS Privacy?

DNSOP participants,

Will you be in Prague on the weekend before IETF 93? (Or could you get there?)  
A number of us will be involved with the hackathon happening on Saturday and 
Sunday:

https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon

Our intent is to work on some tools/services related to DANE, DNSSEC and/or DNS 
privacy - either adding support to existing tools or projects, or developing 
something new that is useful in some way (and is not a duplicate of something 
else).   We don't have specific projects lined up yet  (we need to meet and 
decide what we're going to do)...  but any suggestions are certainly welcome.

If you'd like to join for either one or both days, the link to sign up is on 
that hackathon page.   Here's what we wrote as an abstract:

  *
DANE / DNS Privacy / DNSSEC
 *
Contribute to access of end-systems to new developments in DNS
 *
Protocols: DANE support for webmail, DNS-over-TLS (application uses), 
DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for 
EDNS client-subnet, getdns language bindings, etc.
 *
Tools: portable tool for creating and adding DANE RR’s to zones, changes to 
existing tools to support new crypto algorithms, etc.
 *
Measurement: New tools or sites for measuring DNSSEC or DANE deployment
 *
Available open source libraries: https://github.com/verisign/smaug, 
https://github.com/getdnsapi
 *
Available environment, support, and diagnostic tools: https://dnssec-tools.org, 
https://www.opendnssec.org
 *
Champions
*
Dan York, Internet Society y...@isoc.orgmailto:y...@isoc.org
*
Allison Mankin, Verisign Labs aman...@verisign.commailto:aman...@verisign.com
*
Willem Toorop, NLnet Labs
*
Sara Dickinson, Sinodun
*
Others, TBA

Anyone is welcome to join with us.  The current list of participants is here:  
https://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login=%0Ahttps://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login=
  (you can see that some people have listed that they will join in for 
DNS-related topics...)

See (some of) you in Prague,
Dan

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.orgmailto:y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/http://www.internetsociety.org/deploy360/



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC AD bit handling in stub-resolvers

[Wiley, Glen]

Petr,

Have you taken a look at the getdns API specification that Paul Hoffman
put together at http://www.vpnc.org/getdns-api/ ?

This addresses many of your points for both stub resolvers and a recursive
resolver that would run on a platform local to the applications.
-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.




On 2/26/14 10:44 AM, Petr Spacek pspa...@redhat.com wrote:

Greetings,

I'm Petr Spacek from Red Hat's Identity Management group. We plan to
extend 
support for DNSSEC (including DANE and others) in open-source software
and we 
would like to discuss the right implementation approach with you.

We can see two very basic approaches:
A) Do DNSSEC response validation in each application.
B) Let recursive resolver do the validation and use AD bit in the
application.

We consider the first approach (i.e. each application doing response
validation) too heavy-weight and hard to administer for various reasons:
- Response validation is sensitive operation and application programmers
should not do it themselves.
- A variant where every application calls validation library is still not
optimal. Experience with crypto libraries shows that there are many
opportunities to use a library incorrectly (in a way which works but is
not 
secure).
- This approach has potential to create administrative nightmare if each
application decides to maintain own set of trust anchors etc. We can see
results of such approach in PKI world ...


We believe that better approach is to centralize validation in local
system-wide recursive resolver and use AD bit for signaling that data are
trustworthy to applications. An application should use stub-resolver to
talk 
to local recursive resolver and use received AD bit to decide e.g. if it
is 
possible to trust TLSA records or not.

Unfortunately, there are use cases where neither a locally running
validating 
resolver nor a trusted path to a remote resolver are available and
deployment 
of such is unacceptable.

It seems that existing stub-resolvers unconditionally trust recursive
resolvers and just forward the AD bit back and forth. This behavior is
okay 
only if no application relays on the AD bit. In other words, supporting
DANE 
with current stub-resolvers practically requires to add a configuration
option 
'recursive resolver is un/trusted' to each and every DANE-enabled
application 
and library. (This is exactly what OpenSSH client does. An additional
problem 
is that this value has to be maintained as network configuration changes
over 
time.)


We would like to make DNSSEC implementation in applications as simple and
secure as possible. That is a reason why we are looking for a solution
for a 
case where AD bit can't be trusted because validating resolver is not
available for whatever reason. It would allow applications to use AD bit
without explicit configuration per-application if we solve this case
somehow.

Is there any 'standard' way to handle described situation?


We have the following proposal (some people say it is controversial):
- Extend stub-resolvers with a new call for resolver initialization: In
case 
of ldns it would be something like: ldns_resolver_new_frm_file_trusted()
or 
for glibc res_init_trusted().
- The new call will initialize library as usual + read some system-wide
configuration (it can be whatever, imagine for example a new file
/etc/resolv.trusted).
- Client applications will use the same API (except the initialization)
to do 
DNS queries.
- When a DNS answer is received from network the stub-resolver will
consult 
configuration read from /etc/resolv.trusted:
-- If the particular recursive resolver is listed as trusted - pass AD
bit to 
the application.
-- *Otherwise: Clear AD bit and pass the answer with AD=0 to the
application.*

This allows an administrator to configure system-wide policy. In case
with 
locally running validating resolver or e.g. IPSec tunnel to trusted
resolver 
admin can declare it as trusted and nothing changes. However, this
mechanism 
allows the system to be safe even in configurations *without* validating
resolver. No explicit configuration in application is need, just one
system-wide setting.

It could seem like a minor improvement or a hack, but it allows
applications 
to trust the AD bit unconditionally and as a result it significantly
simplifies DNSSEC implementation and configuration on client machines. We
hope 
that this simple approach will allow us to implement and deploy DANE and
similar technologies widely.

This proposal can be seen as temporary solution before secure transport
mechanisms like IPSec or CGA-TSIG are widely available and used. The main
advantage is that it is easy to implement and it doesn't require any new
technology so we can use it in applications today.

We would like to hear your opinions and recommendations for this area.

Thank you for your time.

-- 
Petr Spacek
Software Engineer
Red Hat

___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] beta release of getdns stub resolver

[Wiley, Glen]

Thanks Rick.

Paul's original commission to write the spec was I think largely motivated by 
the need for an API that non-DNS expert application developers could live with. 
 I am hoping that by building a fully open (BSD licensed) implementation that 
is willing to accept contributions from the community we will end up with 
something that will move DNSSEC adoption to the next level.

--
Glen Wiley
KK4SFV
Sr. Engineer
The Hive, Verisign, Inc.

From: Richard Lamb richard.l...@icann.orgmailto:richard.l...@icann.org
Date: Wednesday, February 26, 2014 2:02 PM
To: Wiley, Glen gwi...@verisign.commailto:gwi...@verisign.com, 
dnsop@ietf.orgmailto:dnsop@ietf.org dnsop@ietf.orgmailto:dnsop@ietf.org
Subject: RE: beta release of getdns stub resolver

Thank you guys!

This is exactly the kind of leadership the rest of the IT industry needs to 
help take DNSSEC to the next level.  Many of us were just going to hack up some 
code for Windows out of frustration but were stymied by what sort of interface 
would be the most attractive to developers (and therefore widespread DNSSEC 
adoption).  So we were waiting for someone else to take the first step.  You 
did it.

Thanks !!
–Rick Lamb (with entrepreneur hat on)



From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Wiley, Glen
Sent: Wednesday, February 26, 2014 10:47 AM
To: dnsop@ietf.orgmailto:dnsop@ietf.org
Subject: [DNSOP] beta release of getdns stub resolver

Verisign and NLnet Labs are pleased to announce the first beta release (0.1.0) 
of an open source implementation of the getdns API specification.  The 
project's home page is at http://getdnsapi.nethttp://getdnsapi.net/.

getdns is a modern asynchronous DNS API. It implements DNS entry points from a 
design developed and vetted by application developers, in the specification at 
http://www.vpnc.org/getdns-api/ edited by Paul Hoffman. With the development of 
this API, we intend to offer application developers a modernized and flexible 
way to access DNS security (DNSSEC) and other powerful new DNS features; a 
particular hope is to inspire application developers towards innovative 
security solutions in their applications.

We invite everyone to take a look at the project and to provide feedback to us 
and even contribute back to the project!  We expect to have successive releases 
over the next few months that move us toward a more complete implementation and 
includes ports to even more platforms.

Signed…the getdns core team:
Craig Despeaux, Verisign, Inc.
Neel Goyal, Verisign, Inc.
Olaf Kolkman, NLnet Labs
Allison Mankin, Verisign Labs.
Melinda Shore, No Mountain Software LLC
Willem Toorop, NLnet Labs
Wouter Wijngaards, NLnet Labs
Glen Wiley, Verisign, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS privacy draft

[Wiley, Glen]

On 12/3/13 5:20 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:


On Mon, Dec 02, 2013 at 01:13:26PM -0500,
 Warren Kumari war...@kumari.net wrote
 a message of 35 lines which said:

  OK. And do note chaff may be a by-product of
  draft-wkumari-dnsop-hammer.
 
 Um, please explain.
 
 Hammer (and the various similar, actually implemented things) simply
 trigger lookups a few seconds before the TTL would naturally expire
 *in response to an incoming query*.

OK, I was too fast, sorry. Hammer itself does not scramble the stream
of requests. So, I withdraw the reference to Hammer.

Still, sending gratuitous queries, without an incoming query and
without waiting for the expiration, may be a good strategy for a
resolver to make traffic analysis more difficult for the eavesdropper
(or for the authoritative name servers).

I have read and support this draft with a few exceptions:

Large scale authoritative name servers (such as our COM/NET footprint)
already sort through an enormous stream of query data so while the chaff
might sound nifty I can't imagine it having a meaningful effect on the
ability for authoritative servers to analyze traffic until it reaches DOS
volumes.  Even for smaller operators this will certainly force changes to
infrastructure but I question whether it will result in reduced ability to
perform traffic analysis.

The other concern that I have is the idea of recursive resolvers holding
long lived sessions open with the authoritative servers.  This bears
closer analysis but my experience with COM/NET makes me nervous about that
idea.  I'd like to hear how other authoritative name server operators feel
about the implications of long lived TCP connections on their name servers.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop