Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

[Mark Andrews]

> On 20 Mar 2018, at 3:10 am, Vladimír Čunát  wrote:
> 
> On 03/18/2018 09:44 PM, Petr Špaček wrote:
>> The current text in section 5 is written with an assumption that query
>> with +CD bit cannot result in "Secure" status and thus cannot trigger
>> sentinel processing, but this depends on implementation.
> 
> I just want to note that this situation of answering +cd queries by
> validated cached RRs isn't very implementation-specific.  One way to
> come to this: it seems generally desirable to have aggressive caching
> (rfc8198) on forwarders, due to serving as a cache shared by multiple
> resolvers, and validating resolvers tend to use +cd to query the
> forwarders (rfc4035#section-3.2.2).

You can’t assume whether CD will be 1 or 0 when the client is validating.
Both types of queries are useful.  The mentioned section just fails to
discuss the CD=0 case.

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

[Dave Crocker]

Folks,

I'll limit what should be an extensive and elaborate apology to just 
this: I'm sorry for the year of inactivity.


The -03 version should provide some useful substance of progress.

I've gone over last summer's comments and the -03 version should reflect 
what the wg agreed to.  Basically, it has been significantly 
streamlined, essentially to reflect a clean-sheet model of the world. 
That is, it doesn't deal with the ugliness that SRV, et al, created.  It 
merely establishes the two registries we need, long term, and populates 
them.  This document should have continuing utility.


-03 defines two registries, 'global' and 'second-level'.  I'm suspicious 
of how short the global one is, though it does make sense.


As noted in the document, absent major concerns with the substance of 
the document, please send me or the list s/old/new/ types of change 
suggestions, and if the change is for a reference, I'd love the 
suggestion to be  xml...



A second document will attempt to fix up the uglinesses in some existing 
documents, to get them to align with a world that has these registries. 
It should be viewed as a transitional document, though we all know how 
glacial 'transitions' are in the Internet...


Deciding how to pursue that reasonably has been the effort.  The changes 
this 'fixes' document defines will be to documentation, but not to 
existing operation.  Existing uses in the field will be preserved.



Here's the approach I'm taking:


1. Simple underscore usage

   For many/most specifications that use underscore naming, the text 
merely says to use it.  They are straightforward.


   These specifications need to be listed in this document, explicitly, 
so that later updates to them will know to deal with the revisions 
called for by this document.


   But this document doesn't really need s/old/new kinds of precise 
detail for them. Rather than provide precise language for changing each 
of these, I propose to provide some generic text, and generic IANA 
Considerations.  This will permit this Fixes document to be cited as 
Updating those RFCs.



2. SRV and URI

   These need more detailed text, very much in the s/old/new style.

   The current text in them does a use-by-reference of existing tables 
defined for other purposes.  The Update text will, instead, specify a 
requirement for adding entries in the Global or Common Second-Level 
registries.



d/


 Forwarded Message 

Name:   draft-ietf-dnsop-attrleaf
Revision:   03
Title:  DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves
Document date:  2018-03-19
Group:  dnsop
Pages:  14
URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-03.txt

[internet-drafts]

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 WG of the IETF.

Title   : DNS Scoped Data Through '_Underscore' Naming of 
Attribute Leaves
Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-03.txt
Pages   : 14
Date: 2018-03-19

Abstract:
   Formally, any DNS resource record may occur for any domain name.
   However some services have defined an operational convention that
   applies to DNS leaf nodes that are under a DNS branch that has one or
   more reserved node names that begin with an underscore.  The
   underscore naming construct defines a semantic scope for DNS records
   that are associated with the parent domain, above the underscored
   branch.  This specification explores the nature of this DNS usage and
   defines the "DNS Global Underscore Scoped Entry Registry" with IANA.
   The purpose of the Underscore registry is to avoid collisions
   resulting from the use of the same underscore-based name, for
   different services.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] Terminology question: split DNS

[Dick Franks]

On 19 March 2018 at 21:30, Steve Crocker  wrote:

> I haven't been following the current thread but I have encountered this
> topic before and I have thought about the implications for DNSSEC.
>
> The terminology of "split DNS" -- and equivalently "split horizon DNS" --
> is, in my opinion, a bit limited.  It's not too hard to imagine further
> carve outs.  For me, the general case is at every point in the network,
> there is an external world and an internal world.  Let's say I am in charge
> of the systems that support a department within a division of a very large
> company.  I could imagine a department DNS that resolves names within the
> department but forwards other queries to the division DNS resolvers.
>

The simple distinction between "internal" and "external" does not begin to
describe the situation on the ground in the multi-national company that
used to employ me.

The only real "external" is the global internet.

Obviously, the local network, at subsidiary company, or in some cases
departmental level, is unambiguously "internal"

The operating subsidiaries were connected to a (corporate) national
network, and thence the international and global networks.

The DNS naming regime represented all these levels, including specifically,
a "view" of a subsidiary's (locally) maintained namespace visible from
other parts of the organisation.

The key ingredient that need to be captured in the description, is that
these are multiple "views" of a single database.  The view is a corporate
policy animal, and usually changes at a much lower rate than routine DNS
database maintenance.  This is a different proposition from selective
forwarding.


  They resolve names within the division and forward other queries to the
> company's resolvers.  The company's resolvers handle queries for names
> defined by the company and forward other queries to the outside.
>

To make this manageable, the corporate nameservers also need to delegate
parts of the namespace to the operating subsidiaries.

The concept of "horizon" seems (at least to me) to imply some limit beyond
which there is no visibility.

IMHO, the neutral concept of "view" describes the situation well enough to
be useful.


If we're going to tackle this problem, let's do it cleanly and completely.
>
> Steve
>
>
> On Mon, Mar 19, 2018 at 5:14 PM, Paul Wouters  wrote:
>
>> On Mon, 19 Mar 2018, John Heidemann wrote:
>>
>> +1 on "split-horizon dns" as the term, over "split dns" and some other
>>> neologism, on the basis of running code and existing documentation and
>>> existing wide use.
>>>
>>
>> I and google disagree:
>>
>> "split dns":  72900 hits
>> "split horizon dns": 5640 hits
>>
>>
>> If the document is about explaining terminology, it must explain "split
>> dns" and can say another term for it is "split horizon dns", but not the
>> other way around.
>>
>> I personally don't hear (or use) "split horizon dns"
>>
>> Paul
>>
>>
>> ___
>> 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Robert Edmonds]

Paul Wouters wrote:
> On Mon, 19 Mar 2018, Robert Edmonds wrote:
> 
> > Viktor Dukhovni wrote:
> > > The idea is to log the DNSKEY RRs observed at each zone apex.
> > > Without the proposed flag, one would also have to log denial of
> > > existence which would make the logs much too large.
> > 
> > Can you expand on what you mean by "much too large"? There are already
> > existing large scale passive DNS systems that log every RRset that they
> > observe, and on relatively modest amounts of hardware. Is transparency
> > for DNSSEC really all that less tractable than the "log every RRset"
> > problem?
> 
> Do these large scale passive DNS systems then host the data for (m)any
> clients to fully download?

If those "(m)any clients" were interested in being customers of the
operator of the large scale passive DNS system, then yeah.

https://www.farsightsecurity.com/faq/#q13

> There are also privacy aspects. if you need to audit/log every query,
> you are uploading more personal identifiable information. Combined with
> TTL=0 or really short RRSIG times, these can become trackers. DNSKEY and
> DS records don't come with such short TTLs (or if they would it could
> itself be seen as a sign of malicious behavior) so there is much less
> of a one to one relationship between those queriers and answers.

Who is uploading what to whom in this scenario?

Suppose there were something like
https://www.internic.net/domain/root.zone, but instead of being a daily
point in time snapshot of the root zone in master file format, it were a
log that captured each RRset and a publish date, going back for some
small window of time, and it were (ugh) PGP signed so that you know it's
authentic. Would that be enough for independent auditors to construct
and publish their own append-only Merkle tree logs or whatever, so that
folks who want to "trust, but verify" the DNSSEC responses from the root
could do so without having to upload their query logs to anyone? If so,
doesn't this generalize to TLDs as well?

That is, I guess I'm saying if you need cooperation from the zone
publisher anyway, why not just get them to publish what you need, out of
band? (Sure, it doesn't work for the TLDs that don't want to publish
their zones.)

-- 
Robert Edmonds

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

Re: [DNSOP] Terminology question: split DNS

[Paul Vixie]

Steve Crocker wrote:

I haven't been following the current thread but I have encountered this
topic before and I have thought about the implications for DNSSEC.

The terminology of "split DNS" -- and equivalently "split horizon DNS"
-- is, in my opinion, a bit limited.  It's not too hard to imagine
further carve outs.  For me, the general case is at every point in the
network, there is an external world and an internal world.  ...


i think two things. probably more, but two that occur upon the above.

first, that general case is not described in detail in the documentation 
of the Internet System. a brief overview is given in RFC 1918 (BCP 5), 
in the last paragraph of section 5, but more is needed.


second, more specific cases exist, where configuration cognizance is 
given to *several* external worlds AND *several* internal worlds. 
bind9's "view" feature accounts for this, but the resulting capabilities 
are very hard to describe in a general way.


see also: .

--
P Vixie

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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Paul Wouters]

On Mon, 19 Mar 2018, Stephane Bortzmeyer wrote:


I'm opposed to this idea.


Can you clarify whether you oppose to be a user of this new flag, or
whether you oppose of giving others the option of using this flag?


While the root and TLD zones are asumed to be almost exclusively
delegation-only zones,


This is unrelated. You mix two different things, the administrative
issue and the technical one (every subdomain in its own zone). gouv.fr
is administratively a delegation from .fr but is in the same zone.


The idea is that the current technology cannot tell this difference,
but we know at some point down the chain there (usually) is a real owner
change. This allows a zone to publish that information.

One of the side effects is that is there is no zone cut when traversal
a label, that to use this new flag, you have to turn this label change
into a real zone cut. I believe the setup of that is easy and that there
are no real operational impacts caused by this, but I'm happy to hear
from operators, especially TLDs, if there are any concerns with such
a conversion.


That's the DNS. It is a tree. Protecting childs against the parent is
a non-goal


If you can't not trust your friends, who can you not trust? :)

We also did not publish TLSA records in the zone in the old days. Now
we do so there is a clear (new) need to add a bit of protection for the
children against potentially malicious parents. It's completely an
opt-in option for the parent.

Rather then hearing "That's the DNS", I'm more interested in hearing
about whether TLDs would be willing to adopt this solution, and if not,
what actual operational (or organisational?) concerns they would have.


or otherwise we should move to some alternative to DNS


That is outside the scope of this proposed solution :)


The aim here is to counter the argument that the root key and TLD
keys are all powerful and under government control, and can therefor
never be trusted.


I've read the draft and still can understand nothing in this sentence.


I'm happy to talk in person this week if that helps. Otherwise if you
have specific questions, I can try to answer them here.


2) Allow the creation of DNSSEC transparency logs


May be mentioning draft-zhang-trans-ct-dnssec would be nice?


This document is not about ct-dnssec itself. It has as one of its goals,
to make some kind of ct-dnssec possible. But that will be pursued with
another document (and probably on the trans list)


 The DELEGATION_ONLY flag has a strong overlap in functionality with
 the Public Suffix List as both signal a formal split of authority
 between parent and child.


May be mentioning the defunct DBOUND working group would be a good
idea?


What specifically about DBOUND is worth mentioning in the document?

Paul

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

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

[Paul Vixie]

Matthew Pounsett wrote:



...


I would suggest that only NXDOMAIN and NOERROR+ANCOUNT=0 are negative
responses.   SERVFAIL, FORMERR, and REFUSED are error responses; you do
not know as a result of those responses whether the name/type tuple
queried about exists.


+1.

--
P Vixie

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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Paul Wouters]

On Mon, 19 Mar 2018, Robert Edmonds wrote:


Viktor Dukhovni wrote:

The idea is to log the DNSKEY RRs observed at each zone apex.
Without the proposed flag, one would also have to log denial of
existence which would make the logs much too large.


Can you expand on what you mean by "much too large"? There are already
existing large scale passive DNS systems that log every RRset that they
observe, and on relatively modest amounts of hardware. Is transparency
for DNSSEC really all that less tractable than the "log every RRset"
problem?


Do these large scale passive DNS systems then host the data for (m)any
clients to fully download?

There are also privacy aspects. if you need to audit/log every query,
you are uploading more personal identifiable information. Combined with
TTL=0 or really short RRSIG times, these can become trackers. DNSKEY and
DS records don't come with such short TTLs (or if they would it could
itself be seen as a sign of malicious behavior) so there is much less
of a one to one relationship between those queriers and answers.

Paul

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

Re: [DNSOP] Terminology question: split DNS

[Steve Crocker]

I haven't been following the current thread but I have encountered this
topic before and I have thought about the implications for DNSSEC.

The terminology of "split DNS" -- and equivalently "split horizon DNS" --
is, in my opinion, a bit limited.  It's not too hard to imagine further
carve outs.  For me, the general case is at every point in the network,
there is an external world and an internal world.  Let's say I am in charge
of the systems that support a department within a division of a very large
company.  I could imagine a department DNS that resolves names within the
department but forwards other queries to the division DNS resolvers.  They
resolve names within the division and forward other queries to the
company's resolvers.  The company's resolvers handle queries for names
defined by the company and forward other queries to the outside.

If we're going to tackle this problem, let's do it cleanly and completely.

Steve


On Mon, Mar 19, 2018 at 5:14 PM, Paul Wouters  wrote:

> On Mon, 19 Mar 2018, John Heidemann wrote:
>
> +1 on "split-horizon dns" as the term, over "split dns" and some other
>> neologism, on the basis of running code and existing documentation and
>> existing wide use.
>>
>
> I and google disagree:
>
> "split dns":  72900 hits
> "split horizon dns": 5640 hits
>
>
> If the document is about explaining terminology, it must explain "split
> dns" and can say another term for it is "split horizon dns", but not the
> other way around.
>
> I personally don't hear (or use) "split horizon dns"
>
> Paul
>
>
> ___
> 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

Re: [DNSOP] Terminology question: split DNS

[Michael Sinatra]

On 3/19/18 11:14 AM, Jim Reid wrote:




On 19 Mar 2018, at 18:09, Artyom Gavrichenkov  wrote:

Another issue here is that, for some enterprises at least, there's no
single "internal network" anymore.


We don't need to enumerate every potential split DNS scenario (or how it's implemented). 
The original text says "there are many potential variants". That should be 
enough for this document. The simple example of one internal and one external net will do 
for illustrative purposes.


Rather than try for some physical demarcation like "firewall" or 
"network," why don't we simply say "organizationally-defined perimeter" 
or "perimeter defined by the organization," which leaves it vague enough 
to support the "many potential variants"?


E.g. in Paul H.'s original text

Instead of: "Where a corporate network serves up partly or completely 
different DNS inside and outside its firewall."


Use: "Where a corporate [enterprise?] network serves partly or 
completely different DNS based on a client's location inside or outside 
of a perimeter defined by that organization."


This also gives the enterprise organization both the authority (and 
onus) to define its perimeter in a reasonable logical way.


michael


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

Re: [DNSOP] Terminology question: split DNS

[Paul Wouters]

On Mon, 19 Mar 2018, John Heidemann wrote:


+1 on "split-horizon dns" as the term, over "split dns" and some other
neologism, on the basis of running code and existing documentation and
existing wide use.


I and google disagree:

"split dns":  72900 hits
"split horizon dns": 5640 hits


If the document is about explaining terminology, it must explain "split
dns" and can say another term for it is "split horizon dns", but not the
other way around.

I personally don't hear (or use) "split horizon dns"

Paul

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

Re: [DNSOP] Terminology question: split DNS

[John Heidemann]

On Mon, 19 Mar 2018 11:33:12 -0700, Paul Vixie wrote: 
>
>
>Ted Lemon wrote:
>> On Mar 19, 2018, at 6:10 PM, George Michaelson > > wrote:
>>> "A DNS resolver which looks at the client requesting address, and uses
>>
>> That's a different thing. There's a distinction between a resolver that
>> gives different answers, and a set of authoritative servers that give
>> different answers. I believe split horizon is referring to the latter,
>> not the former.
>
>i've done both and referred to both as "split-horizon dns".
>
>bind9 views does both.

+1 on "split-horizon dns" as the term, over "split dns" and some other
neologism, on the basis of running code and existing documentation and
existing wide use.

As another demonstration of wide use of this term, see
https://en.wikipedia.org/wiki/Split-horizon_DNS

It is not, to me, too great an overlap with split-horizon routing.

   -John Heidemann



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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Robert Edmonds]

Viktor Dukhovni wrote:
> The idea is to log the DNSKEY RRs observed at each zone apex.
> Without the proposed flag, one would also have to log denial of
> existence which would make the logs much too large.

Can you expand on what you mean by "much too large"? There are already
existing large scale passive DNS systems that log every RRset that they
observe, and on relatively modest amounts of hardware. Is transparency
for DNSSEC really all that less tractable than the "log every RRset"
problem?

-- 
Robert Edmonds

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

Re: [DNSOP] Terminology question: split DNS

[John Kristoff]

On Mon, 19 Mar 2018 19:26:42 +
"Darcy Kevin (FCA)"  wrote:

> How about just "disjoint DNS" or "non-synchronized DNS"? Or, to
> hijack the Perl motto, TMTOWTRI (There's More Than One Way To Resolve
> It :-)

Coming up with new names though is less than ideal.  The Microsoft
community has used split-brain, which might be an option, but might
not get a lot of support from this community (including me). RFC 7719
seems to prefer the term "view" for better or worse.  I kind like that.
Paul's comment doesn't convince me it shouldn't be apportioned for this.

John

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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Viktor Dukhovni]

On Mon, Mar 19, 2018 at 02:12:38PM -0400, Bob Harold wrote:

> > > We have just submitted a draft aimed at increasing the security of
> > > the DNSSEC with respect to the power that parental zones have over
> > > their children.
> >
> > I'm opposed to this idea.
>
> If the parent simply pointed the NS and DS records to a different version
> of the zone, that would accomplish the same effect, even with a
> 'delegation-only' flag, so the 'delegation-only' flag really does not solve
> the problem.

The 'delegation-only' flag does not *by itself* prevent parent
domains from answering authoritatively for their child domains,
but it could make "certificate-transparency" more tractable for
DNSSEC.

The idea is to log the DNSKEY RRs observed at each zone apex.
Without the proposed flag, one would also have to log denial of
existence which would make the logs much too large.  CT for DNSSEC
may be impractical anyway, but this flag could make it more realistic.

-- 
Viktor.

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

Re: [DNSOP] Terminology question: split DNS

[Darcy Kevin (FCA)]

The trouble with "split horizon" is that it is a term of inter-network routing 
of much older and more-established provenance, and thus to use it for DNS can 
be viewed as a usurpation, and ultimately, confusing. (I know Cricket had the 
same observation, circa 2000).

I occasionally use "schizophrenic DNS" when I want to disparage the practice, 
but I realize that is both a) inaccurate, from a clinical standpoint, and b) 
politically incorrect, in some circles.

How about just "disjoint DNS" or "non-synchronized DNS"? Or, to hijack the Perl 
motto, TMTOWTRI (There's More Than One Way To Resolve It :-)


- Kevin



-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Vixie
Sent: Monday, March 19, 2018 1:55 PM
To: Paul Hoffman 
Cc: dnsop 
Subject: Re: [DNSOP] Terminology question: split DNS



Paul Hoffman wrote:
> Some folks had reservations about the current definition of "split
> DNS": "Where a corporate network serves up partly or completely 
> different DNS inside and outside its firewall. There are many possible 
> variants on this; the basic point is that the correspondence between a 
> given FQDN (fully qualified domain name) and a given IPv4 address is 
> no longer universal and stable over long periods." (Quoted from  target="RFC2775"/>, Section 3.8)
>
> What would the WG like for this definition?

my only qualm is that A and  RR's are not the only things that are usually 
not the same when DNS is split in this way. MX, NS, SRV, and likely a dozen 
others, and DNSSEC signatures and keys, can also differ.

it should be called split-horizon DNS not split-DNS, to highlight the fact that 
it's the same zone name in an entirely separate DNS namespace.

--
P Vixie

___
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

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-bootstrap-validator-00.txt

[Matthew Pounsett]

On 19 March 2018 at 11:14, Joe Abley  wrote:

> Dave and I imagine this kind of thinking might be relevant and timely. Tim
> and Suz have kindly tolerated my increasingly frantic handwaving on this
> subject and have offered me some minutes in the dnsop meeting tomorrow,
> where I intend to suggest that a specification along these lines is
> necessary and that the working group should take this on.
>
> I won't be in the correct country top attend tomorrow's meeting, so I'll
state here that I think this is useful work.

I've done a quick perusal of the document and so far I've got one
question:   do you really mean to use the word "stub" in the definition of
"Validator"?  The way you're using Validator in the document, it doesn't
seem to me that it's actually limited to stub resolvers, and should include
all validating resolvers.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

[Matthew Pounsett]

On 19 March 2018 at 08:21, Matthijs Mekking  wrote:

> I and some others have been using the term 'Negative response' to indicate
> that the response does not contain any records in the Answer section.
> Current definition seems to imply that this is only the case if the RCODE
> is NXDOMAIN, NOERROR, SERVFAIL or if there was a timeout (unreachable). The
> definition I have been using includes responses with other RCODEs too, for
> example FORMERR or REFUSED.


> I wonder if this is just me and my bubble or if others also a slightly
> different meaning of 'Negative response' as it is defined now. If there are
> others, is it worth spending a line or two about this here?
>

I would suggest that only NXDOMAIN and NOERROR+ANCOUNT=0 are negative
responses.   SERVFAIL, FORMERR, and REFUSED are error responses; you do not
know as a result of those responses whether the name/type tuple queried
about exists.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology question: split DNS

[George Michaelson]

The quality to me, which was there in abstract, is a port-53 bound
daemon, which uses the client IP network or /32 to specify how it
answers.

Server, Resolver, these are distinct classes. I felt split-horizon was
the moment of decision logic from "who asked"

If anyone has actually bound it to "which interface did I get the
question on" thats subtly different, and more side-like.

-G

On Mon, Mar 19, 2018 at 6:33 PM, Paul Vixie  wrote:
>
>
> Ted Lemon wrote:
>>
>> On Mar 19, 2018, at 6:10 PM, George Michaelson > > wrote:
>>>
>>> "A DNS resolver which looks at the client requesting address, and uses
>>
>>
>> That's a different thing. There's a distinction between a resolver that
>> gives different answers, and a set of authoritative servers that give
>> different answers. I believe split horizon is referring to the latter,
>> not the former.
>
>
> i've done both and referred to both as "split-horizon dns".
>
> bind9 views does both.
>
> --
> P Vixie
>

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

Re: [DNSOP] Terminology question: split DNS

[Paul Vixie]

Ted Lemon wrote:

On Mar 19, 2018, at 6:10 PM, George Michaelson > wrote:

"A DNS resolver which looks at the client requesting address, and uses


That's a different thing. There's a distinction between a resolver that
gives different answers, and a set of authoritative servers that give
different answers. I believe split horizon is referring to the latter,
not the former.


i've done both and referred to both as "split-horizon dns".

bind9 views does both.

--
P Vixie

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

Re: [DNSOP] Terminology question: split DNS

[Robert Edmonds]

Artyom Gavrichenkov wrote:
> On Mon, Mar 19, 2018 at 5:47 PM, Paul Hoffman  wrote:
> > [..] the basic point is that the
> >correspondence between a given FQDN (fully qualified domain name) and a
> >given IPv4 address is no longer universal and stable over long periods."
> 
> IP v. being whatever, 4 or 6, there's a bunch of reasons there's
> virtually no correspondence between a given FQDN and a given IP
> address nowadays. E.g. CDNs.

There are many reasons that globally inconsistent DNS RRsets exist, e.g.
load balancers, CDNs, split [horizon] DNS, etc. I think split horizon is
a specific type of global inconsistency that doesn't necessarily
encompass the other types.

-- 
Robert Edmonds

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

Re: [DNSOP] Terminology question: split DNS

[Jim Reid]

> On 19 Mar 2018, at 18:09, Artyom Gavrichenkov  wrote:
> 
> Another issue here is that, for some enterprises at least, there's no
> single "internal network" anymore.

We don't need to enumerate every potential split DNS scenario (or how it's 
implemented). The original text says "there are many potential variants". That 
should be enough for this document. The simple example of one internal and one 
external net will do for illustrative purposes.

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

Re: [DNSOP] Terminology question: split DNS

[Paul Vixie]

Bob Harold wrote:

I think the key part is:
"different answers depending on the source of the query."

In practice this is done by using either different DNS servers (or
processes), or multiple "views" in a DNS configuration.
(Is "view" in BIND called something else in other software?)


bob halley and i put "views" into the BIND9 architecture because 
previously, people were running separate BIND8 server instances on 
different computers or on different listener-IP addresses, and we wanted 
to make this easier.


i suggest not mentioning views, because the concept predates them.

--
P Vixie

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

Re: [DNSOP] Terminology question: split DNS

[Artyom Gavrichenkov]

yeah, a simple example of such an exception is an anycast DNS
network which doesn't even look at the source IP address, but just has
completely different zones deployed in different points of presence.
When a PoP goes down, the same IP address will be directed to another
PoP and will start receiving data from a different "horizon" (there
might be a better metaphor for this concept).

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58


On Mon, Mar 19, 2018 at 6:09 PM, Artyom Gavrichenkov  wrote:
> On Mon, Mar 19, 2018 at 6:05 PM, Bob Harold  wrote:
>> In practice this is done by using either different DNS servers (or
>> processes), or multiple "views" in a DNS configuration.
>
> Another issue here is that, for some enterprises at least, there's no
> single "internal network" anymore. There are different network scopes
> (_sometimes_ nested) ranging from "formally internal but treated as
> almost external" to "air gap-separated DMZ", with different policies,
> including different DNS policies.
>
> My second thought (personally) is that there might be a reason to just
> bury the "split DNS" definition whatsoever and to just define a
> "multi-horizon DNS", where a "horizon" is defined by a company's
> policy and _usually_ depends on the source IP address of a query
> (there may be exceptions).
>
> | Artyom Gavrichenkov
> | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
> | mailto: xima...@gmail.com
> | fb: ximaera
> | telegram: xima_era
> | skype: xima_era
> | tel. no: +7 916 515 49 58

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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Bob Harold]

On Mon, Mar 19, 2018 at 12:34 PM, Stephane Bortzmeyer 
wrote:

> On Mon, Mar 19, 2018 at 08:22:03AM -0400,
>  Paul Wouters  wrote
>  a message of 57 lines which said:
>
> > We have just submitted a draft aimed at increasing the security of
> > the DNSSEC with respect to the power that parental zones have over
> > their children.
>
> I'm opposed to this idea.
>
> > While the root and TLD zones are asumed to be almost exclusively
> > delegation-only zones,
>
> This is unrelated. You mix two different things, the administrative
> issue and the technical one (every subdomain in its own zone). gouv.fr
> is administratively a delegation from .fr but is in the same zone.
>
> > the root zone operator (or any level higher in the hierarchy than
> > the target victim) could briefly remove the NS and DS records, and
> > create a "legitimate" DNS entry for "www.example.org"
>
>

If the parent simply pointed the NS and DS records to a different version
of the zone, that would accomplish the same effect, even with a
'delegation-only'
flag, so the 'delegation-only' flag really does not solve the problem.

-- 
Bob Harold





> That's the DNS. It is a tree. Protecting childs against the parent is
> a non-goal, or otherwise we should move to some alternative to DNS
> (Namecoin is cool).
>
> > The aim here is to counter the argument that the root key and TLD
> > keys are all powerful and under government control, and can therefor
> > never be trusted.
>
> I've read the draft and still can understand nothing in this sentence.
>
> > 2) Allow the creation of DNSSEC transparency logs
>
> May be mentioning draft-zhang-trans-ct-dnssec would be nice?
>
> >  The DELEGATION_ONLY flag has a strong overlap in functionality with
> >  the Public Suffix List as both signal a formal split of authority
> >  between parent and child.
>
> May be mentioning the defunct DBOUND working group would be a good
> idea?
>
> ___
> 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

Re: [DNSOP] Terminology question: split DNS

[George Michaelson]

"A DNS resolver which looks at the client requesting address, and uses
this to serve different versions of information about a zone based on
which client address or prefix requests it."

the concept of "side" is rather limited. split DNS can encompass more
than two sides can't it?

-George

On Mon, Mar 19, 2018 at 5:47 PM, Paul Hoffman  wrote:
> Some folks had reservations about the current definition of "split DNS":
>"Where a corporate network serves up partly or completely different DNS
> inside and outside
>its firewall. There are many possible variants on this; the basic point
> is that the
>correspondence between a given FQDN (fully qualified domain name) and a
> given IPv4 address
>is no longer universal and stable over long periods."
>(Quoted from , Section 3.8)
>
> What would the WG like for this definition?
>
> --Paul Hoffman
>
> ___
> 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

Re: [DNSOP] Terminology question: split DNS

[Artyom Gavrichenkov]

On Mon, Mar 19, 2018 at 6:05 PM, Bob Harold  wrote:
> In practice this is done by using either different DNS servers (or
> processes), or multiple "views" in a DNS configuration.

Another issue here is that, for some enterprises at least, there's no
single "internal network" anymore. There are different network scopes
(_sometimes_ nested) ranging from "formally internal but treated as
almost external" to "air gap-separated DMZ", with different policies,
including different DNS policies.

My second thought (personally) is that there might be a reason to just
bury the "split DNS" definition whatsoever and to just define a
"multi-horizon DNS", where a "horizon" is defined by a company's
policy and _usually_ depends on the source IP address of a query
(there may be exceptions).

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

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

Re: [DNSOP] Terminology question: split DNS

[Bob Harold]

On Mon, Mar 19, 2018 at 2:00 PM, Artyom Gavrichenkov 
wrote:

> On Mon, Mar 19, 2018 at 5:47 PM, Paul Hoffman 
> wrote:
> > [..] the basic point is that the
> >correspondence between a given FQDN (fully qualified domain name) and
> a
> >given IPv4 address is no longer universal and stable over long
> periods."
>
> IP v. being whatever, 4 or 6, there's a bunch of reasons there's
> virtually no correspondence between a given FQDN and a given IP
> address nowadays. E.g. CDNs.
>
>
>
I think the key part is:
   "different answers depending on the source of the query."

In practice this is done by using either different DNS servers (or
processes), or multiple "views" in a DNS configuration.
(Is "view" in BIND called something else in other software?)

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

Re: [DNSOP] Terminology question: split DNS

[Ted Lemon]

On Mar 19, 2018, at 5:47 PM, Paul Hoffman  wrote:
> Some folks had reservations about the current definition of "split DNS":
>   "Where a corporate network serves up partly or completely different DNS 
> inside and outside
>   its firewall. There are many possible variants on this; the basic point is 
> that the
>   correspondence between a given FQDN (fully qualified domain name) and a 
> given IPv4 address
>   is no longer universal and stable over long periods."
>   (Quoted from , Section 3.8)

Yeah, that's a bit iffy.   Homenet is another example of the same thing.   I 
would make it more generic, something like this:

  Where DNS servers that are authoritative for a particular set of domains
  provide partly or completely different answers in those domains depending
  on the source of the query.   The effect of this is that a domain name that
  is notionally globally unique nevertheless has different meanings for
  different network users.

This is probably not exactly right, but it gets rid of several problems with 
the old text.   I think the reference to "corporate" is bogus, and the 
reference to "IPv4" is also bogus, and also incomplete, since split horizon can 
affect any record, not just address records.

It could be usefully clarified by adding something along the lines of, "for 
example, RFC2775 mentions ..." and then include some or all of the old text.

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

Re: [DNSOP] Terminology question: split DNS

[Jim Reid]

> On 19 Mar 2018, at 17:47, Paul Hoffman  wrote:
> 
> Some folks had reservations about the current definition of "split DNS":
>   "Where a corporate network serves up partly or completely different DNS 
> inside and outside
>   its firewall. There are many possible variants on this; the basic point is 
> that the
>   correspondence between a given FQDN (fully qualified domain name) and a 
> given IPv4 address
>   is no longer universal and stable over long periods."
>   (Quoted from , Section 3.8)
> 
> What would the WG like for this definition?

The quoted definition seems wrong: the binding of a name to address isn't 
necessarily unstable in split DNS setups. And that's not the only game in town 
either: for instance MX and NS records.

How about the following:

Where a corporate network serves up partly or completely different DNS data 
inside and outside its network. There are many possible variants on this; the 
basic point is that the
correspondence between a given QNAME/QTYPE/CLASS tuple and the data for that 
tuple is no longer universal and can depend on where the query is made from or 
which DNS server(s) are queried.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology question: split DNS

[Paul Vixie]

Paul Hoffman wrote:

Some folks had reservations about the current definition of "split
DNS": "Where a corporate network serves up partly or completely
different DNS inside and outside its firewall. There are many
possible variants on this; the basic point is that the correspondence
between a given FQDN (fully qualified domain name) and a given IPv4
address is no longer universal and stable over long periods." (Quoted
from , Section 3.8)

What would the WG like for this definition?


my only qualm is that A and  RR's are not the only things that are 
usually not the same when DNS is split in this way. MX, NS, SRV, and 
likely a dozen others, and DNSSEC signatures and keys, can also differ.


it should be called split-horizon DNS not split-DNS, to highlight the 
fact that it's the same zone name in an entirely separate DNS namespace.


--
P Vixie

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

[DNSOP] Terminology question: split DNS

[Paul Hoffman]

Some folks had reservations about the current definition of "split DNS":
   "Where a corporate network serves up partly or completely different 
DNS inside and outside
   its firewall. There are many possible variants on this; the basic 
point is that the
   correspondence between a given FQDN (fully qualified domain name) 
and a given IPv4 address

   is no longer universal and stable over long periods."
   (Quoted from , Section 3.8)

What would the WG like for this definition?

--Paul Hoffman

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

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Stephane Bortzmeyer]

On Mon, Mar 19, 2018 at 08:22:03AM -0400,
 Paul Wouters  wrote 
 a message of 57 lines which said:

> We have just submitted a draft aimed at increasing the security of
> the DNSSEC with respect to the power that parental zones have over
> their children.

I'm opposed to this idea.

> While the root and TLD zones are asumed to be almost exclusively
> delegation-only zones,

This is unrelated. You mix two different things, the administrative
issue and the technical one (every subdomain in its own zone). gouv.fr
is administratively a delegation from .fr but is in the same zone.

> the root zone operator (or any level higher in the hierarchy than
> the target victim) could briefly remove the NS and DS records, and
> create a "legitimate" DNS entry for "www.example.org"

That's the DNS. It is a tree. Protecting childs against the parent is
a non-goal, or otherwise we should move to some alternative to DNS
(Namecoin is cool).

> The aim here is to counter the argument that the root key and TLD
> keys are all powerful and under government control, and can therefor
> never be trusted.

I've read the draft and still can understand nothing in this sentence.

> 2) Allow the creation of DNSSEC transparency logs

May be mentioning draft-zhang-trans-ct-dnssec would be nice?

>  The DELEGATION_ONLY flag has a strong overlap in functionality with
>  the Public Suffix List as both signal a formal split of authority
>  between parent and child.

May be mentioning the defunct DBOUND working group would be a good
idea?

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

[Vladimír Čunát]

On 03/06/2018 01:30 AM, Wessels, Duane wrote:
> I think its different.  The above can tell you whether certain names were 
> resolvable (maybe even validatable?) but kskroll sentinel tells you that 
> specific key tags are or are not present in the TA store even if those keys 
> don't have "active" chains of trust.

Yes, the point of this RFC is to disclose information that we don't know
how to obtain without the RFC.  The question is whether the positive or
negative potential of this disclosure is larger (possibly in each
deployed instance separately).

TL;DR: altogether the risks known so far seem acceptable to me.  The
"leaked" information is noted in the "Security Considerations" section
(incl. third parties).  Of course, implementations might like to provide
a way to disable compliance to this RFC.

If a root key is compromised, this information does seem misusable to
simplify choosing targets for attacks.  Here it might be good that the
RFC is written to disclose only the root trust.  The RFC might
theoretically be amended to handle revoked keys in a special way - to
hide some parts of information that we don't need now, but such attempts
don't seem worth it (to me).  One reason is complexity, and the more
important one is that it will also be *useful* that people have a way to
test that their resolver correctly distrusts revoked root keys.  Note
that the good testability effects of this RFC apply even in regular
rollovers (without key compromise), so we can detect bad instances more
easily, and the negative effects only apply in the (unlikely) case of
root key compromise.  (It seems similar to usual
security-through-obscurity arguments.)

I suppose cases like Freedonians will need some extra patches or
configuration knobs, in case they want to hide their non-compliance
while appearing to follow the RFC.  That is, assuming the non-compliance
can't be found out in some other easy way (already).

--Vladimir

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

Re: [DNSOP] Comments on draft-ietf-dnsop-session-signal-06

[Stuart Cheshire]

On 5 Mar 2018, at 14:56, Paul Hoffman  wrote:

> This draft is much clearer about DSO unacknowledged messages, which really 
> helps understanding the protocol. Also, thank you for switching from "octet" 
> to "byte". :-)

Thanks for your feedback Paul.

> A few other comments:
> 
>   In this document the term "session" is used exclusively as described
>   above, and is in no way related to the anachronistic term "session"
>   as used in the obsolete "seven-layer model" that shaped the design of
>   the failed OSI protocols of the 1980s.
> 
> Judgmental language seems unneeded here.

Just a test to check if anyone was actually reading the draft :-)

It is now changed to this:

   In this document the term "session" is used exclusively as described
   above.  The term has no relationship to the "session layer" of the
   OSI "seven-layer model" popularized in the 1980s.

>   Note that for clients that implement only the DSO-TYPEs defined in
>   this base specification, sending a DSO Keepalive TLV is the only DSO
>   request message they have available to initiate a DSO Session.  Even
>   for clients that do implement other future DSO-TYPEs, for simplicity
>   they MAY elect to always send an initial DSO Keepalive request
>   message as their way of initiating a DSO Session.
> 
> It is unclear whether this is meant to place a restriction on future 
> protocols that define new DSO-TYPEs. Assuming that it is, it might be clearer 
> to say so explicitly.

I have updated the text as follows:

   <>  A future
   definition of a new response-requiring DSO-TYPE gives implementers
   the option of using that new DSO-TYPE if they wish, but does not
   change the fact that sending a DSO Keepalive TLV remains a valid way
   of initiating a DSO Session.

> The second paragraph of Section 5.6.1 give an example that is much more 
> detailed, and possibly conflicting with the (apparently normative) table in 
> Section 4.2.1.
> 
>   |9 | NOTAUTH   | Not Authoritative (TLV-dependent)  |
> 
>   An RCODE value of NOTAUTH indicates
>   that the server has been reconfigured and is no longer able to
>   perform one or more of the functions currently being performed on
>   this DSO Session because it no longer has authority over the names in
>   question.
> 
> The table entry says nothing about the server being reconfigured, nor about 
> "no longer able" as compared to "was never able”.

You are right. This part of the document was not sufficiently thorough. I also 
realized it was unclear about what to do when there is more than one reason for 
the server wanting to end the session. I have updated the text as shown below:

6.2.1.  Retry Delay TLV used as a Primary TLV

   When sent from server to client, the Retry Delay TLV is used as the
   Primary TLV in an unacknowledged message.  It is used by a server to
   instruct a client to close the DSO Session and underlying connection,
   and not to reconnect for the indicated time interval.

   In this case it applies to the DSO Session as a whole, and the client
   MUST begin closing the DSO Session, as described in Section 5.6.1.
   The RCODE in the message header SHOULD indicate the principal reason
   for the termination:

   o  NOERROR indicates a routine shutdown or restart.

   o  FORMERR indicates that the client requests are too badly malformed
  for the session to continue.

   o  SERVFAIL indicates that the server is overloaded due to resource
  exhaustion and needs to shed load.

   o  REFUSED indicates that the server has been reconfigured, and at
  this time it is now unable to perform one or more of the long-
  lived client operations that were previously being performed on
  this DSO Session.

   o  NOTAUTH indicates that the server has been reconfigured and at
  this time it is now unable to perform one or more of the long-
  lived client operations that were previously being performed on
  this DSO Session because it does not have authority over the names
  in question (for example, a DNS Push Notification server could be
  reconfigured such that is is no longer accepting DNS Push
  Notification requests for one or more of the currently subscribed
  names).

   This document specifies only these RCODE values for Retry Delay
   message.  Servers sending Retry Delay messages SHOULD use one of
   these values.  However, future circumstances may create situations
   where other RCODE values are appropriate in Retry Delay messages, so
   clients MUST be prepared to accept Retry Delay messages with any
   RCODE value.

   In some cases, when a server sends a Retry Delay message to a client,
   there may be more than one reason for the server wanting to end the
   session.  Possibly the configuration could have been changed such
   that some long-lived client operations can no longer be continued due
   to policy (REFUSED), and other long-lived client operations can no
   longer be 

Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

[Vladimír Čunát]

On 03/18/2018 09:44 PM, Petr Špaček wrote:
> The current text in section 5 is written with an assumption that query
> with +CD bit cannot result in "Secure" status and thus cannot trigger
> sentinel processing, but this depends on implementation.

I just want to note that this situation of answering +cd queries by
validated cached RRs isn't very implementation-specific.  One way to
come to this: it seems generally desirable to have aggressive caching
(rfc8198) on forwarders, due to serving as a cache shared by multiple
resolvers, and validating resolvers tend to use +cd to query the
forwarders (rfc4035#section-3.2.2).

--Vladimir

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

[DNSOP] I-D Action: draft-ietf-dnsop-session-signal-07.txt

[internet-drafts]

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 WG of the IETF.

Title   : DNS Stateful Operations
Authors : Ray Bellis
  Stuart Cheshire
  John Dickinson
  Sara Dickinson
  Ted Lemon
  Tom Pusateri
Filename: draft-ietf-dnsop-session-signal-07.txt
Pages   : 53
Date: 2018-03-19

Abstract:
   This document defines a new DNS OPCODE for DNS Stateful Operations
   (DSO).  DSO messages communicate operations within persistent
   stateful sessions, using type-length-value (TLV) syntax.  Three TLVs
   are defined that manage session timeouts, termination, and encryption
   padding, and a framework is defined for extensions to enable new
   stateful operations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-07
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-bootstrap-validator-00.txt

[tjw ietf]

I will say that I tolerate Joe's hand waving, I can't speak for my
co-chair.



On Mon, Mar 19, 2018 at 3:14 PM, Joe Abley  wrote:

> Hi all,
>
> This draft from 2011 emerged blinking into the sunlight from the grave
> where it expired, growling something about KSK rollovers and brains. Dave
> and I promptly wrestled it to the ground and locked it in the datatracker
> where we can safely poke sticks at it through the reinforced metal bars.
>
> The original draft contained this prescient language:
>
>The possibility remains, however, that [RFC5011] signalling will not
>be available to a validator: e.g. certain classes of emergency KSK
>rollover may require a compromised KSK to be discarded more quickly
>than [RFC5011] specifies, or a validator might be off-line over the
>whole key-roll event.
>
>This document provides guidance on how DNSSEC Validators might
>determine an appropriate set of trust anchors to use at start-up, or
>when other mechanisms intended to allow key rollover to be tolerated
>gracefully are not available.
>
> Dave and I imagine this kind of thinking might be relevant and timely. Tim
> and Suz have kindly tolerated my increasingly frantic handwaving on this
> subject and have offered me some minutes in the dnsop meeting tomorrow,
> where I intend to suggest that a specification along these lines is
> necessary and that the working group should take this on.
>
>
> Joe
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **New Version Notification for
> draft-jabley-dnsop-bootstrap-validator-00.txt*
> *Date: *19 March 2018 at 14:59:53 GMT
> *To: *"Joe Abley" , "Dave Knight" <
> dave.knight@team.neustar>
>
>
> A new version of I-D, draft-jabley-dnsop-bootstrap-validator-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
>
> Name: draft-jabley-dnsop-bootstrap-validator
> Revision: 00
> Title: Establishing an Appropriate Root Zone DNSSEC Trust Anchor at
> Startup
> Document date: 2018-03-19
> Group: Individual Submission
> Pages: 9
> URL:https://www.ietf.org/internet-drafts/draft-
> jabley-dnsop-bootstrap-validator-00.txt
> Status: https://datatracker.ietf.org/doc/draft-jabley-
> dnsop-bootstrap-validator/
> Htmlized:   https://tools.ietf.org/html/draft-jabley-dnsop-
> bootstrap-validator-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-
> jabley-dnsop-bootstrap-validator
>
>
> Abstract:
>   Domain Name System Security Extensions (DNSSEC) allow cryptographic
>   signatures to be used to validate responses received from the Domain
>   Name System (DNS).  A DNS client which validates such signatures is
>   known as a validator.
>
>   The choice of appropriate root zone trust anchor for a validator is
>   expected to vary over time as the corresponding cryptographic keys
>   used in DNSSEC are changed.
>
>   This document provides guidance on how validators might determine an
>   appropriate trust anchor for the root zone to use at start-up, or
>   when other mechanisms intended to allow key rollover to be tolerated
>   gracefully are not available.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> ___
> 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] Fwd: New Version Notification for draft-jabley-dnsop-bootstrap-validator-00.txt

[Joe Abley]

Hi all,

This draft from 2011 emerged blinking into the sunlight from the grave where it 
expired, growling something about KSK rollovers and brains. Dave and I promptly 
wrestled it to the ground and locked it in the datatracker where we can safely 
poke sticks at it through the reinforced metal bars.

The original draft contained this prescient language:
   The possibility remains, however, that [RFC5011] signalling will not
   be available to a validator: e.g. certain classes of emergency KSK
   rollover may require a compromised KSK to be discarded more quickly
   than [RFC5011] specifies, or a validator might be off-line over the
   whole key-roll event.

   This document provides guidance on how DNSSEC Validators might
   determine an appropriate set of trust anchors to use at start-up, or
   when other mechanisms intended to allow key rollover to be tolerated
   gracefully are not available.
Dave and I imagine this kind of thinking might be relevant and timely. Tim and 
Suz have kindly tolerated my increasingly frantic handwaving on this subject 
and have offered me some minutes in the dnsop meeting tomorrow, where I intend 
to suggest that a specification along these lines is necessary and that the 
working group should take this on.


Joe

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-jabley-dnsop-bootstrap-validator-00.txt
> Date: 19 March 2018 at 14:59:53 GMT
> To: "Joe Abley" , "Dave Knight" 
> 
> 
> 
> A new version of I-D, draft-jabley-dnsop-bootstrap-validator-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Name: draft-jabley-dnsop-bootstrap-validator
> Revision: 00
> Title:Establishing an Appropriate Root Zone DNSSEC Trust 
> Anchor at Startup
> Document date:2018-03-19
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/internet-drafts/draft-jabley-dnsop-bootstrap-validator-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-jabley-dnsop-bootstrap-validator/
> Htmlized:   
> https://tools.ietf.org/html/draft-jabley-dnsop-bootstrap-validator-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-bootstrap-validator
> 
> 
> Abstract:
>   Domain Name System Security Extensions (DNSSEC) allow cryptographic
>   signatures to be used to validate responses received from the Domain
>   Name System (DNS).  A DNS client which validates such signatures is
>   known as a validator.
> 
>   The choice of appropriate root zone trust anchor for a validator is
>   expected to vary over time as the corresponding cryptographic keys
>   used in DNSSEC are changed.
> 
>   This document provides guidance on how validators might determine an
>   appropriate trust anchor for the root zone to use at start-up, or
>   when other mechanisms intended to allow key rollover to be tolerated
>   gracefully are not available.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

[DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

[Paul Wouters]

We have just submitted a draft aimed at increasing the security of the DNSSEC
with respect to the power that parental zones have over their children.

The aim of this draft is twofold:

1) Allow zones to publicly commit to being delegation_only zones.

The aim here is to counter the argument that the root key and TLD
keys are all powerful and under government control, and can therefor
never be trusted.

2) Allow the creation of DNSSEC transparency logs

With delegation_only zones, we can limit DNSSEC transparency to only
log DS and DNSKEY and their proof of non-existenc. While this does not
prevent all rogue parental data, it does prevent it for those records
that matter (TLSA, SMIMEA, OPENPGPKEY).

Please have mercy on our souls,

Paul, Frank and Wes


A new version of I-D, draft-pwouters-powerbind-00.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Name:   draft-pwouters-powerbind
Revision:   00
Title:  The Delegation_Only DNSKEY flag
Document date:  2018-03-19
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-pwouters-powerbind-00.txt
Status: https://datatracker.ietf.org/doc/draft-pwouters-powerbind/
Htmlized:   https://tools.ietf.org/html/draft-pwouters-powerbind-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-pwouters-powerbind


Abstract:
   This document introduces a new DNSKEY flag called DELEGATION_ONLY
   that indicates that the particular zone will never sign zone data
   across a label.  That is, every dot is considered a zone cut and must
   have its own (signed) delegation.



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

The IETF Secretariat

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

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

[Matthijs Mekking]

Hi,


While I was not waiting for WG last call, it is a while ago since I have 
read this draft. Positive is that I read it without it leading to a lot 
of confusion or outrage.


I have some small comments though.


Negative response:

I and some others have been using the term 'Negative response' to 
indicate that the response does not contain any records in the Answer 
section. Current definition seems to imply that this is only the case if 
the RCODE is NXDOMAIN, NOERROR, SERVFAIL or if there was a timeout 
(unreachable). The definition I have been using includes responses with 
other RCODEs too, for example FORMERR or REFUSED.


I wonder if this is just me and my bubble or if others also a slightly 
different meaning of 'Negative response' as it is defined now. If there 
are others, is it worth spending a line or two about this here?



RRsets:

Raised by a discussion I had at the Hackathon, I think it would be 
useful to add some clarification about RRSIGs and their role with 
respect to RRsets. Perhaps a quote from RFC4035 will do:


   An RRset MAY have multiple RRSIG RRs associated with it.  Note that
   as RRSIG RRs are closely tied to the RRsets whose signatures they
   contain, RRSIG RRs, unlike all other DNS RR types, do not form
   RRsets.  In particular, the TTL values among RRSIG RRs with a common
   owner name do not follow the RRset rules described in [RFC2181].


Last, I don't fully understand the meaning of the cryptic comment about 
QTYPE=ANY that is under the RRset definition:


   (This definition is definitely not the same as "the
   response one gets to a query for QTYPE=ANY", which is an
   unfortunate misunderstanding.)

Can you explain why this comment is here?


Thanks, best regards,

Matthijs




On 05-03-18 17:14, Paul Hoffman wrote:
Greetings. As you can see, draft-ietf-dnsop-terminology-bis-09.txt is 
out. Reading the diff might be a bit difficult because of the 
reorganization of some sections that y'all asked for, but I think the 
result is worth the extra effort.


We're still not done yet. I took a hiatus from finishing the list of 
definitions that people wanted more scrutiny on, but will start that 
again soon. I hope we'll be done with that list by mid-April and then be 
ready for WG last call.


As a side note, some of the changes in this version came from people 
reading the document fresh. I encourage folks who were maybe waiting for 
WG Last Call to do a first deep reading of the document to instead do so 
now. The work that everyone is doing on this document will go a long way 
to making the final RFC more valuable for lots of folks entering the field.


--Paul Hoffman

___
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