Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

[Brian Dickson]

Mark,

When I say, "never reaches the roots", this is what I mean:
Resolution of "example." is, by design, intercepted by
homenet resolvers, and never reaches the outside world.
Do you concur with this statement?

Please stop conflating the issue of "the homenet namespace is local" (and
thus not resolvable from outside starting at the DNS root) from the issue
of the need for an insecure delegation IF homenet end systems do their own
DNSSEC validation AND those same end systems don't special-case homenet
from validation AND IF homenet is not signed with a separate trust anchor.

Yes, IF validating stubs need to confirm the unsigned nature of homenet,
THEN there is a need for retrieving the appropriate DNSSEC proof showing
that there is a delegation out of the chain of trust anchored at the DNS
root.

What that proof looks like is dependent on the issue under discussion,
which is what the domain name for homenet should be, and why.

If the domain for homenet is "homenet." anchored in the root zone, then
yes, "homenet/DS" will need to be obtained (or more correctly,
"homenet/NSEC" proving no DS exists), signed by the ZSK of the root, along
with the signed DNSKEY set (signed by the KSK of the root, i.e. the ICANN
root trust anchor).

If the domain for homenet is something else, such as "homenet.arpa.", then
the proof contains more elements, such as the DS for arpa, and the NSEC for
homenet.arpa (proving no homenet.arpa/DS exists).

Brian

On Thu, Mar 30, 2017 at 12:20 AM, Mark Andrews <ma...@isc.org> wrote:

>
> In message <CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__+34BRowwUw@mail.
> gmail.com>, Brian Dickson writes:
> > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley <m...@townsley.net>
> wrote:
> >
> > >
> > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> > <mcr+i...@sandelman.ca>
> > > wrote:
> > > >
> > > >
> > > > Terry Manderson <terry.mander...@icann.org> wrote:
> > > >> B) seek a .homenet special use domain WITHOUT the delegation request
> > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
> > > >> community to achieve an insecure delegation
> > > >
> > > >> c) seek a .arpa insecure special use delegation
> > > >
> > > >> d) go for "B" and if that doesn't work shift to "C"
> > > >
> > > > Is there some reason we can not proceed with "C", concurrently with
> (B).
> > >
> > > I think that would require a new consensus call. There was a lot of
> work
> > > done to get to the point of agreeing on a path forward at the last
> IETF,
> > > and this path would be rather different than that.
> > >
> > > > This might cause stub resolvers to have to have two cases
> > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could
> deploy
> > > > and attempt interop with SOMETHING.arpa NOW, and it would more
> clearly
> > > > permit "home." to be removed from code.
> > > >
> > >
> > > /chair-hat-off
> > >
> > > I don’t think we want to have two defaults in our specs. It’s bad
> enough
> > > that we are already going to end up with .home and .homenet depending
> on
> > > the version of code used or forked from, I really don’t want to do
> anything
> > > that could lead to a third if we can avoid it.
> > >
> > > - Mark
> > >
> >
> > Taking a STRICTLY devil's advocate position here:
> >
> > Isn't it the case that the thing that knows what the  label is,
> > should be able to masquerade on behalf of anything that isn't aware of
> the
> > divergence of the three possible values for ? If you end up with
> > some boxes thinking it is ".home", some ".homenet", and some
> > ".homenet.arpa", as long as one of them knows about all three, it should
> > be possible to resolve the differences.
> >
> > The scope of the namespace is "the home network", and never reaches the
> > real DNS (roots), so at worst it would be folding the three fake
> > namespaces into a unified (three-headed) fake namespace.
>
> Can we please stop with this "and never reaches the real DNS (roots)"
> garbage.  Queries for homenet/DS *will* reach the roots.  That is
> how DNSSEC validation is designed to work.  They *need* to be
> answered with a signed NOERROR NODATA response.  Lots of Linux
> distributions ship with DNSSEC validation enabled for on machine
> clients and they are also c

Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

[Brian Dickson]

On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley  wrote:

>
> > On Mar 29, 2017, at 10:07 AM, Michael Richardson 
> wrote:
> >
> >
> > Terry Manderson  wrote:
> >> B) seek a .homenet special use domain WITHOUT the delegation request
> >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
> >> community to achieve an insecure delegation
> >
> >> c) seek a .arpa insecure special use delegation
> >
> >> d) go for "B" and if that doesn't work shift to "C"
> >
> > Is there some reason we can not proceed with "C", concurrently with (B).
>
> I think that would require a new consensus call. There was a lot of work
> done to get to the point of agreeing on a path forward at the last IETF,
> and this path would be rather different than that.
>
> > This might cause stub resolvers to have to have two cases
> > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
> > and attempt interop with SOMETHING.arpa NOW, and it would more clearly
> > permit "home." to be removed from code.
> >
>
> /chair-hat-off
>
> I don’t think we want to have two defaults in our specs. It’s bad enough
> that we are already going to end up with .home and .homenet depending on
> the version of code used or forked from, I really don’t want to do anything
> that could lead to a third if we can avoid it.
>
> - Mark
>

Taking a STRICTLY devil's advocate position here:

Isn't it the case that the thing that knows what the  label is,
should be able to masquerade on behalf of anything that isn't aware of the
divergence of the three possible values for ? If you end up with
some boxes thinking it is ".home", some ".homenet", and some
".homenet.arpa", as long as one of them knows about all three, it should be
possible to resolve the differences.

The scope of the namespace is "the home network", and never reaches the
real DNS (roots), so at worst it would be folding the three fake namespaces
into a unified (three-headed) fake namespace.

I.e. avoid it if you can, but if you can't, I think the issues are
solvable, even if they get a little funky/ugly under the hood.

None of that should be visible to users, I don't think.

Brian

P.S. Guide to implementers - never expose multiple handles for the same
object; over-exuberant users may be tempted to try to "clean up" the
duplicates.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

[Brian Dickson]

I was thinking about the DNSSEC validation by stubs, with respect to the
homenet discussion.

And, I was wondering about various trust anchor options (other than ICANN's
current root trust anchor).

It occurred to me, that any non-ICANN trust anchor, would possibly require
5011 key rolls under certain circumstances.

Which begs the question: are validating stub resolvers presumed to be
5011-capable?

But, I realize, the issue of 5011 capability also exists for the root trust
anchor.

So, the dilemma is:

   - Can we assume 5011 stub support regardless?
   - If not, does this make the DNSSEC issue for homenet moot, since the
   root KSK will be rolled in the near future (for some value of "near
   future"), and break stub validation?

On the other hand, if 5011 support by stubs is assumed, there is one
interesting option:

Establish a trust anchor for homenet (whatever name is used), AND publish
the private keys.

This creates the ability to have a master DNS authority server, in any
given homenet instance, sign the data in the homenet zone. The default
software could/would need to ship with the trust anchor, and the private
key. The out-of-the-box behavior would just work, and would verify/validate
properly for validating stubs that ship with the homenet trust anchor.

There would then be the ability for users running their own homenet
networks, to do the equivalent of changing the default password -- they
would be able to do a 5011 key roll, which would cause the default trust
anchor to be replaced with a unique trust anchor for that specific homenet.

It's not part of the homenet standard (yet), but might be worth thinking
about.

Again, the main question is, has an assumption about 5011 support in stubs
been made, and is it a valid assumption?

If not, to re-emphasize, then the "unsigned delegation" thing isn't even
necessary, since the stub resolvers won't be able to validate ANYTHING.

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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Brian Dickson]

On Mon, Mar 20, 2017 at 6:54 PM, Ted Lemon <mel...@fugue.com> wrote:

> On Mar 20, 2017, at 9:50 PM, Brian Dickson <brian.peter.dick...@gmail.com>
> wrote:
>
> This would require an update every time the KSK is rolled, or whenever the
> RRSIG needs to be refreshed. 68 years is an inconvenient interval, so maybe
> 50 or 20 years? This is still a lot better than 1 week or 1 month.
>
>
> Isn't there some inconvenient process involved in using the KSK?   I
> suspect that in practice, this makes it harder, not easier.
>

Yes, very much so, although I'm answering from second- or third-hand
knowledge.

As I understand it, the whole process of using the KSK is a scripted,
recorded ceremony in a carefully controlled super-restricted environment,
so this would need to be added to that script.

On the plus side, if it only needs to be done on the very rare occasion
(every N years or when the KSK rolls), I think the benefit would outweigh
the initial barrier to change.

But, that is probably for the folks with direct knowledge to comment on.
I'm just putting the suggestion forward.

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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Brian Dickson]

Just to follow through on my thought(s) on this... (thought in-line below).

On Mon, Mar 20, 2017 at 6:25 PM, Ted Lemon <mel...@fugue.com> wrote:

> I'm curious what Russ and Steve think about this as an alternative.   It
> seems a bit byzantine to me, but I can't say that I object to it on
> principal.   It does create a lot of extra work for ICANN, though, and it
> would be a bit more brittle than just doing an unsigned delegation: we now
> have to have some way to get current versions of these signatures into the
> homenet resolver.
>

Given that hypothetically this would not be published in the root zone,
there are ways to make this less brittle or expensive.
(Apologies in advance to anyone who might sprain their eyebrows.)

Technically, it is possible use the KSK instead of the ZSK in generating an
RRSIG.
This would alleviate the temporal nature of validation from ZSK-derived
RRSIGs. (Continue reading for why this matters.)

And also technically, an RRSIG can have a nearly-arbitrary validity period,
up to 68 years.

So, if ICANN were to agree to do so, they could provide a long-lived RRSIG
signed directly by the root trust anchor, aka the KSK of the root zone.
This would validate for however long the RRSIG's validity period is, or
until the KSK rolls.

This would require an update every time the KSK is rolled, or whenever the
RRSIG needs to be refreshed. 68 years is an inconvenient interval, so maybe
50 or 20 years? This is still a lot better than 1 week or 1 month.

The question of how to publish this is orthogonal; perhaps some existing or
new RRTYPE, at some well-known place in the DNS tree, maybe under ".arpa"
somewhere convenient? Ideally also DNSSEC-signed.

Just suggesting something that is technically feasible...

Brian


>
> Further comments inline.
>
> On Mar 20, 2017, at 6:08 PM, Brian Dickson <brian.peter.dick...@gmail.com>
> wrote:
>
>
>1. What is required for the above, is generation of DNSSEC records
>including RRSIG(NS), NSEC, and RRSIG(NSEC), for "homenet" TLD.
>
>
> Yes.
>
> Since the queries are never meant to reach the root servers, the presence
> or absence of "homenet" in the root is mostly moot.
>
>
> Sure.
>
> The only technical requirement is that suitable DNSSEC records be
> generated, and that the special-purpose homenet DNS resolvers are able to
> have up-to-date copies of these DNSSEC records.
>
>
> Sure.
>
> As a technical matter, this does not require publishing these records in
> the root zone, although that would be one way of achieving the necessary
> requirement.
>
>
> True.
>
> Perhaps the homenet WG folks could talk to the ICANN folks about ways of
> accomplishing the above, without the need for publishing the unsigned
> delegation in the root zone?
>
>
> Strictly speaking I think this is something the IESG would have to do.  I
> don't object to this as a solution, but operationally I think it's a lot
> more work.   It may be that it's worth doing it, since it might be
> applicable to other special-use name allocations.
>
> The benefit of not publishing, is that any queries that do hit the root
> servers, would get a signed NXDOMAIN, which IMHO is a more correct response.
>
>
> Yes.   I'm not sure that's enough to justify the extra work.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Brian Dickson]

> Hi,
> The INT Area Director who oversees the homenet WG, Terry Manderson, has
> asked DNSOP participants to review
> https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt, "Special Use Top
> Level Domain '.homenet’”, with the following aspects in mind:
> 1) in terms of RFC6761
> 2) in terms of the _operational_ position of an unsigned entry in the root
> zone as requested in this document, to break the chain of trust for local
> DNS resolution of .homenet names.
>

I'd like to ask some questions about homenet and the TLD.

These are mostly clarification questions, but might (together) lead to an
alternative solution.


   1. The homenet TLD is intended to be used in such a way that queries
   should never reach the root servers. Is this correct?
   2. The main issue driving the request for the insecure delegation, is
   the ability to have a proof of insecurity anchored at the ICANN
   root-of-trust, aka the KSK for the root zone. Is this correct?
   3. Resolvers doing "homenet" need to be able to serve current "proof"
   responses, whose signatures' validity periods are "current". Is this
   correct?
   4. What is required for the above, is generation of DNSSEC records
   including RRSIG(NS), NSEC, and RRSIG(NSEC), for "homenet" TLD.

Since the queries are never meant to reach the root servers, the presence
or absence of "homenet" in the root is mostly moot.

The only technical requirement is that suitable DNSSEC records be
generated, and that the special-purpose homenet DNS resolvers are able to
have up-to-date copies of these DNSSEC records.

As a technical matter, this does not require publishing these records in
the root zone, although that would be one way of achieving the necessary
requirement.

Perhaps the homenet WG folks could talk to the ICANN folks about ways of
accomplishing the above, without the need for publishing the unsigned
delegation in the root zone?

The benefit of not publishing, is that any queries that do hit the root
servers, would get a signed NXDOMAIN, which IMHO is a more correct response.

(It also prevents the problem of what NS values would need to be used on
the unsigned delegation.)

Brian



> This document is the product of the homenet WG, which has asked the IESG
> to approve it for publication, so our comments are strictly advisory to the
> IESG. There was some discussion of the draft on this list shortly after it
> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
> additional review.
>
>
> thanks,
> Suzanne & Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Brian Dickson]

>
> Richard Gibson  wrote:
> > Because without such a signal, humans using ANY for legitimate diagnostic
> > purposes have no means of differentiating section 4.1/4.3 "subset"
> > responses from conventional responses where there just happen to be only
> a
> > small number of RRSets at the queried name, encouraging (or at least
> doing
> > nothing to dissuade) a conclusion that the response is in fact
> conventional
> > and complete.
> There are several ways to avoid this pitfall:
> Use TCP
> Look for an NSEC(3) record
> Query for the specific types you want to know about
> Tony.


I hope it's not too late to discuss additions to the I-D. Sorry for not
contributing sooner.

So, I have a question about EDNS and DNSSEC (and maybe when DO=1):

Suppose a zone is NOT signed, but the requestor uses EDNS (and maybe DO=1).

What would resolvers do if they received, in addition to normal RRs, one or
more NSEC or NSEC3 records, and no RRSIGs?

That would be one way to provide information about RRtypes at the owner
name, even if the zone was unsigned.

Would it be feasible to limit the behavior of "refuse-any" returning
"partial" UDP responses, to situations where EDNS with DO=1 is used? Older
resolvers would need to have some method of getting answers, so maybe for
those, use the TC=1 method?

Specifically:
 When a QTYPE=ANY is received, respond with some "arbitrary" choice of
RRTYPE, and add an unsigned NSEC or NSEC3 record to list RRTYPEs present.

In the case of SIGNED zone, returning a random RRtype and including the
NSEC/NSEC3 would be ideal for both signaling that "ANY" is not supported,
as well as what else to query for.

I think NSEC or NSEC3 could be used in an unsigned zone, and generated "on
the fly" with trival or empty values for "next owner", with the caveat that
it MUST NOT be used for generating negative or empty responses. But that is
a stretch, and probably not worth pursuing without some further
investigation into resolvers' handling of such unsigned responses inside
unsigned zones.

(This on-the-fly suggestion is a compromise to avoid the need for
NSEC/NSEC3 over unsigned zones, or forcing everything to be signed, which
is clearly not yet a reasonable suggestion.)

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews  wrote:

>
> In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon
> writes:
> >
> > On Feb 9, 2017, at 3:45 PM, Mark Andrews  wrote:
> > > At the moment we have Ted saying that if you want privacy you MUST
> > > also turn on DNSSEC validation and implement QNAME minimisation and
> > > implement agressive negative caching (still a I-D).
> >
> > No, I am _not_ saying that.   I am saying that an unsigned delegation
> > doesn't help with privacy unless you also specially configure your local
> > resolver, and if you are going to specially configure your local
> > resolver, then there are several options for how to do that.   The only
> > reason you need DNSSEC is that if you specially configure your local
> > resolver to lie, then DNSSEC validation will break that.   If you aren't
> > doing DNSSEC validation, you can say any old thing in your local resolver
> > and the stub will believe it.
>
>
Suppose a signed delegation for alt, to some widely operated, centrally
managed servers (say, the arpa servers).
Now suppose an unsigned delegation for some other name under alt, such as
"foo.alt", to an empty zone on the same set of servers.

The only difference here is where the unsigned delegation is, and what the
scope of that delegation is.

In this scenario, any local "foo.alt" can lie about the contents of
"foo.alt", because it is outside of the secure delegation chain from the
root.

The only difference is that the delegation is not directly from the root.

Any other name under "alt" would have its existence securely denied, unless
and until a request for an insecure delegation was made and approved.

Is there a problem with this scenario?


> And a signed answer doesn't help unless the recursive server is
> validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
> (to prevent *.alt leaking in the first place) and has agressive
> negative caching (so the answer from the minimised QNAME query get
> turned into a answer for *.alt).
>
> Now we can put QNAME minimisation into a server.
> Now we can put the code to support agressive negative caching into a
> server.
> We can't force validation to be enabled.
>
> We need all three things for the privacy leakage to stop.  Any two
> alone doesn't stop it.
>


There's something I don't understand.

In the case where the local namespace (in your email, that would be "alt",
in my example above, that would be "foo.alt") is not configured, why does
leaking matter? Obviously the real local use case is "won't work - broken
config", and leaking is mostly moot.

In the case where the local namespace is instantiated, the queries won't
leak to the root, so privacy is assured.

Are you saying that leakage when the local namespace is non-existent, is
a/the issue?

I don't agree, if that is what you are asserting.
Queries for "rumplestiltskin.foo.alt" can't expect privacy, unless they are
using a resolver specifically configured for "foo.alt".
Note that defaulting to providing "empty.as112.arpa", and having the DNAME
to "alt.empty.as112.arpa", would further actually accomplish privacy,
without affecting the local instantiation of "foo.alt" via
"foo.alt.empty.as112.arpa".

Brian


>
> The alternative is to do a insecure delegation and build in a default
> empty zone for alt.  You then have to take steps to break the privacy
> leak by disabling the empty zone.  Additionally it works with all
> existing servers if they just add a empty .alt zone.  It doesn't
> require validation to be enabled.
>
> It's the difference between defaulting private or not.
>
> Mark
> --
> 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

Maybe DNS authority server software could auto-generate TXT records for what 
would otherwise be ENTs, or zone administrators could add them manually,

E.g. ent.example.com TXT "This object intentionally left blank."

This avoids the ENT issue.

I can't think of any way that would break anything. The issue with ENTs is that 
they have children, which are not changed or harmed. Preventing the erroneous 
NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be returned.

Brian

Sent from my iPhone

> On Feb 9, 2017, at 11:57 AM, Mark Andrews <ma...@isc.org> wrote:
> 
> 
> In message <20170209163123.56hdbzaluekmv...@nic.fr>, Stephane Bortzmeyer 
> writes
> :
>> On Wed, Feb 08, 2017 at 12:36:23PM -0800,
>> Brian Dickson <brian.peter.dick...@gmail.com> wrote 
>> a message of 258 lines which said:
>> 
>>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
>>> - cache the response, and as appropriate, re-query periodically.
>>> - If a query for .onion is received, reply with the authenticated
>>> denial of existence from the root (cached in step 2)
>> 
>> Note that, if you implement RFC 7816 and RFC 8020, you already have
>> this behavior. No work for us :-)
> 
> Only if you are willing to break lookups for names where there are
> missing delegations in parent zone and the parent and child zones
> share the same nameservers or the nameserver just misimplements ENT
> or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist
> with RFC 2535).  All of these result in NXDOMAIN for ENT.
> 
> RFC7816
> 
>   A problem can also appear when a name server does not react properly
>   to ENTs (Empty Non-Terminals).  If ent.example.com has no resource
>   records but foobar.ent.example.com does, then ent.example.com is an
>   ENT.  Whatever the QTYPE, a query for ent.example.com must return
>   NODATA (NOERROR / ANSWER: 0).  However, some name servers incorrectly
>   return NXDOMAIN for ENTs.  If a resolver queries only
>   foobar.ent.example.com, everything will be OK, but if it implements
>   QNAME minimisation, it may query ent.example.com and get an NXDOMAIN.
>   See also Section 3 of [DNS-Res-Improve] for the other bad
>   consequences of this bad behaviour.
> 
> Mark
> 
> -- 
> 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews  wrote:

>
> In message , Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 3:30 PM, Mark Andrews  wrote:
> > > And if the service has the same privacy issues as .onion has?
> > >
> > > So we leak names until every recursive server in the world is
> > > validating (what % is that today?) and supports agressive negative
> > > caching (still a I-D).
> >
> > I feel like I am arguing with a wall, so if this doesn't work I will just
> > give up.   But if it's okay for us to ask resolvers to make a chance, it
> > is okay for us to ask resolvers to make the right change.   And if they
> > don't, yes, it's possible that some queries will leak.   There is nothing
> > we can do to prevent that other than harden caching servers and stub
> > resolvers; if we are going to do that, we might as well do it right, by
> > caching the full proof of nonexistence, rather lying about what's in the
> > root zone.
>
> Actually we can do something that doesn't require that validation
> be enabled.  We don't have to create that linkage.  It's not like
> the names are not supposed to exist.  They do/will exist and not
> as in they are/will be squatted upon.
>

I'm confused here.

The point of ALT (and/or LCL if a 2nd draft is created), and ONION, is that
they exist ONLY within their own (local) scope, if they exist at all.

>From the viewpoint of the global DNS, they do not exist, and the point of
those I-Ds/RFCs is to enforce that non-existence, in the global scope.

My problem with what you are proposes, is that it removes the mechanism for
that enforcement.

Here's a thought - for any/all validating stubs, use CD=1 for names in the
set of "things that are meant to be local", and turn off validation of
those.
That *should*, if I understand 4035's directives for CD=1, prevent
validation by the recursive resolver in use by the client, and will return
whatever answers are present, with or without DNSSEC records.

Or, perhaps the organizations that represent the requestor of the 6761
names, could establish something like a "distrust anchor" - a trust anchor
which is only to be used for signing negative assertions about the TLD
name, or assertions about its insecure status to enable local service of
the TLD name, and which can be published to the community, along with a
static DNS zone file to be served by the -aware resolvers?

Again, just to reiterate, in the global root zone, and for any resolvers
which are not yet onion-aware, onion does not exist and must not exist.

For onion-aware resolvers, everything related to onion is just an
optimization; avoiding leakage for privacy reasons might be an issue for
some folks, but IMHO must not tread on the previous requirement - that
onion must not exist in the root, and must not appear to exist to any
onion-unaware resolvers.

If you want to find a way to fix that, without resulting in BOGUS or
SERVFAIL, there may be ways that aren't easy, but the one way not permitted
by the published RFCs is, an unsigned delegation in the root.

I'm not sure why you disagree with this, it is clear as day in the relevant
RFCs.

Brian




>
> Oh sorry, you can't have privacy unless you validate.  And only
> because people are too scared to ask for changes to the root
> zone to add a delegation.
>
> Mark
> --
> 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews  wrote:

>
> In message , Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 1:02 AM, Mark Andrews  wrote:
> > > Which assumes agggressive negative caching.   I'm going to make a
> > > realistic assumption that it will take 10+ years for there to be
> > > meaningful (>50%) deployment of aggressive negative caching.
> >
> > First of all, this probably isn't true, since most of the caches we care
> > about are run by network operators, who tend to update more frequently
> > for obvious reasons.   But the solution you propose, which causes a
> > SERVFAIL, involves a specially-prepared resolver.   So if you get to
> > _create_ the problem with a specially-prepared resolver, I get to solve
> > it with a differently specially-prepared resolver.   If you want queries
> > to .alt not to leak, you have to preload your cache with a proof of
> > nonexistence for .alt, and you have to keep it up to date.   This is not
> > terribly difficult to arrange.
> >
> > >> Leaking a query to .alt is harmless.
> > >
> > > Is it?  What reports are we going to see over the next 20 year of
> > > DITL data on *.alt.
> >
> > How is that relevant?   Suppose we don't create .alt, and instead people
> > just pick random top-level domains for their experiments, as they do now.
> >   Will the number of bogus queries to the root be greater, or fewer?
> > Furthermore, queries for .alt are legitimate, in just the same way that
> > queries for .com are.   They just have a different answer.
>
> Me, I'm trying to prevent the SERVFAIL issues the IETF has created for
> .onion.  In particular this from RFC7686
>
>4.  Caching DNS Servers: Caching servers, where not explicitly
>adapted to interoperate with Tor, SHOULD NOT attempt to look up
>records for .onion names.  They MUST generate NXDOMAIN for all
>such queries.
>
> Without .onion being a insecurely delegation this results in SERVFAIL
> or BOGUS being returned for .onion named when validation is performed
> by any validating software that is not RFC7686 aware.
>
>
So, while technically the instruction (SHOULD NOT) applies to full .onion
names,
it is a SHOULD NOT, not a MUST NOT.

Again, technically, the bit of code to do the following, IMHO, nears the
level of "trivial":
- upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
- cache the response, and as appropriate, re-query periodically.
- If a query for .onion is received, reply with the authenticated
denial of existence from the root (cached in step 2)

I believe this should prevent any SERVFAIL or BOGUS.

(I think this turns on the pedantic reading of "generate".)



> Nameserver vendors have a choice.  Follow RFC7686 and have their
> clients get a answer that they know cannot be validated or ignore
> this clause and pretend that RFC7686 has never been written so that
> their client get a validatable answer.  Should the IETF have put
> Nameserver vendors in this position?
>
> At this stage we have not yet implemented this clause in BIND.  We
> are aware of RFC7686 and at some point someone will complain that
> we don't implement this.  At that point we will point out to them
> that this results in SERVFAIL or bogus being returned.
>
> Note all through the debate about .onion I raise this issue.  Go
> look at the archives.
>
> Now draft-ietf-dnsop-alt-tld-07 has almost identical wording
>
>4.  Caching DNS servers SHOULD recognize these names as special and
>SHOULD NOT, by default, attempt to look up NS records for them,
>or otherwise query authoritative DNS servers in an attempt to
>resolve these names.  Instead, caching DNS servers SHOULD
>generate immediate negative responses for all such queries.
>
> This clause results in BOGUS or SERVFAIL being returned to the DNS
> application if there is a validator in the return DNS path between
> the caching DNS server and the application.
>

See above; maybe the text of alt-tld should be less prescriptive, and
instead use aggressive-negative compatible language (including use of
legitimate, signed denial of existence RRsets).

Brian



>
> Mark
> --
> 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews  wrote:

>
> In message 

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews  wrote:

>
> In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon
> writes:
> > Hm.   When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> > When I validate, I get a secure denial of existence.   This is the
> > correct behavior.   Why do you think we would get a SERVFAIL?
>
> Because your testing is incomplete.
>
> Go add a empty zone (SOA and NS records only) for alt to your
> recursive server.  This is what needs to be done to prevent
> privacy leaks.
>
>
Here are some possible alternatives (to having the empty zone be named
"alt.").

First: make the locally served empty zone be "empty.as112.arpa".

Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and the
locally served zone be the same name.

Or, third, have some other name for the zone (anything other than alt, or
really anything that doesn't collide with a global name), and then use a
local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that
zone's name (e.g. "homenet" or "homenet.local" or whatever  you wish).

Since all of the above occur at or below the transition to unsigned, they
should validate. (I need to test these, but I don't see why they wouldn't
work, and all of the above avoid leaking queries to the root or to AS112
servers.)

Brian



> Configure another recursive server to forward its queries to this
> server and enable validation.
>
> Now ask for foo.alt from this second server.
>
> Mark
> --
> 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews  wrote:

>
> In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon
> writes:
> > Hm.   When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> > When I validate, I get a secure denial of existence.   This is the
> > correct behavior.   Why do you think we would get a SERVFAIL?
>
> Because your testing is incomplete.
>
> Go add a empty zone (SOA and NS records only) for alt to your
> recursive server.  This is what needs to be done to prevent
> privacy leaks.
>
> Configure another recursive server to forward its queries to this
> server and enable validation.
>
>
I believe this is an erroneous configuration.

You need to have the recursive server (the first one) forward to another
server for the empty zone, otherwise that zone's contents do not end up in
the recursive server's cache.

Once you have that, the other recursive server (added and forwarding to the
first recursive) only gets back the non-leak results.

Since the first server is always forwarding to the empty zone, it never
queries the root, and never gets the authenticated denial of existence.

Brian


> Now ask for foo.alt from this second server.
>
> Mark
> --
> 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews <ma...@isc.org> wrote:

>
> In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian
> Dickson writes:
> > The suggestion of DNAME to empty.as112.arpa involves some subtle details,
> > which IMHO may in combination be the right mix here.
> >
> > The DNAME target is an insecure empty zone.
> >
> > This avoids the validation issue, and facilitates use of local "alt"
> > namespaces.
>
> No it doesn't.
>
> > The default response to queries under alt would be unsigned NXDOMAINs.
>
> No, it would be a secure response saying that foo.alt is covered
> by a DNAME.  The names under empty.as112.arpa are unsigned NXDOMAINs.
>
> The difference between the two descriptions is critical to why a
> DNAME in the root zone will not work.  You *have* to leak names to
> the root to get a DNAME returned by ordinary processing because the
> DNAME is signed.
>
> > I am not seeing a problem with this.
> >
> > Am I missing anything?
>
> Yes.  A solution that *works*.
>
>
What are the specific requirements for the solution?

I am inferring that the following are needed:

The ability to have a local authority server for *.alt, where responses to
queries with DO=1 do not include any DNSSEC RRs, i.e. unsigned responses.

The ability to have validating forwarders configured to point to one or
more resolvers, where the resolvers are configured to use these alt
server(s) (directly or indirectly)

The ability of validating stub resolvers to accept the answers received
(not BOGUS).

Does the existence of query rewriting matter, as long as the end result
RDATA is the expected value?
I.e. If the query is "my-thing.foo.alt", returns a combo of "alt DNAME
empty.as112.arpa" plus "my-thing.foo.empty.as112.arpa  ",
is that acceptable, as long as there is no validation failure?

Whatever initiated the DNS call, via the stub, would get back , and
presumably be unaware of the presence of the DNAME.

I just want to be sure what is or is not acceptable, and what is explicitly
within the requirements for a working solution.

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

The suggestion of DNAME to empty.as112.arpa involves some subtle details, which 
IMHO may in combination be the right mix here.

The DNAME target is an insecure empty zone.

This avoids the validation issue, and facilitates use of local "alt" namespaces.

The default response to queries under alt would be unsigned NXDOMAINs.

I am not seeing a problem with this.

Am I missing anything?

Brian

Sent from my iPhone

> On Feb 6, 2017, at 10:31 PM, Mark Andrews <ma...@isc.org> wrote:
> 
> 
> 
> 
> In message <3581be55-b178-4298-8ee8-73fd16b42...@gmail.com>, Brian Dickson 
> writes:
>> Mark,
>> 
>> I don't think the use cases for most of the sandbox involving alt, and/or
>> the homenet use case, requires support for validating stubs. If stubs
>> aren't already validating, the incremental addition of a local alt, only
>> requires distribution of the trust anchor to the resolvers. That is a
>> solvable problem for most values of "local".
> 
> It's not just stubs.
> 
>> If use cases for non-local or validating stubs exits, IMHO that rises to
>> the level of requiring something real, not an alt name.
>> 
>> If you think that is something that there is a demand for, I don't know
>> if it might belong in a separate domain.
>> 
>> An insecure delegation from the root may be seen as an invitation for
>> exploitation by squatters.
> 
> And if they could find a way to squat here (which requires intercepting
> queries) what would be the problem?  We are expecting the namespace
> to be squatted.  Thats the whole point of the namespace.  In fact
> we are going to tell nameserver vendors to squat on .alt by default*
> to generate the NXDOMAIN responses.
> 
> There is absolutely no need for a secure NXDOMAIN here.  Just as
> there is zero need for secure NXDOMAINs in COM, ORG, NET or any
> other gTLD.  The gTLDs prevent secure delegations being spoofed
> away.  The don't prevent names being spoofed into existence between
> the secure delegations.
> 
> There is absolutely no need for a secure delegation here.
> 
> I have not seen anyone demonstrate a technical need for a secure
> delegation for alt.  There are no formal delegation in alt so there
> can be no secure delegations from alt.
> 
> Mark
> 
>> Sent from my iPhone
> -- 
> 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

Mark,

I don't think the use cases for most of the sandbox involving alt, and/or the 
homenet use case, requires support for validating stubs. If stubs aren't 
already validating, the incremental addition of a local alt, only requires 
distribution of the trust anchor to the resolvers. That is a solvable problem 
for most values of "local".

If use cases for non-local or validating stubs exits, IMHO that rises to the 
level of requiring something real, not an alt name.

If you think that is something that there is a demand for, I don't know if it 
might belong in a separate domain.

An insecure delegation from the root may be seen as an invitation for 
exploitation by squatters.

Sent from my iPhone

> On Feb 6, 2017, at 8:05 PM, Mark Andrews <ma...@isc.org> wrote:
> 
> 
> In message 
> <cah1icipkwcosmqy3kjvsz42lmk37gld6gp2avtnwk0c83k-...@mail.gmail.com>, Brian 
> Dickson writes:
>> 
>> TL;DR: it is possible to have a signed DNAME in the root for alt (to
>> empty.as112.arpa), AND have a local signed alt. Things under this local alt
>> can be signed or unsigned.
> 
> So now there is the problem of distributing trust anchors for the
> locally signed .alt zone just to be able to generate a NXDOMAIN
> response locally so that you don't leak names to the root servers.
> 
> Note: we have no automatic solution to this problem and there is
> no possible solution.
> 
> A DNAME at the root is not the right solution to this.
> 
> Mark
> 
>>> On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <ma...@isc.org> wrote:
>>> 
>>> 
>>> In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@
>>> mail.gmail.com>
>>> , Brian Dickson writes:
>>>> 
>>>>   - I am in favor of AS112 for ALT
>>>>   - For AS112, I prefer the AS112++ method (DNAME)
>>>>   - I do not see why the DNAME would/should not be DNSSEC signed
>>>>   - Any local use of ALT can be served locally and signed using an
>>>>   alternative trust anchor
>>> 
>>> You need a insecure delegation for ALT for the purposes we want to
>>> use ALT for.
>>> 
>>> Go setup a test rig where you have a signed root with ALT as you
>>> described.  A validiting recursive server which also serves foo.alt.
>>> A second validating recursive server which forwards all queries to
>>> the first recursive server.  All servers are configured with a trust
>>> anchor for the test root zone and are validating responses.  Try
>>> to perform a lookup on foo.alt.
>>> 
>> 
>> I spent some time mocking up a variety of configurations.
>> 
>> My original assertion stands; the particulars on making it work are perhaps
>> not interesting to everyone.
>> However, it falls in the "pics or it didn't happen" category, so here's
>> what I did to make it work.
>> 
>> 1 - set up a general resolver with the standard ICANN root trust anchor.
>> Call it "X".
>> 2 - set up a local "fake root server" which delegates to a "local alt
>> server". Call this fake root server "F"
>> 3 - set up a local "alt server" which serves the local "alt" domain
>> (including any delegations, etc). Cal this "A".
>> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a
>> "fake root server" instead of the real root. Call this "Y".
>> 4 - set up a forwarder, which is configured to always forward to "X",
>> except for the zone "alt", where it forwards to "Y". Make sure the
>> necessary trust anchors are configured. Call this "Z".
>> 
>> Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
>> anchors)
>> Z->X otherwise (and validates using the ICANN root trust anchor).
>> 
>> When I do this, I get real answers for everything but "alt". For anything
>> at or under "alt", I get my own local copy.
>> 
>> Everything validates (or is from below an insecure delegation point).
>> 
>> 
>>> 
>>> The second recursive server is the validating client that needs to
>>> be able to get a answer other than BOGUS.  As we want to allow
>>> foo.alt to be unsigned there can't be any other trust anchors,
>>> including negative, configured.
>>> 
>> 
>> In the above scenario, you CAN have an unsigned foo.alt, and it will not
>> get BOGUS.
>> 
>> If you want me to send you configs, just drop me a line.
>> 
>>> 
>>> Only so

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

TL;DR: it is possible to have a signed DNAME in the root for alt (to
empty.as112.arpa), AND have a local signed alt. Things under this local alt
can be signed or unsigned.

On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <ma...@isc.org> wrote:

>
> In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@
> mail.gmail.com>
> , Brian Dickson writes:
> >
> >- I am in favor of AS112 for ALT
> >- For AS112, I prefer the AS112++ method (DNAME)
> >- I do not see why the DNAME would/should not be DNSSEC signed
> >- Any local use of ALT can be served locally and signed using an
> >alternative trust anchor
>
> You need a insecure delegation for ALT for the purposes we want to
> use ALT for.
>
> Go setup a test rig where you have a signed root with ALT as you
> described.  A validiting recursive server which also serves foo.alt.
> A second validating recursive server which forwards all queries to
> the first recursive server.  All servers are configured with a trust
> anchor for the test root zone and are validating responses.  Try
> to perform a lookup on foo.alt.
>

I spent some time mocking up a variety of configurations.

My original assertion stands; the particulars on making it work are perhaps
not interesting to everyone.
However, it falls in the "pics or it didn't happen" category, so here's
what I did to make it work.

1 - set up a general resolver with the standard ICANN root trust anchor.
Call it "X".
2 - set up a local "fake root server" which delegates to a "local alt
server". Call this fake root server "F"
3 - set up a local "alt server" which serves the local "alt" domain
(including any delegations, etc). Cal this "A".
3 - set up a second resolver, with appropriate trust anchor(s), that uses a
"fake root server" instead of the real root. Call this "Y".
4 - set up a forwarder, which is configured to always forward to "X",
except for the zone "alt", where it forwards to "Y". Make sure the
necessary trust anchors are configured. Call this "Z".

Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
anchors)
Z->X otherwise (and validates using the ICANN root trust anchor).

When I do this, I get real answers for everything but "alt". For anything
at or under "alt", I get my own local copy.

Everything validates (or is from below an insecure delegation point).


>
> The second recursive server is the validating client that needs to
> be able to get a answer other than BOGUS.  As we want to allow
> foo.alt to be unsigned there can't be any other trust anchors,
> including negative, configured.
>

In the above scenario, you CAN have an unsigned foo.alt, and it will not
get BOGUS.

If you want me to send you configs, just drop me a line.

>
> Only solutions which allow content from the foo.alt zone to be
> successfully resolved are acceptable.
>
> The following will not work with the above rig:
> * No delegation for ALT.
> * A secure delegation for ALT.
> * A DNAME for ALT in the root zone.
>
> Mark


The problem is with your set-up, not the ability to have a working
local-alt set-up.

You need to put "foo.alt" somewhere OTHER than on the validating recursive
server (which knows how to find the local "alt" stuff.)

TIL you can't mix authority and recursive on the same server, when you are
the target of a forwarder.

If the two are separated, it works correctly, including using an alternate
trust anchor for "alt".

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

On Fri, Feb 3, 2017 at 12:21 PM, Steve Crocker <steve.croc...@gmail.com>
wrote:

> And just to stir the pot a bit, what would you have ICANN do if someone
> applies for .alt as a top level domain?  Is it ok if we say yes and
> delegate the name?  If not, what is the basis for us to say no?
>

The insertion of the DNAME record in the root, instantiates the ALT domain.
It says the ALT domain exists.

However, the DNAME target of an empty zone, assures (with DNSSEC
signatures) that no names below ALT exist.

So, a query to a root server for "alt." would get the DNAME (if the query
was for type DNAME or type ANY), or would get "NODATA" for any other RRTYPE.

And a query to a root server for "anything.alt" would get the DNAME to
AS112.ARPA, and the subsequent query (rewritten as anything.as112.arpa)
would get NXD.

As to the question about applying for "alt": it means no one can apply for
.alt as a TLD, because it is taken. That is the basis for saying "no".

Brian


>
>
> Steve Crocker
> [I am having trouble sending from st...@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> st...@shinkuro.com]
>
> On Feb 3, 2017, at 12:18 PM, Brian Dickson <brian.peter.dick...@gmail.com>
> wrote:
>
> The DNAME has an effect similar to delegation, except that in the case of
> the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a
> well-known & published empty zone (as112.arpa.)
>
> (Delegation and DNAME cannot coexist for the same owner name - that is one
> of the edicts for DNAME, similar to CNAME.)
>
> Any local configuration of something.alt (as an authoritatively served
> zone) would be matched before checking the cache or attempting recursive
> resolution, per 103[345].
>
> I don't have any desire or intention of local something.alt, I'm just
> pointing out that the existence of a signed NXD result (via DNAME to an
> empty zone) doesn't break such a set-up.
>
>
>
> The reason for DNAME instead of delegation, is that it avoids the
> operators of AS112 instances from having to configure the new zone(s)
> whenever a new "delegation" occurs.
>
> If, instead, a delegation were done, the specific zone (.alt) would need
> to be configured and served somewhere.
>
> RFC7535 is designed to avoid the need for coordination in configuring such
> zones.
>
> (RFC7535 also allows authorities for other places in the DNS tree to make
> use of AS112, but that is a non-sequitur.)
>
> Brian
>
> On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <steve.croc...@gmail.com>
> wrote:
>
>> Are you also expecting ALT will never be delegated in the root?  If it
>> were to be delegated in the root, what impact would that have on the uses
>> you have in mind?
>>
>> Steve Crocker
>> [I am having trouble sending from st...@shinkuro.com, but I am receiving
>> mail without trouble.  Please continue to send mail to me at
>> st...@shinkuro.com]
>>
>>
>> On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dick...@gmail.com>
>> wrote:
>>
>> Stephane wrote:
>>
>>> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>>>  Warren Kumari  wrote
>>>  a message of 103 lines which said:
>>>
>>> > or 2: request that the IANA insert an insecure delegation in the
>>> > root, pointing to a: AS112 or b: an empty zone on the root or c"
>>> > something similar.
>>>
>>> Here, people may be interested by draft-bortzmeyer-dname-root (expired
>>> but could be revived). The main objection was the privacy issue
>>> (sending user queries to the "random" operators of AS112.)
>>>
>>>
>> My opinion on these issues are as follows, roughly:
>>
>>- I am in favor of AS112 for ALT
>>- For AS112, I prefer the AS112++ method (DNAME)
>>- I do not see why the DNAME would/should not be DNSSEC signed
>>- Any local use of ALT can be served locally and signed using an
>>alternative trust anchor
>>- I don't think there is any issue with having both the NXD from the
>>   root, and the local assertion of existence, both present (in cache and 
>> in
>>   authoritative data respectively)
>>   - Maybe there are issues with specific implementations?
>>   - If anyone knows of such problems, it would be helpful to
>>   identify them along with the implementation and version
>>- For AS112 privacy, perhaps someone should write up a recommendation
>>to set up local AS112 instances, to provide privacy, as

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson]

The DNAME has an effect similar to delegation, except that in the case of
the AS112++ RFC ( https://tools.ietf.org/html/rfc7535 ) , the target is a
well-known & published empty zone (as112.arpa.)

(Delegation and DNAME cannot coexist for the same owner name - that is one
of the edicts for DNAME, similar to CNAME.)

Any local configuration of something.alt (as an authoritatively served
zone) would be matched before checking the cache or attempting recursive
resolution, per 103[345].

I don't have any desire or intention of local something.alt, I'm just
pointing out that the existence of a signed NXD result (via DNAME to an
empty zone) doesn't break such a set-up.



The reason for DNAME instead of delegation, is that it avoids the operators
of AS112 instances from having to configure the new zone(s) whenever a new
"delegation" occurs.

If, instead, a delegation were done, the specific zone (.alt) would need to
be configured and served somewhere.

RFC7535 is designed to avoid the need for coordination in configuring such
zones.

(RFC7535 also allows authorities for other places in the DNS tree to make
use of AS112, but that is a non-sequitur.)

Brian

On Fri, Feb 3, 2017 at 12:06 PM, Steve Crocker <steve.croc...@gmail.com>
wrote:

> Are you also expecting ALT will never be delegated in the root?  If it
> were to be delegated in the root, what impact would that have on the uses
> you have in mind?
>
> Steve Crocker
> [I am having trouble sending from st...@shinkuro.com, but I am receiving
> mail without trouble.  Please continue to send mail to me at
> st...@shinkuro.com]
>
>
> On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dick...@gmail.com>
> wrote:
>
> Stephane wrote:
>
>> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>>  Warren Kumari  wrote
>>  a message of 103 lines which said:
>>
>> > or 2: request that the IANA insert an insecure delegation in the
>> > root, pointing to a: AS112 or b: an empty zone on the root or c"
>> > something similar.
>>
>> Here, people may be interested by draft-bortzmeyer-dname-root (expired
>> but could be revived). The main objection was the privacy issue
>> (sending user queries to the "random" operators of AS112.)
>>
>>
> My opinion on these issues are as follows, roughly:
>
>- I am in favor of AS112 for ALT
>- For AS112, I prefer the AS112++ method (DNAME)
>- I do not see why the DNAME would/should not be DNSSEC signed
>- Any local use of ALT can be served locally and signed using an
>alternative trust anchor
>- I don't think there is any issue with having both the NXD from the
>   root, and the local assertion of existence, both present (in cache and 
> in
>   authoritative data respectively)
>   - Maybe there are issues with specific implementations?
>   - If anyone knows of such problems, it would be helpful to identify
>   them along with the implementation and version
>- For AS112 privacy, perhaps someone should write up a recommendation
>to set up local AS112 instances, to provide privacy, as an informational
>RFC?
>   - Even simply through resolver configurations, without a full AS112
>   "announce routes"?
>   - Do any resolver packages offer such a simple AS112 set-up?
>   - Maybe the efforts for privacy should start there (implement
>   first, then document)?
>   - Do any stub resolver packages include host-local AS112
>   features/configurations?
>
> Overall, I'm obviously in favor of use of ALT, and for signing whatever is
> done for ALT, and for use of DNAME for ALT.
>
> Brian "DNAME" Dickson
> ___
> 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] ALT-TLD and (insecure) delgations.

[Brian Dickson]

Stephane wrote:

> On Wed, Feb 01, 2017 at 03:28:29PM -0500,
>  Warren Kumari  wrote
>  a message of 103 lines which said:
>
> > or 2: request that the IANA insert an insecure delegation in the
> > root, pointing to a: AS112 or b: an empty zone on the root or c"
> > something similar.
>
> Here, people may be interested by draft-bortzmeyer-dname-root (expired
> but could be revived). The main objection was the privacy issue
> (sending user queries to the "random" operators of AS112.)
>
>
My opinion on these issues are as follows, roughly:

   - I am in favor of AS112 for ALT
   - For AS112, I prefer the AS112++ method (DNAME)
   - I do not see why the DNAME would/should not be DNSSEC signed
   - Any local use of ALT can be served locally and signed using an
   alternative trust anchor
   - I don't think there is any issue with having both the NXD from the
  root, and the local assertion of existence, both present (in cache and in
  authoritative data respectively)
  - Maybe there are issues with specific implementations?
  - If anyone knows of such problems, it would be helpful to identify
  them along with the implementation and version
   - For AS112 privacy, perhaps someone should write up a recommendation to
   set up local AS112 instances, to provide privacy, as an informational RFC?
  - Even simply through resolver configurations, without a full AS112
  "announce routes"?
  - Do any resolver packages offer such a simple AS112 set-up?
  - Maybe the efforts for privacy should start there (implement first,
  then document)?
  - Do any stub resolver packages include host-local AS112
  features/configurations?

Overall, I'm obviously in favor of use of ALT, and for signing whatever is
done for ALT, and for use of DNAME for ALT.

Brian "DNAME" Dickson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

[Brian Dickson]

On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews  wrote:

>
> In message 

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

[Brian Dickson]

On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon  wrote:

> On Dec 14, 2016, at 5:04 PM, John Levine  wrote:
>
> But it's worse than that -- if your client software does DNSSEC
> validation it needs to understand that homenet is a special case and
> it's OK not to validate.
>
> [etc]
>
>
> That is precisely why we need an unsecured delegation.
>
>


I agree that in the current world, an unsigned delegation is required.

I would humbly suggest that use of an AS112-like set of well-known names
and IP addresses, would be the preferred way of DOING that delegation.

A well-known address set would allow homenet-aware devices to be pre-loaded
with the address of the NS, while non-aware would learn it through the
delegation.

If it were possible to have the names be served by root servers (as a
consequence of being in the set of domains served by the root servers),
then the glue data would be signed and validate-able, which is about as
good as you can get (security-wise), while making homenet strictly local.

(Within a given homenet, the well known IP(s) could be handled via anycast
or similar mechanisms, presuming the homenet mechanisms support things like
that.)

My personal recommendation would be non-RFC-1918 well known addresses.

This ensures that for queries that leak from non-1918 space sourced
queries, that the delegation is to an address that is guaranteed to be
reachable, even if the local set-up is badly broken.

That IP would be configured to give itself as the answer to any query, and
be configured to provide (rate-limed) HTTP (wild-card) responses,
that serve up the RFC for how to set up homenet. (If that RFC doesn't
exist, that really should be next on the WG milestones.)

All roads would then lead to the answer to the question, which is, "How do
I get this stuff to work?".

Brian

PS For the DNSSEC-aware humans:

I think this exposes an unforeseen edge case, not covered in the design of
DNSSEC.

I think what would have been ideal, would have been the ability to securely
delegate to a well-known name/address, but without a secure entry point.
I.e. where parent/child NS use different RRTYPEs, and the parent NS is
signed (along with glue), and there is no DS.

The child could exist as an island of security, and have a self-signed
DNSKEY (or KSK/ZSK pair).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?

[Brian Dickson]

A short time ago, in a time zone not far away, Warren Kumari wrote:

On Fri, Oct 14, 2016 at 10:04 AM, Paul Wouters  wrote:

> On Fri, 14 Oct 2016, Stephane Bortzmeyer wrote:

>

>> draft-bortzmeyer-dname-root

>>

>> ,

>> which proposes to "sink" special-use TLD (may be you've heard of RFC

>> 6761 "special use domain names"?) using AS 112,

> This is tricky. We want DNS resolvers to not send these onto the

> internet. But by adding delegations in the root to AS112, aren't

> we making it more likely that the queries leak further onto the net?


My observation here is "yes and no"; the nature of AS112 is that anyone can
deploy an instance, pretty freely/easily.

Basically, the only thing that changes is where those leaks go, not whether
they occur.

The DNAME to AS112++ is a (root) server-side thing, which is not mutually
exclusive (compared to resolver side solutions).

Doing BOTH is probably the most conservative approach. DNAME will work in a
backwards-compatible fashion with older resolvers.
(This was confirmed in the AS112++ work, by Geoff Huston and George
Michaelson, kudos to them. DNAME w/CNAME synthesis FTW.)
Anything else is an optimization, e.g. RFC 6303 stuff.

So, back in ~Feb 2014 we had very similar discussion about ALT-TLD,

AS112 delegations and DNAME.

Initially the ALT-TLD document

(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/) had .alt

being delegated to "new style" AS112 nameservers, but Joe Abley

pointed out that this would be a lame delegation.


A minor caveat: we should be careful in the language we use, to distinguish
"delegate" (use NS) vs DNAME.
A delegation would indeed be lame, while DNAME to AS112++ will never be
lame, per se.

I agree, we should take "delegate" off the table.

We also discussed using DNAME, but the general view seemed to be that

getting this deployed in the root would be an uphill battle; much of

this discussion was happening during the new gTLDs process , "the

variants problem", bundling, etc.

What is the consensus view of now vs 2014? Has anything changed, do we
think?
(I recognise the difficulty in consulting the "magic 8 ball" where
deployment in the root is concerned.)

There is also a big difference between "reserving" something and

actually getting it delegated, even for a "null" answer.


Again, technically, in the DNAME to AS112++, this would be for an
"NXDOMAIN" answer.
But, this is a big difference, in that the result is indistinguishable from
the querier's point of view.

The consensus seemed the be that adding things like .alt to the

RFC6303 ( "Locally Served DNS Zones") registry was sufficient. I think

that the consensus was correct -- RFC6303 zones come baked into most

authoritative resolver packages, and the time to upgrade the majority

of "served users" isn't that long (especially if you get this into the

registry shortly before a large CVE :-P). Anything which isn't caught

by Locally Served Zones simply flows upwards till it hits the root --

which is already handling this garbage anyway...

So, back to Stephane's original question  -- I think that documenting

the current state is useful, or we will have this discussion all over

again in a few months

Below is the .ALT IANA considerations, and extracts of the 6761 "questions":

4.  IANA Considerations

   The IANA is requested to add the ALT string to the "Special-Use

   Domain Name" registry ([RFC6761], and reference this document.  In

   addition, the "Locally Served DNS Zones" ([RFC6303]) registry should

   be updated to reference this document.

4.1.  Domain Name Reservation Considerations

   This section is to satisfy the requirement in Section 5 of RFC6761.

[SNIP]

4.  Caching DNS servers SHOULD recognize these names as special and

   SHOULD NOT, by default, attempt to look up NS records for them,

   or otherwise query authoritative DNS servers in an attempt to

   resolve these names.  Instead, caching DNS servers SHOULD

   generate immediate negative responses for all such queries.

(I would point out that doing "in situ" AS112++ on the caching DNS server
is one way to accomplish this.)

   5.  Authoritative DNS servers SHOULD recognize these names as special

   and SHOULD, by default, generate immediate negative responses for

   all such queries, unless explicitly configured by the

   administrator to give positive answers for private-address

   reverse-mapping names.

For this (5), using the DNAME solution does this explicitly, while "reserve
but don't do anything" does this implicitly.
I like the explicitness of DNAME, only because it tells a human making
inquiries that this is in fact "special".

Brian "DNAME" Dickson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Another suggestion for any

[Brian Dickson]

tl;dr:
I am thinking of the principle of least surprise, for the use case of
interactive dig users.

Here's why:
Asking ANY to a recursive resolver, the expected behavior is whatever is
in the cache (which could be a subset of the real RRsets, and possibly
empty even though RRs exist on corresponding auth servers). No-error,
no-data in this circumstance would not be unexpected, and would not be a
cause for concern.

Asking ANY to an auth server, the expected behavior is everything at this
node.

At 3am, when investigating a problem with a domain, if I unwittingly type
ANY as the type, I don't want to have to think about or remember that the
behavior changed, and that the no-error, no-data answer really means
deprecated.

I would be happy if the differential behavior were refused or notimpl,
in this specific corner case (RD=1, to an auth server).

Maybe that compromise is sufficient? It would still accomplish Olafur's
goal.

Brian

On Wed, Mar 11, 2015 at 2:00 AM, Paul Vixie p...@redbarn.org wrote:



   Brian Dickson brian.peter.dick...@gmail.com
  Wednesday, March 11, 2015 11:13 AM
 On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson 
 brian.peter.dick...@gmail.com wrote:

 Hey, everyone,

 [snip]

 dig-friendly.


 Okay, thinking about this a bit more...
 Recursive vs authoritative, RD=0 vs RD=1.

 In all combinations of the above, do the new thing, except for one
 corner case:
 if(RD==1  I_AM_AUTHORITY) then
   do_ANY

 (Which happens to be the default if someone uses dig against an auth
 server).


 djb doesn't want QTYPE=ANY deprecated in any form.

 olafur doesn't want to do_ANY, under any conditions.

 so i'm baffled by why you're offering this alternative?

 --
 Paul Vixie

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

[DNSOP] Another suggestion for any

[Brian Dickson]

On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson brian.peter.dick...@gmail.com
 wrote:

 Hey, everyone,

[snip]

 dig-friendly.


Okay, thinking about this a bit more...
Recursive vs authoritative, RD=0 vs RD=1.

In all combinations of the above, do the new thing, except for one corner
case:
if(RD==1  I_AM_AUTHORITY) then
  do_ANY

(Which happens to be the default if someone uses dig against an auth
server).

I'm pretty sure this qualifies as leaks nothing.

This stops clients asking recursives for ANY, and stops recursives asking
authorities for ANY (with RD=0).

And, FWIW, I like the noerror/nodata answer.

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

[DNSOP] Suggestion for any - TCP only

[Brian Dickson]

Hey, everyone,

Given the diagnostic value of any (and similarly RRSIG et al), I would
prefer deprecation of only the UDP version, via mechanisms that are
dig-friendly.

E.g. return TC=1 (and minimal response) instead, to trigger TCP retry.

It throws out the bath water, but keeps the baby.

I am guessing here, but would this be easy enough to implement?

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

Re: [DNSOP] Comments on draft-ietf-dnsop-root-loopback

[Brian Dickson]

On Sat, Jan 10, 2015 at 10:05 AM, Paul Hoffman paul.hoff...@vpnc.org
wrote:

 Wearing my co-author hat:

 On Dec 29, 2014, at 2:23 PM, Brian Dickson brian.peter.dick...@gmail.com
 wrote:
  - Given the unsigned nature of the glue in the zone, and the importance
 of root glue, it might be the right time to also introduce a zone
 signature RR, signed by the ZSK.

 It might be, but that certainly would not go in this document. Having said
 that, it would be good to first hear evidence about how many resolvers take
 the unsigned root glue on faith versus how many chase down the names
 themselves. If there is only a small percentage who use the unsigned root
 glue, adding a new zone signature RR would seem awfully heavy-weight. (I
 say that as someone who has already done a design for the RR and presented
 it as a possibly-useful idea; I'm now not convinced it is worth the effort.)


The problem with chasing down the names is that the names are not in signed
zones (root-servers.net for example, but many TLD's name server names are
in unsigned zones.) I was surprised to learn this, and back when there were
only a few hundred TLDs, had trouble finding TLDs whose name server names
*were* in signed zones.

Maybe the issue is moot, if the AXFR sources are configured by IP address
rather than name, and don't factor into the attack surface. The downside
is, if there is a need to change the AXFR IP address, presuming a large
installed base, how would that happen?

On the other hand, if AXFR addresses are looked up in DNS, it becomes a
capture issue. If an attacker manages to poison the cache of the
operator, the attacker can capture the AXFR itself and provide a modified
root zone with good signed data but bad glue data. This becomes an
undetectable and unrecoverable situation.

The use of a zone signature would protect against this, for comparatively
low cost.




  - Given the lack of the big red button, this would be a good time to
 introduce the ability to opt-in to a NOTIFY registry, so that
 appropriately validated notifications could be sent by a root-zone operator
 (from whom the root-loopback operator does AXFRs)

 It might be, but that certainly would not go in this document. Still, I
 don't see the need for this if the root-loopback operator is checking for
 updates at a reasonable rate. The next draft will have a note about the
 history of root zone updates.


Ah, rIght, there could be a big difference between RR TTLs and SOA REFRESH.
I was thinking of the former, not the latter.



  - I'd also suggest adding something like a sentinel query for SOA
 Serial Number be made at REFRESH intervals to randomly-selected root
 servers. If the SOA Serial Number is stale for REFRESH + RETRY, it may be
 safer to go SERVFAIL at that point rather than waiting for EXPIRE. (The
 stale zone might still want to be used if all other root servers become
 unreachable, so don't delete the zone, just prefer not to use it.)

 What does safer mean here? If the folks who create the root zone (or any
 zone, for that matter) want people to expire sooner, they should change the
 value of the EXPIRE field: they shouldn't rely on us second-guessing them.


For most current situations, any zone which is being served by a
secondary/slave (including the root zone), normally is done with the
knowledge and intent of the zone owner/operator, and (at least for best
practices) is monitored by the zone operator. As such, it is generally a
rare event for EXPIRE to take effect, at least anecdotally speaking.

The root-loopback draft changes the operation of the root zone instances
from all managed by one of the root operators to loosely managed by
resolver operators. The benefits of having local root zones may be
compelling, but IMHO the implementation of this may require more cautious
approaches to boundary conditions. Fail safe, to put it in simple terms.

Safer means, This should never happen, and if it does, something
extremely odd has happened. If the SOA serial is consistently behind some
other reference SOA serial source, it means that either the zone updates
have been failing, or the upstream masters are themselves stale. Without an
additional master from whom to [AI]XFR, this is an error condition for
which there is no available solution via established mechanisms.

Ideally, the root-loopback host should be configured to AXFR from any/all
root servers, which I think makes the scenario impossible. If the host only
does AXFR from a subset of (or only one of) the root servers, the scenario
goes from impossible to possible (regardless of how likely, or via what
chain of events).

Basically, if the SOA serial has changed, but we aren't using the new copy
of the zone (i.e. our copy's serial is older), then by definition we are
using a stale copy of the zone. At that point, the only way to get
non-stale answers is to query something other than the local
(root-loopback) root servers.

I'm suggesting that how this error condition is handled, might

[DNSOP] Fwd: Comments on draft-ietf-dnsop-cookies

[Brian Dickson]

I'm a big fan of these cookies, and have been waiting eagerly for the draft
to finally get picked up.

These comments are meant to be constructive, and with the goal of improving
the draft quality and/or quality of the underlying protocol.

And, of course, I speak only for myself.

In no particular order:
- Attacks/weaknesses of DNS protocol: I think it would be very helpful to
add a subsection to either Section 2 or Section 3, concerning UDP
fragmentation, and how currently all anti-spoofing protections (vs off-path
attackers) are found in only the UDP header, DNS message header, and
question section. Adding extra text concerning the EDSN(0) flexibility of
OPT RR placement inside the Additional section, means it is probably also
RECOMMENDED that the OPT RR (containing the DNS cookies) be placed at the
end of the Additional section. This provides a much stronger defense
against spoofing, by requiring the attacker to have the correct DNS cookies
to poison a cache which implements cookies.

- It may be worth including an analysis of the overhead of cookies in
various states, and the comparative costs of cookies vs TCP.  For instance,
once the client and server have established mutual cookies, the cost of
validating cookies becomes the cost of looking up a cookie via a hash
table, and a cmp() operation. Keeping one old server cookie in addition to
the current server cookie, would further reduce the overhead in cases where
secret rollover has occurred. (If any value of BADCOOKIE other than the
most recent server cookie is seen, IMHO it would be fair to discard the
query silently, or do a minimum response WITHOUT a valid server cookie.)

- It may also be worth pointing out that there is an additional benefit to
clients in protecting themselves against arbitrary DDOS spoofing of
authority server(s), by being able to white-list cookie-enabled authority
servers, and to enforce the presence of cookies from those servers, and
even to also statically add cookie values to the server white-lists (with
fall-through logic for cookie mismatches, of course). Specifically, this
attack vector appears to the victim as if it is an amplification attack,
but in actuality bypasses the authority-as-amplifier, with packets sent
directly from a bot-net to the victim, spoofing the authority servers'
source address(es).

- It may be worth explicitly making the distinction between black-listing
IP addresses and filtering based on cookies. Both are effective at blocking
DDOS traffic, but only cookies facilitate valid traffic flowing while
attack traffic is blocked. Maybe something in an Appendix?

Hope this is helpful.

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

[DNSOP] Fwd: Comments on draft-ietf-dnsop-qname-minimisation

[Brian Dickson]

I'm a big fan of this.

These comments are meant to be constructive, and with the goal of improving
the draft quality and/or quality of the underlying protocol.

And, of course, I speak only for myself.

In no particular order:

- In section 3, it might be good to add a paragraph about the implications
for HAMMER. Specifically, in addition to pre-fetching records that would
otherwise expire, it is probably worth probing for the introduction of zone
cuts where none previously existed (i.e. confirm their continued absence,
or discover them.)

- Another comment for Section 4 (other advantages), it may be worth
mentioning improved look-up performance for TLD operators, which offsets
the loss of query data. A 2-label QNAME query is optimal for finding the
delegation owner name in a delegation-only TLD.

- Another thing to possibly call out is the behavior of some name servers
when the QNAME is an Empty Non-Terminal, e.g. a non-zone-cut with a child,
but no RRs at the owner name. I seem to recall something along those lines
but don't recall details, e.g. which software, version, etc., has this
issue.

Hope this is helpful.

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

[DNSOP] Fwd: Comments on draft-ietf-dnsop-root-loopback

[Brian Dickson]

I like the idea generally, and mostly have concerns about what can go
wrong, and possible missed opportunities in the operational realm.

These comments are meant to be constructive, and with the goal of improving
the draft quality and/or quality of the underlying protocol.

And, of course, I speak only for myself.

In no particular order:

- Given the unsigned nature of the glue in the zone, and the importance of
root glue, it might be the right time to also introduce a zone signature
RR, signed by the ZSK.

- Given the lack of the big red button, this would be a good time to
introduce the ability to opt-in to a NOTIFY registry, so that
appropriately validated notifications could be sent by a root-zone operator
(from whom the root-loopback operator does AXFRs)

- I'd also suggest adding something like a sentinel query for SOA Serial
Number be made at REFRESH intervals to randomly-selected root servers. If
the SOA Serial Number is stale for REFRESH + RETRY, it may be safer to go
SERVFAIL at that point rather than waiting for EXPIRE. (The stale zone
might still want to be used if all other root servers become unreachable,
so don't delete the zone, just prefer not to use it.)

Hope this is helpful. Feel free to ignore anything viewed as controversial
or unlikely to gain consensus.

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

Re: [DNSOP] Spartacus and new record types

[Brian Dickson]

IIRC, there is support for generic-named types similar to BIND's record
type name/number thing.

The RRTYPE would be a given a name which is something like rrtype,
and numeric value associated with the name, which is .

The RDATA would be encoded as a specified-length base-64 encoded binary
blob.

The RDATALEN specifies the length of the RDATA.

As to maintaining the specification, given that this is a -00 version, it
might need to be clarified.

I think that this would best be handled in an IANA registry, on the basis
of the existing registered DNS types, names, etc.

I think there is perhaps a need to specify how to craft the entries in that
registry.

Long-term, it may be better to include the encoding as table entries for
the DNS types, as first-class citizen(s) within those other registry
entries.

All of this is flexible.

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

Re: [DNSOP] Spartacus and new record types

[Brian Dickson]

Sent from my iPhone

 On Nov 12, 2014, at 1:26 PM, Mark Andrews ma...@isc.org wrote:
 
 
 In message 
 cah1iciqxwowao8nm8k-x47qiwawery9+etuefygzfn3aj5w...@mail.gmail.com, Brian 
 Dickson writes:
 
 IIRC, there is support for generic-named types similar to BIND's record
 type name/number thing.
 
 It is RFC3597 format not BIND's record name/number thing.

Yes, but I believe bind implements said RFC. (Incorporate by reference.)

 
 The RRTYPE would be a given a name which is something like rrtype,
 and numeric value associated with the name, which is .
 
 TYPE is reserved for all  [0..65535].  Why reinvent the wheel?

Note the word like. Wheel not reinvented. TYPE is used.

 
 The RDATA would be encoded as a specified-length base-64 encoded binary
 blob.
 
 Why switch to base64 rather than continuing with hex?

It may indeed be hex. No objection to use of hex, hex it is.

 
 The RDATALEN specifies the length of the RDATA.
 
 As to maintaining the specification, given that this is a -00 version, it
 might need to be clarified.
 
 I think that this would best be handled in an IANA registry, on the basis
 of the existing registered DNS types, names, etc.
 
 I think there is perhaps a need to specify how to craft the entries in that
 registry.
 
 Long-term, it may be better to include the encoding as table entries for
 the DNS types, as first-class citizen(s) within those other registry
 entries.
 
 All of this is flexible.
 
 Brian
 -- 
 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

Re: [DNSOP] Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia (circleid)

[Brian Dickson]

Paul Vixie wrote:

 because right now the people who do this have to pirate the address space
 of root name servers, and they have to do it for all of our addresses.
 under this proposal, there would be no piracy required, and there would
 only be two address blocks per stack (two for v4, two for v6) to do it for.


Actually, I don't believe this is the case.

Here's why:
- the root servers are authoritative for root-servers.net
- root-servers.net is unsigned
- the root zone is signed
- the glue for the root zone (like all other glue) is not signed (or even
signable)

So, alternate root zone hints files, and alternate versions of root zones,
can be created and served, with only the NAMES of the root servers signed,
protected, and unmutable.

The addresses associated with those names ( [a-m].root-servers.net ) are
replaceable in a way which is undetectable and unprotected by DNSSEC.

Thus, there is no need to hijack BGP routes. There is not even a
requirement that 13 unique addresses be used. The same single address could
be served up for all 13 entries (as glue data).

In that respect, arguably the proposal is kind of moot.

(On the other hand, I think this demonstrates the weakness of not pushing
for splitting the original NS into two different RR types (parent NS and
child NS), and making the authority for each the respective owner, and
having the owners signing them.)

I'd prefer to live in a world where BGP hijacking WAS necessary, and where
the root server addresses were signed, authoritatively served from within
the root zone directly (with no delegations).

E.g. change the names of the root servers to literally a. through m.,
and being in the root zone itself, have signed A/ records served
(either in response to queries for their addresses, or as Additional data
with signatures when DO is set).

Any chance of that happening, in this century?

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

Re: [DNSOP] Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia (circleid)

[Brian Dickson]

On Mon, Nov 10, 2014 at 7:16 PM, Ralf Weber d...@fl1ger.de wrote:

 Moin!

  On 10 Nov 2014, at 16:49, Brian Dickson brian.peter.dick...@gmail.com
 wrote:
 
  The addresses associated with those names ( [a-m].root-servers.net )
 are replaceable in a way which is undetectable and unprotected by DNSSEC.
 


 With DNSSEC any modification (malicious or not) can be detected so the
 actual packet origin doesn't matter. The data origin/authenticity is what
 we care about.


This is true ONLY for DNSSEC-protected data, and then only to the degree
that confidentiality is not an issue.

For example, by substituting the address glue for the root servers, an
attacker could then MitM all subsequent DNS traffic, by providing
delegation glue for nameservers that point at (other) attacker-controlled
machines. At a minimum, the attacker would see all the DNS queries and
answers. And, for any names not DNSSEC-protected, the attacker could then
trivially supply forged answers.

Given the relatively low penetration rate in sizeable portions of the
namespace, this is indeed something worth worrying about.

And, it helps give motivation for removing any and all impediments to wide
deployment of DNSSEC, on resolvers, clients, and
registrants/registrars/registries.

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

Re: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

[Brian Dickson]

TL;DR

As Tony Finch observed, the benefit is only seen when SEP failures occur,
most often in key-rolls. I'd argue that the vast majority of observed
DNSSEC failures have been of the key-roll (or initial set-up) variety with
mismatches between DS and DNSKEY, but otherwise properly signed (by ZSK)
zones.

Also, my assumption about what is needed to fix this (beyond NTA) was
WRONG. :-)
(It is amazing what you learn by setting up test cases and observing
behavior. Also, delv rocks.)

The good news is, for most cases, setting up a DLV-based fix can be done,
with only the DNSKEY(KSK).
I.e. modifying responses is not required AT ALL, and no new DNSKEYs or
signatures are needed.

(Please ignore my previous responses.)

Long version:

In order to assist validating forwarders, broken DNSSEC zones can be
repaired using DLV, and ONLY DLV.

Take the result of dnssec-dsfromkey for the apex KSK, append the DLV
domain name to the owner names.
Insert into the DLV zone, sign, bazinga. Use of this DLV, with the modified
suite of bind tools, securely resolves.

As currently implemented in BIND-9.10.1, a modification is needed to
lib/dns/validator.c.
The good news is, it is a one-line change.
Basically, it changes the logic, if no DS-DNSKEY validated match can be
made, to fall through to use DLV.

(In the current logic, DLV is only queried if no DS exists above a secure
zone, from a secure zone. The change extends the logic to make this no
VALID DS instead of no DS.)

No changes to the answers served by a resolver (who is the target of
forwarders) are required.

There is not even a requirement that the NTA resolver operator be the
operator of the fix-up DLV.

Given the relative rarity of DNSSEC failures which do not get fixed quickly
enough relative to their perceived value, it may be worth asking for
volunteers to run one (or more) centralized fix-up DLV instances.

So, other than the operational implications to downstream validators of
NTA-implementing resolvers, it may be sufficient to add the observation
regarding DLV as a possible way of fixing broken DS-DNSKEY (on a
third-party basis) as a sub-paragraph.

Hope this helps, and is worth consideration for addition to the draft.

Suggested text and location: New paragraph just before the last paragraph
of section 8:

In addition to configuring a Negative Trust Anchor, implementors MAY choose
to also

implement a DNSSEC Lookaside Validator (DLV) zone, containing appropriate
DNSSEC
material to provide an alternative Secure Entry Point (SEP) into affected
zones.

Individual DLV records consistent with apex KSK records at the
corresponding DLV name,
when referenced by validating resolvers (and/or forwarders), permit DNSSEC
validation
of the affected zone(s). Such DLV registries may be operated by NTA
implementors,
or by other (presumably trustworthy) parties.


(If anyone wants a suite of test zones demonstrating the before/after
behavior, I am more than happy to provide them. Perhaps they would be
useful in another Appendix?)

Brian Dickson

The patch needed for 9.10.1 (which may work on other bind branches) is as
follows:

*diff --git a/lib/dns/validator.c b/lib/dns/validator.c*

*index 88bfaef..31e9425 100644*

*--- a/lib/dns/validator.c*

*+++ b/lib/dns/validator.c*

@@ -2274,7 +2274,8 @@ validatezonekey(dns_validator_t *val) {

} else {

validator_log(val, ISC_LOG_INFO,

  no valid signature found (DS));

-   return (DNS_R_NOVALIDSIG);

+   return (startfinddlvsep(val, val-event-name));

+   /* WAS return (DNS_R_NOVALIDSIG); */

}

 }

On Sat, Nov 1, 2014 at 8:30 PM, Brian Dickson brian.peter.dick...@gmail.com
 wrote:



 Sent from my iPhone

  On Nov 1, 2014, at 4:30 PM, Warren Kumari war...@kumari.net wrote:
 
  On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson
  brian.peter.dick...@gmail.com wrote:
  I think it is good to minimize disruption caused by broken DNSSEC
 domains,
  for all the reasons listed in the document.
 
  However, I also believe there is a second-order negative effect of
  implementing NTAs as described.
 
  Validating stub resolvers and validating forwarding resolvers, will
 still
  break.
 
  Yup. This is a feature, not a bug.
 
  NTA only makes the local / ISP resolver not perform validation for
  the domain. Anyone downstream who is doing validation will still
  perform the validation, and this will fail -- this is, IMO, the right
  thing to have happen.
  Downstream validators are presumably a: more security conscious and b:
  more able to troubleshoot DNS issues than my auntie.

 There is subtlety in using DLV instances.

 On the one hand, passing along answers that have known DNSSEC validation
 problems avoids blocking your auntie.

 On the other hand, if it is known to have problems, stitching things up in
 ways that still don't validate without use of DLV isn't really any worse.

 And on the gripping hand, adding the fix in DLV, for only those who

Re: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

[Brian Dickson]

Sent from my iPhone

 On Nov 1, 2014, at 4:30 PM, Warren Kumari war...@kumari.net wrote:
 
 On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson
 brian.peter.dick...@gmail.com wrote:
 I think it is good to minimize disruption caused by broken DNSSEC domains,
 for all the reasons listed in the document.
 
 However, I also believe there is a second-order negative effect of
 implementing NTAs as described.
 
 Validating stub resolvers and validating forwarding resolvers, will still
 break.
 
 Yup. This is a feature, not a bug.
 
 NTA only makes the local / ISP resolver not perform validation for
 the domain. Anyone downstream who is doing validation will still
 perform the validation, and this will fail -- this is, IMO, the right
 thing to have happen.
 Downstream validators are presumably a: more security conscious and b:
 more able to troubleshoot DNS issues than my auntie.

There is subtlety in using DLV instances.

On the one hand, passing along answers that have known DNSSEC validation 
problems avoids blocking your auntie.

On the other hand, if it is known to have problems, stitching things up in ways 
that still don't validate without use of DLV isn't really any worse.

And on the gripping hand, adding the fix in DLV, for only those who have 
configured that specific DLV, means those clients are able to validate.

Furthermore, those doing advanced level DNS operations are unlikely to use NTA 
implementer services.

And, IMHO, advanced operators could signal a desire for unmodified answers the 
traditional way, via the CD bit.

Adding the DLV function provides a scaling benefit in terms of how many 
validating forwarders need to make the NTA mod to resolve the affected domain. 
Without DLV, there is still an incentive to turn off validation -- which is 
what NTA is explicitly trying to prevent.

Having forwarders validate should be something we all encourage and support, 
especially in this sort of document.

I definitely think it is up to each operator as to whether they do this.

However, I would like this to be included in the draft as an optional aspect of 
setting up NTAs, so that operators can evaluate the pros and cons, and make 
informed choices.

Brian

 
 There is a big difference between handing back an answer as though you
 are not a validator (the NTA), and signing someone else's answer.
 
 W
 
 I do have a suggestion, which I hope is worth exploring and considering.
 
 For anyone using an open, well-known resolver (either provided by their ISP,
 or operated as a public service), include instructions on use of a
 provider-specific DLV and provider-specific alternative trust anchor
 (DNSKEY).
 
 Whenever it is necessary to over-ride broken DNSSEC zones, most likely on
 the Secure Entry Point, do the following:
 (1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK for
 all such instances, and publish the public DNSKEY used.
 (2) Sign the apex DNSKEY RRset with this new KSK
 (3) Add this KSK into the DLV operated by the resolver operator at the
 appropriate location. For example, if example.com is broken, put the KSK at
 example.com.dlv.example.net, if the operator of the public resolver is
 example.net.
 (4) Observe successful validation of example.com by anyone configured to use
 dlv.example.net as their DLV.
 
 I haven't tried this, and there might be some specific modifications to what
 I described needed to make the configuration correct/functional. I don't
 believe it introduces new insecurities to anyone who already has placed
 trust in the resolver at example.net.
 (Is it the case that things that use DLV validate the chain of trust to the
 DLV itself, from the root, if there is not a separate trust anchor for the
 DLV zone? That would be optimal, security-wise, I believe.)
 
 Thoughts?
 
 Brian Dickson
 
 
 
 -- 
 I don't think the execution is relevant when it was obviously a bad
 idea in the first place.
 This is like putting rabid weasels in your pants, and later expressing
 regret at having chosen those particular rabid weasels and that pair
 of pants.
   ---maf

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

[DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

[Brian Dickson]

I think it is good to minimize disruption caused by broken DNSSEC domains,
for all the reasons listed in the document.

However, I also believe there is a second-order negative effect of
implementing NTAs as described.

Validating stub resolvers and validating forwarding resolvers, will still
break.

I do have a suggestion, which I hope is worth exploring and considering.

For anyone using an open, well-known resolver (either provided by their
ISP, or operated as a public service), include instructions on use of a
provider-specific DLV and provider-specific alternative trust anchor
(DNSKEY).

Whenever it is necessary to over-ride broken DNSSEC zones, most likely on
the Secure Entry Point, do the following:
(1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK
for all such instances, and publish the public DNSKEY used.
(2) Sign the apex DNSKEY RRset with this new KSK
(3) Add this KSK into the DLV operated by the resolver operator at the
appropriate location. For example, if example.com is broken, put the KSK at
example.com.dlv.example.net, if the operator of the public resolver is
example.net.
(4) Observe successful validation of example.com by anyone configured to
use dlv.example.net as their DLV.

I haven't tried this, and there might be some specific modifications to
what I described needed to make the configuration correct/functional. I
don't believe it introduces new insecurities to anyone who already has
placed trust in the resolver at example.net.
(Is it the case that things that use DLV validate the chain of trust to the
DLV itself, from the root, if there is not a separate trust anchor for the
DLV zone? That would be optimal, security-wise, I believe.)

Thoughts?

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

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

[Brian Dickson]

 TL;DR tidbit: IF the combined authority+resolver case (when switching
ISP hosting companies) is not handled  by the QNAME minimization draft,
IMHO it should consider adding it. It is a real-world problem edge-case
seen frequently.


 On Tue, Oct 07, 2014 at 12:04:22AM -0400, Tim Wicinski wrote:
  Please review this draft to see if you think it is suitable for adoption
  by DNSOP, and comments to the list, clearly stating your view.
 I do not support accepting the draft (or the proposal it carries) as a
 work item.
 Other than the author - and obviously others - I believe that the
 resolution
 algorithm of RFC 1034 is pretty clear about the QNAME being sent in full
 and that has been operational reality for 25+ years.  A whole system has
 been successfully built around it with complex interdependencies.
 'parent centric' and 'child centric' resolvers and query patterns
 evolved along that algorithm.  The fact that certain services may have
 experimented
 (successfully, to them) with the proposed algorithm already gives anecdotal
 evidence at most, but no evidence for the absence of harm.
 Making the zone cut, an otherwise arbitrary boundary, a central search
 element, is another huge paradigm shift that I see with great interest.
 Please don't anyone tell me that's the case with DNSSEC already - the story
 there is different.
 Finally, QNAME minimization is providing little gain in the traditional
 forward tree and already needs kludges in deeper, nested name spaces.
 Comparing the (little) gain with the unclear risk, I'd rather see work and
 energy devoted to a long term solution.
 -Peter


There are two places where there is potential impact, by definition:
- recursive resolvers
- authority servers

The case for recursive resolvers is plain: any QUERY below an NXDOMAIN
can avoid querying the parental unit of the original NXDOMAIN.
The problem being solved is DOS of recursive resolvers.

The argument implicit in Peter's message is, there is little or no gain on
the
authority server side.

I would like to illustrate one example case which, however rarely it occurs,
can be made moot by QNAME minimization.

Here is an example case in bullet form, showing delegations and a change.

example.com is administered by one department, and delegates administration
of other departments to their respective nameservers. The group that does
the administration of example.com is a sub-department of one of the
delegates.

Now imagine that the sub-department migrates its own zone from the shared
nameserver of example.com, to its own separate nameserver. In doing so,
imagine an error is made - the zone in question is not removed from the
example.com nameserver. (It is like a lame delegation only in reverse.)

Nomenclature for the example: X:Y means server X hosts zone Y.
Before:
X:example.com - Y:foo.example.com - X:bar.foo.example.com
After:
X:example.com - Y:foo.example.com - Z:bar.foo.example.com
(but X:bar.foo.example.com still exists).

No QNAME minimization: Querying X for www.bar.foo.example.com
returns the values on X, instead of the values on Z. Admins looking
at servers Y and Z fail to see why this is occurring.

QNAME minimization: Querying X for www.bar.foo.example.com
gives delegation to Y, etc., eventually returning values from Z.
The presence of the undelegated instance on X never causes problems.

This might happen rarely in Academic institutions, but is more likely to
happen
when a ETLD registrant changes hosting providers/ISPs, and where the old
hosting provider/ISP does not follow BCP, and combines authoritative service
and resolution on the same DNS servers. Old (and now undelegated) zone
data gets served.

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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-spartacus-lang-00.txt

[Brian Dickson]

Hi,

I have posted two new IDs, one for a DNS description language, the other
for a DNS-JSON-DNS system,
designed to be operated either as a bridge, or as a transparent proxy.

I'm hoping for some initial feedback, including whether either/both belong
in DNSOP.

Thanks,
Brian DIckson
-- Forwarded message --
From: internet-dra...@ietf.org
Date: Wed, Oct 15, 2014 at 6:10 PM
Subject: New Version Notification for
draft-dickson-dnsop-spartacus-lang-00.txt
To: Brian Dickson brian.peter.dick...@gmail.com



A new version of I-D, draft-dickson-dnsop-spartacus-lang-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-spartacus-lang
Revision:   00
Title:  A Language to Describe the DNS Wire Format
Document date:  2014-10-15
Group:  Individual Submission
Pages:  23
URL:
http://www.ietf.org/internet-drafts/draft-dickson-dnsop-spartacus-lang-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-spartacus-lang/
Htmlized:
http://tools.ietf.org/html/draft-dickson-dnsop-spartacus-lang-00


Abstract:
   As part of the SPARTACUS DNS gateway system, building a full DNS
   parser was necessary.  Parsing DNS packets is the only way to avoid
   propogating packets which are not correctly formatted DNS packets.

   In order to facilitate building a new parser from scratch, the author
   chose to build a parser-builder which takes as input, a description
   of the DNS wire format.

   This document describes the language created to facilitate this
   description, and includes the resulting DNS wire format description
   in this language.




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] Fwd: New Version Notification for draft-dickson-dnsop-spartacus-system-00.txt

[Brian Dickson]

Hi,
This is the second of the pair of drafts submitted together for
consideration.
(See the first post for the full description.)
Brian Dickson
-- Forwarded message --
From: internet-dra...@ietf.org
Date: Wed, Oct 15, 2014 at 6:11 PM
Subject: New Version Notification for
draft-dickson-dnsop-spartacus-system-00.txt
To: Brian Dickson brian.peter.dick...@gmail.com



A new version of I-D, draft-dickson-dnsop-spartacus-system-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-spartacus-system
Revision:   00
Title:  System to transport DNS over HTTP using JSON
Document date:  2014-10-15
Group:  Individual Submission
Pages:  34
URL:
http://www.ietf.org/internet-drafts/draft-dickson-dnsop-spartacus-system-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-spartacus-system/
Htmlized:
http://tools.ietf.org/html/draft-dickson-dnsop-spartacus-system-00


Abstract:
   This is the SPARTACUS DNS gateway system.  It is designed to
   facilitate the transport of DNS messages opaquely, across problematic
   sections of the Internet.  It uses JSON encoding, and HTTP(S) as the
   protocol for transport.

   The main criteria of SPARTACUS is that it preserve DNS messages
   verbatim, and that only properly formatted DNS messages are passed.

   There are two modes (so far) defined: DNS forwarder (dns clients
   point to a local gateway, which forwards to a remote gateway for
   sending to a DNS resolver); and transparent proxy (DNS packets are
   intercepted, passed to a local gateway, which sends them to the
   remote gateway, with original destination IP address etc. encoded,
   and used by the remote gateway as the destination).

   DNS messages are NAT-friendly, so changes to IP or UDP headers do not
   impact them.  Thus, SPARTACUS does not interfere with TSIG, SIG(0),
   or Eastlake Cookies.

   This document describes the system, the components, and behavior,
   with examples.




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] [dnsext] [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document

[Brian Dickson]

I'm not sure where it would belong, exactly, but certainly between
best practices and DNSSEC security concerns, is the basic tenet:

The DNS is a unified namespace.

This leads to a number of potential issues, which can largely be
addressed by viewing the issues from the perspective of a unified
name-space's root. And by providing lots of literal and explicit
examples.

E.g.:
- It is recommended that use of private namespaces be restricted to
subdomains of legitimately-assigned domains by the domain owner
exclusively (e.g. .private.example.com. and NOT .private.)
- It is recommended that unofficial namespaces be avoided where
practical to do so (e.g. .local, .fake-domain, .TBD)
- It is recommended that any and all domain names be anchored with a
trailing . when expressed in text form, regardless of scope
(global/private, bare TLD or otherwise) to remove any possible
ambiguity (e.g. .example.com., NOT .example.com which might
suggest use of search lists)
- It is recommended that inconsistent or conflicting namespace or
contents be avoided (e.g. split DNS with same labels having different
RVALUEs) (possibly handled by non-anchored names and search lists,
which result in unambigous names upon expansion)
- It is recommended that handling of restricting access to private
namespaces be handled in a manner that does not induce look-up
failures if the wrong nameserver is consulted first (e.g. ISP/global
before VPN/private, have .private.example.com. return something
OTHER than NXDOMAIN, e.g. servfail or whatever anyone smarter than me
suggests)
- It is recommended that configured Trust Anchors (for private
namespaces) and learned Trust Anchors (KSK or ZSK of securely
delegated zones) be handled in a manner compatible with any usage of
split DNS (so that signature validation is deterministic)
- It is recommended that private namespaces underneath secure global
namespaces be DNSSEC-protected with either a global learned Trust
Anchor, or a configured Trust Anchor
- It is recommended that private namespaces be DNSSEC-protected where
practical to do so

The above is just off the top of my head as possible text that could
be used. Comments on style, content, etc., are more than welcome.

Brian

On Wed, Oct 19, 2011 at 1:58 PM,  teemu.savolai...@nokia.com wrote:
 Ted, thank you for comments.

 Please feel free to propose text - I love constructive text proposals:-)
 During following week would be nice, if possible, so that we can move
 forward with the draft before the next IETF.

 Now that you say it, we might state that not any VPN can be trusted by
 default (but VPN is an example here), but e.g. a VPN Configuration Profile
 could enable the setting for that particular VPN connection. If the trusted
 VPN then **cks you up, then, well, trusted parties sometimes do that..

 Best regards,

        Teemu

 -Original Message-
 From: ext Ted Lemon [mailto:ted.le...@nominum.com]
 Sent: 19. lokakuuta 2011 19:07
 To: Savolainen Teemu (Nokia-CTO/Tampere)
 Cc: Hui Deng; m...@ietf.org; dnsext List; dnsop@ietf.org WG; DHC WG;
 sa.morr...@googlemail.com; p...@isoc.de
 Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection
 document

 The DHCP changes look good.  You can get multiple selection tuples in
 DHCPv4 if you want, but you seem to have decided its not important, which
 is fine by me.   Let me know if you want me to explain how to do that.

 However, I reread the text on server selection, and it still has a serious
 and
 easily exploited security flaw.   In order for DNSSEC validation to save
 you
 from an attack, it has to be the case that you look the name up on every
 possible name server to see if any claim it's in a signed zone.   If one
 does, it
 has to be validated.   Right now it looks like if the trusted server
 doesn't
 sign the zone, the DNSSEC validation will never happen.   We dealt with
 this
 by trusting some networks more than others, and that eliminates a lot of
 the
 risk.

 For example, in the case of a hotel net we're okay, because it will be
 less
 trusted than the 3G network.   The case I am most concerned with is when
 you VPN to a site that is not trusted: the default behavior will be to
 prefer
 the VPN link, because we presume it is more trustworthy.  A consultant who
 VPNs to multiple corporate sites could be spoofed here though, as could a
 user of a firewall bypass VPN.

 Unfortunately, I don't know of a way to fix this that doesn't fire up both
 radios for every query.   Leaving this off by default is probably the best
 we
 can do, but it might be good to add more text to the security
 considerations
 section describing specific exploit scenarios.   The text in 10.1 and 10.2
 doesn't address this particular attack vector.

 I would propose adding a requirement that there be a mode, off by default,
 enabled by UI, in which the resolver just fires up both radios, battery be
 damned, but I am not sure anyone would use it, because it would be
 difficult
 to explain why and 

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

[Brian Dickson]

I think we can skirt this rat-hole if we separate the two following
distinct cases:

Case A: foo
Case B: foo. (with terminating dot).

Case B meets the technical requirements of a Fully Qualified Domain
Name, structurally speaking.
Case A does not.

Case A is a bare name, case B is not.

If we stick to the notions of FQDN versus anything else, we can avoid
entering the rat-hole, IMHO.

(I.e., We don't need to get into any issues over the number of labels
in an FQDN; an FQDN does not require treatment, special or otherwise;
etc., etc.,)

Brian Dickson

On Thu, Oct 20, 2011 at 9:38 PM, Keith Moore mo...@network-heretics.com wrote:

 On Oct 20, 2011, at 9:19 PM, David Conrad wrote:

 On Oct 20, 2011, at 6:07 PM, Keith Moore wrote:
 It might that IETF should consider bare names out of its scope, except 
 perhaps to say that they're not DNS names, they don't have to necessarily 
 be mappable to DNS names, and that their use and behavior is host and 
 application-dependent.

 Can we please not redefine what a DNS name is to meet a particular agenda?

 I wasn't trying to do so.

 Isn't it sufficient to say a 'bare name' does not conform to a hostname as 
 defined in RFC 952 and modified by RFCs 1122?

 Probably.  I'm just suggesting that trying to nail down the behavior of such 
 names is probably a rathole as well as likely to cause significant disruption.

 ___
 dnsext mailing list
 dns...@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsext

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

[DNSOP] Time vs bootstrap (was Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00)

[Brian Dickson]

Top-replying here, to attempt a high-level suggestion on how to get
some close approximation of time, using DNS/DNSSEC exclusively.

(Warning to those with weak stomachs - this is mildly evil stuff.)

First, without any assurances on the accuracy of local time, the best
that can be achieved regarding bootstrap-to-trust-anchor is
consistency validation.
Having multiple ways to validate the consistency of answers received
over DNSSEC, can create a high degree of confidence in the validity of
the root key, but cannot get to 100% (I don't think, anyway).

However, once you have a trust anchor (root key) that you have a lot
of confidence in, you can then do some cute DNSSEC tricks to get a
rough idea of time, and then a better idea of time.

First, look at the contents of the RRSIGs for the root. If you believe
the RRSIGs, you also necessarily believe that the current time must be
within the start/end time of those RRSIGs.

That might not be close enough for your needs, but may be enough to
further validate the root key. (If it is, validate it before
continuing.)

Next, consider what needs to happen for TLDs that update very frequently.
When they update, their SOA SN needs to change.
And, if they are signed zones, the SOA record's RRSIG needs to be
generated when this happens.
Using the start date/time of such an RRSIG on the SOA for such a zone,
should give a pretty good value for the current time, to at least an
accuracy of a couple of minutes.
This may be good enough for DNSSEC purposes.

(If you do use RRSIG timestamps, be sure to validate the RRSIG first
before trusting the values on the timestamp!!!)

While horribly kludgey and mildly evil, it does get an answer that is
reasonably trustworthy, moderately accurate/precise, and only uses
DNSSEC.

(It borrows the main idea from using GPS for clock as well as position.)

Brian

On Mon, Jan 31, 2011 at 5:44 PM, John Bashinski jb...@cisco.com wrote:
 On 2011-01-31 14:32, Joe Abley wrote:


 Time
 

 3.1 Initial State
 [...]
 A validator must confirm that its local clock is sufficiently
 accurate before trust anchors can be established, and before
 processing of DNSSEC signatures can proceed.  Discussion of timing
 considerations can be found in Section 4.

 How?

 I know I brought it up, but I'm getting a little nervous about using the
 home router as the only reference point. Nonetheless, it's a good
 paradigmatic case, and I'll go with it for now. You're a home
 router. You've just been plugged in, either new from the box or after
 being in a closet for a long time.


 The state of the art in enterprise networks is *unauthenticated* NTP
 with internal hosts. The state of the art in consumer is unauthenticated
 NTP with a pool on the public Internet.

 This is a huge problem for us with bootstrapping all kinds of crypto
 protocols, actually, not just DNSSEC. There's this pervasive assumption
 that the time of day is not only known, but known with such certainty
 that it can be trusted to ensure the security of systems that are
 otherwise engineered to take CPU-aeons to compromise. The problem is
 that it's just not an assumption we know how to meet.

 In a lot of cases, we just end up having to assume that keys are valid
 from the beginning of time to the end of time. I'd very much like to not
 have that be true, but I don't know how to fix it.

 I could imagine a distributed system of digital notaries and time
 stampers that at least let you establish that it was no earlier than
 some particular time, and that also gave you some assurance that some
 set of past events had happened in a particular sequence and within
 particular time parameters. You could build that with mutually
 distrustful authorities, and use a quorum or something to prevent any
 one of them from messing it up. I think that sort of thing is (part of)
 what Phillip Hallam-Baker is getting at. But I'm not sure we can deploy
 it sanely in time to be useful for this application... and I don't
 think you can build *anything* that lets you detect lies about the
 time if an attacker controls *all* your communications.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Cache poisoning on DNSSEC

[Brian Dickson]

Dean Anderson wrote:
 On Sun, 24 Aug 2008, Brian Dickson wrote:

   
 Dean Anderson wrote:
 
 On Sun, 24 Aug 2008, Dean Anderson wrote:

   
   
 Ok.  But when you resign using arbitrary data controlled by the
 attacker, the private key can be obtained. [There is a crypto attack on
 rekeying] OOPS!!.  Rekeying is out of the question for, say, .com, .net,
 etc.  I guess you didn't know that.
 
 
 Correction: The above should say there is a crypto attack on re-SIGNing.  
 ReKEYing is fine. Apologies for the confusion I just created.
   
   
 You say there is a crypto attack on re-signing.

 One using arbitrary data provided by the attacker - what is the 
 arbitrary data, as opposed to some other kind of data?
 

 I don't think I can give the exact correct mathematics without using a
 book--and I don't have my crypto library right now--so I'll try to
 armwave a bit:

 Basically, if the attacker can pick a known-plaintext that corresponds
 to a large-prime, they can use the result and the public key to obtain
 the private key. This is consequence of modular arithmetic.  I'm not
 entirely certain from memory if the plaintext has to be prime or if it
 can be a multiple of a prime.  

   

What Dean describes is a general attack on PKI math, not on 
(re-)signing as DNSSEC (RFC4034) specifies for RRSIG.

His theory is, if the attacker can arrange for the thing being signed to 
be a prime (or possibly even the product of two known primes),
then it may be possible to recover the key used for signing, based on 
the signature.

The question is, is it possible for an attacker to arrange for the thing 
being signed to be a prime, or some arbitrary value?

No.

There is no way to deterministically cause a known value to be used for 
what gets signed.

Here's why:

signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )

But: RRSIG_RDATA includes the expiry and incept date - chosen by the 
signer, not the attacker.

Even worse, the contents of RR(1) are a DS record, which is itself a 
digest of a DNSKEY record.
The DNSKEY record includes a few fields which are mostly 0's (7/8, 7/8, 
6/8 on three octets).
The DS may be provided by the operator of the subordinate zone, or built 
by the parent operator,
most likely the latter.

So, there are 20 bits of zeros which get used in a digest, and 64 bits 
not under the attackers control,
plus 16 bits of fixed value (Type Covered), an 8-bit fixed value field 
(Labels),  plus the Signer's
Name is also a fixed value. That's way more than 88 bits of data not 
under the control of the attacker.

For perspective, 2^88 is the number of seconds in the age of the 
universe, estimated. To suggest that
appending a digest value to that, and having the result be a prime, does 
not strike me as a serious
threat to key recovery by an attacker.

So, I would say that in all likelihood, re-signing with the *same* key 
is perfectly safe.

(The inclusion of the signature's own timestamp values in the data being 
signed was, IMHO, genius.)

Brian

P.S. This does not, however, mean that there does not exist some other 
key recovery risk; if anyone knows of one, please detail it or give a 
reference.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Cache poisoning on DNSSEC

[Brian Dickson]

[EMAIL PROTECTED] wrote:
 On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
   
 The DS may be provided by the operator of the subordinate zone, or built 
 by the parent operator,
 most likely the latter.
 


   thats an interesting premise.  
   why do you think this will be the case?
   
   (I would posit that the folks generating the DNSKEY will also 
   want to generate the DS hash on their known, trusted signing tools
   instead of trusting the parent w/ the DNSKEY materials)
   

Well, here's why:

- The DS is a deterministic function
- Having DS sent to the parent, rather than calculated locally by the 
parent, introduces a host of human and/or process risks/requirements
- The DS only needs to be built when the DNSKEY changes (key rollover)
- The parent is already trusted with DNSSEC tools, since the parent is 
signing the parent's zone (including the DS record!)
- Nothing in the DNSKEY, or in the building of the DS, involves private 
keys, only public keys - so there is no trust issue with the materials.
- The DNSKEY is already published, so the parent can trivially get it, 
in a way that is not subject to poisoning (the NS glue is hardcoded in 
the parent zone, after all)

It isn't something that seemed obvious until I looked at the signing 
stuff. If the DS is deterministic, why create an avenue for expoiting?

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

Re: [DNSOP] Cache poisoning on DNSSEC

[Brian Dickson]

David Ulevitch wrote:

Paul Vixie wrote:

no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.


If you have a malicious man in the middle, he will do bad things to you.

DNSSEC will not stop that.


Too many pronouns...

DNSSEC provides the ability to determine that a given authoritative 
answer is signed (by DS on the delegation from the parent),

and provides cryptographic signatures on such authoritative answers.

The signatures can be chased up to a configured trust anchor, ideally a 
signed root.
And without any private key in that chain of trust, he can't change 
signed authoritative data without causing validation to fail.


With apologies to Meat Loaf:

A Man in the middle can
bedevil your wits,
He can fiddle with packets,
he can twiddle the bits,
He can easily spoof your
sequence numbers and such,

But he can't spoof sigs,
No he can't do that.
Oh, no,
No, he can't do that.

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

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

[Brian Dickson]

bert hubert wrote:

On Mon, Aug 18, 2008 at 04:34:30PM +, Paul Vixie wrote:
  

and let's also make explicit that TCP is not to be used unless UDP returns
TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA.



This means disabling one of the more widely used MTAs.


Could you please elaborate on this? Which MTA, how does it use DNS, and 
is the way it uses it intractable?



It may require some work to beef up TCP support though,


The problem, I think, is TCP itself, not TCP support within 
implementations. E.g. resource limits per IP address (16 bits of port 
number) don't scale to current-size Internet scale.


So, short of dramatic changes to TCP that support better scalability and 
performance, it's kind of out of scope for DNS itself.


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

Re: [DNSOP] Services and top-level DNS names

[Brian Dickson]

Mark Andrews wrote:
names which do not terminate in . (and in some cases, which might not 
permit such name termination).


Consider the label foo.bar, a stub resolver, a recursive resolver, new 
TLD bar, and existing SLD example.com.



Partially qualified domains and search lists are always dangerous
unless you never use a partial name which matches a tld.
  


Exactly!

The problem is a who choses last problem.

Anyone who is using a partial name, which *then* becomes a new TLD, gets 
the surprise results.


And, as the new rules are likely to result in TLDs with more 
semantically meaningful values, there is greater

likelihood that such problems will appear.

Especially for TLDs with geographic significance. .asia was bad 
enough, but what if the various FAA airport codes

get used by the respective airport authorities as new TLDs?

How many operators have infrastructure naming schemes based on FAA 
codes? How much chaos might occur if new
TLDs like CHI, NYY, LAX, SEA, or YYZ come into existence? 
(Shudder).


That's precisely why it makes sense to think about the partial name 
problem, before big problems happen for lots of ISPs.


Brian

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

Re: [DNSOP] Fwd: New Version Notification

[Brian Dickson]

Paul Vixie wrote:

[EMAIL PROTECTED] (Phil Regnauld) writes:
  

Question: How do existing implementations react to the presence of a
single, terminal dot ?  What if an A record is published for '.' ?  I
know it probably won't happen. but I'm also curious to know, and I think
the document should specify this: what is the impact of this on existing
implementations ?



i'm afraid that this will just result in a lot of QTYPE A messages sent to
the authority servers for . asking about ., and a lot of new useless RCODE 3
responses therefrom.

  


Are you certain? (And does RCODE 3 mean, as I understand it, NXDOMAIN?)

I tried doing just such a query using dig, and got:

;  DiG 9.3.2  @f.root-servers.net A . +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 47975
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;.  IN  A

;; AUTHORITY SECTION:
.   86400   IN  SOA A.ROOT-SERVERS.NET. 
NSTLD.VERISIGN-GRS.COM. 2008062800 1800 900 604800 86400


;; Query time: 3 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Sat Jun 28 16:11:59 2008
;; MSG SIZE  rcvd: 92



i think it will not be correctly implemented, just as RFC 2136 was not
correctly implemented, and if people start putting SOA.MNAME=. then it
will just lead to a lot more QTYPE A queries for ..
  


Hypothetically speaking, if an actual answer for such a query were 
returned, would anything actually *use* the answer?


Again, hypothetically speaking, if an A RR were added for . , with a 
very long TTL, such as 8640, that would be cached ubiquitously, and 
reduce these queries at the root servers, right?


Again, hypothetically, what values for such an A RR would cause benign 
behaviour? E.g. 127.0.0.1?


Just thinking *way* outside the box

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

Re: [DNSOP] Fwd: New Version Notification

[Brian Dickson]

Paul Vixie wrote:

Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst
failures to send DNS UPDATE messages to root servers would not be cached?



the data at hand tells me that lots of people don't cache, and those who
do only cache positives.  but in principle, yes, if the hosts who aren't
following the spec regarding using SOA.MNAME as a selection criteria among
{NS.NSDNAME} happen not to be the same hosts who aren't caching negative
or empty results, then some good could come of this.


What about the behavior of (modern) caching resolvers, at start-up time, 
when they prime themselves based on the root hints file?


What do they query for, i.e. . with query type of any?

If that's the case, then such resolvers will already have the answer 
(empty though it may be), and no new traffic should be seen.


If I understand things correctly, that is, and some quick local tests I 
did seem to point to this behavior.


(Even trying to do dig +trace on the A of . seems to short-circuit 
locally, without querying any root servers.)


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

Re: [DNSOP] Why deny AXFR from root servers?

[Brian Dickson]

Dean Anderson wrote:

BTW, can you explain what these zones are?

XN--KGBECHTV. NS A.IANA-SERVERS.NET


Wow, an interesting, operationally pertinent question. It deserves mild 
praise and an answer.


See http://www.iana.org/reports/2007/testetal-report-01aug2007.html

(Things that start with xn-- are punycode. Google or any other search 
engine is your friend.)


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

Re: [DNSOP] Public Suffix List

[Brian Dickson]

Yngve Nysaeter Pettersen wrote:
 On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly [EMAIL PROTECTED]  
 wrote:

   
 On 12 Jun 2008, at 12:25, Gervase Markham wrote:

 
 The second question is one of resources and client complexity. I am
 meeting resistance to the idea of having the existing list regularly
 dynamically downloaded, which would be the simplest method of
 providing
 more frequent updates than the six-to-eight week Firefox security
 releases. An assemble-and-cache-the-data-from-DNS scheme would be an
 order of magnitude more complex.
   
  I'm not sure why you would need to assemble anything.
  Couldn't you seize the data you need, on demand, from
  the DNS (and cache at will).
 

 DNS, or full DNS, is not always available.

 There are at least two scenarios where this is the case:

   - Behind (very) closed firewalls, where all access go through a HTTP-only  
 proxy. No DNS for external addresses is available. For that matter, when  
 going through a proxy you have no way of knowing if the DNS available to  
 you know anything about the address space you are accessing through the  
 proxy.

   - On a number of systems, in particular phone devices, the application  
 does not even have access to DNS to do a name lookup, it must specify the  
 hostname, and try to connect.

   

A DNS-based solution does not *need* to be a DNS-*only* solution.

As I understand it, your list associates suffixes with true/false 
state, i.e. whether they are public or not.

Imagine a tree of subdomains, all of which exist only to provide 
true/false information, rooted at, say,
suffix-list.mozilla.org. If a given subdomain exists, true, otherwise 
false. And for http-only scenarios,
have each of these subdomains be a CNAME pointing a static web page, say 
true.suffix-lists.mozilla.org.,
which contains just the word True.

Both the content of the pages, and the DNS entries, could be cached in 
their respective systems
(web browser cache, or DNS resolver cache). Timeliness of updates would 
be maintained by appropriate
mechanisms to tell the querying agent to check again (HTTP tag or DNS TTL).

The HTTP side of things does not require a separate DNS client. But, the 
updates to the list can
be made trivially by manipulation of DNS data alone, and use of DNS 
involves much less processing
on the client side if DNS client querying is possible (one UDP packet, 
generally).

Brian

 Additionally, a DNS-only solution would mean implementing a DNS client  
 inside the application, since AFAICT the platform socket APIs usually do  
 not provide the necessary functionality needed to access non-IPaddress  
 data.

 While I am not opposed to the data being available in DNS, there must be a  
 simple way to collect and provide it to clients efficiently and for any  
 use case, while reducing privacy issues (which a batch of data for a given  
 TLD will solve neatly), and with respect to HTTP clients, HTTP is the only  
 method we can rely on, and it will also be available to many specialized  
 applications that use HTTP, perhaps through some library.


   

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

Re: [DNSOP] Public Suffix List

[Brian Dickson]

Gervase Markham wrote:
 The difference is that the public suffix list is an (attempt at an)
 expression of fact, not policy.

I think is where you are encountering resistance, even though you may 
not realize it.

What you are doing is *publishing* something, which alleges to be a 
factual list.

Who is on it, who is not on it, and who uses it and how, matter a great 
deal.

If the list is 100% complete and 100% accurate and 100% timely, there 
are no problems.
Any deviation from that situation, regardless of how much and in what 
manner the deviation occurs,
puts the publisher of alleged facts at risk.

And relying on authoritative sources to push data to you, is a reverse 
onus that hundreds of years of case
law quite likely present a formidable obstacle, if it becomes necessary 
to defend your choice.

Here's a concrete analogy that may be suitable for demonstrating the issue.

Imagine a magazine dedicated to Tires. It publishes an article on 
Tire Safety.
It contains a list of Tires (manufacturer/model) safe to use at 180 km/h.
Is the list accurate? Timely? Complete?

If a reader bases a safety decision (buys tires, drives 180 km/h) that 
goes badly, then what?

What about recalls?

Also: Publishing a list may be even *riskier* than publishing a single, 
but erroneous, fact.

E.g. what about manufacturers not listed?
They have been implicitly or even explicitly defamed, even if you 
include a footnote to the effect that this list is not complete.
 If you are concerned that we will
 withhold changes or issue known-incorrect lists in order to conduct some
 sort of vendetta against a particular TLD, all I can say is why on
 earth would we do that?
   

No malice is needed on your part, for publishing a list to cause 
problems, esp. for you and the publisher (Mozilla).
I think you might not have considered that, yet.

Conclusion:

Regardless of the benign intent of the list, publishing it means needing 
to keep it timely, accurate,
and complete, and that is why the notion of updates based on volunteered 
data from registries,
updated only when software updates are performed, is a particularly bad 
idea.

I happen to think that the idea of maintaining such a list is probably 
not a bad idea itself.

It is the means by which the list is built, and distributed, that are of 
great concern.

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

Re: [DNSOP] Public Suffix List

[Brian Dickson]

Gervase Markham wrote:
 We've had this basic problem in the domain of cookies for years. I don't
 expect another solution to pop out of the woodwork now. But I'm open to
 being surprised :-)
   

Surprise!

If you want grouping, there is a simple-to-code, reliable, and 
authoritative way to do so.

Zone cuts (in DNS).

(Note well - a zone is not semantically identical to a domain, although 
they can at times seem that way.
In particular, if a child domain is served by the same server(s) as the 
parent, there will not be a zone cut.
This, I believe, will generally do a good job of permitting grouping 
automagically.)

Where there is a delegation of authority, via a zone cut, that is 
*exactly* where you want to group.

And in the absence of a zone cut, you do not want separation by grouping.

That (among other things) is what distinguishes foo.co.uk from 
myprivatesubdomain.foo.com.

Perhaps examining other aspects of DNS responses may further inform the 
device needing to determine grouping.
Things like presence/absence of glue (at particular places, e.g. 
root/TLD), commonality of NS instances between parent/child, etc.

Whether this gets done by the end-user's client, or by some 
more-centralized box, is an implementation issue (but one that should be 
given lots of thought!!).

But, it is better to trust information already published, which is 
required for proper operation of DNS, than to look for additional 
information that may become stale or inconsistent.

Brian Dickson


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

Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping

[Brian Dickson]

Andrew Sullivan wrote:
 Dear colleagues, 

 I received some time ago some comments off-list on the reverse-mapping
 considerations document.  I attempted unsuccessfully to convince the
 reviewer to send his substantive comments to the WG list, but he did
 not feel comfortable with that.  (He also provided a number of helpful
 editorial comments, which we incorporated in the most recent version
 of the draft.)

 I here will attempt to summarize my understanding of his comments.


 The reviewer takes exception to the suggestion that delegations in the
 forward zone should ideally have an entry in the reverse zone too.
 Instead, he suggests, that there be _at least one_ matching reverse;
 e.g.,

  A (PTR (ipaddr))   == ipaddr 
   
 or   A (PTR (A (fqdn))) == A (fqdn)

 but not many more.  The reviewer argues that the draft should in fact
 argue against adding multiple (more than a handful) PTR(s) for a
 given address.

   

Ah. I think the issue that (presumably) the original review had was, 
that if you have, say, 100 FQDNs,
all of which have:

A ( fqdnXX ) == A.B.C.D
(for all values of XX ranging from 00 to 99)

then the issue is, does there need to be 100 PTR records, where

PTR ( A.B.C.D ) == fqdnXX
(for all values of XX ranging from 00 to 99).

I would suggest that the forward/reverse validation embodied in this, 
could better be handled
from an operational perspective, with the following alternative solution:

CNAME ( fqdnXX ) == fqdn00
(for all values of XX ranging from 01 to 99)

and then only the one PTR record is needed to validate the 
forward/reverse universe:

PTR ( A.B.C.D ) == fqdn00.

It's not perfect, but may be adequate for many of the uses of 
forward/reverse matching.

It also does a better job of embodying the *intent* of both PTR and 
CNAME, when there are many
domains served/hosted on a single IP address.

(I would suggest that anyone considering doing the CNAME exercise, do so 
with sub-domain entries
rather than with the entire domain, so that SOA information can be kept 
separate for each domain.
E.g. have a real SOA for subdomain25.example.com, and a CNAME for 
www.subdomain25.example.com
which points to www.example.com, rather than having 
subdomain25.example.com be a CNAME pointing
to example.com.)

 It was our (the editors') impression that the above is consistebt with
 what the draft actually says, but that it has a different emphasis.
 That is, we think the draft says that existing reverse data is
 generally good, and matching reverse is nice to have, but that you
 shouldn't take this too far.  We decided not to try to change this in
 the draft on the grounds of the support we had so far, but we're
 certainly open to changes if others think this message is garbled in
 the existing version of the draft.
   

I think the language in the current draft does a good job of describing 
the general use and intent
behind its own recommendation, without delving into the minutia that 
having examples iterating
over many use cases would require.

I think in all cases, it is imperative that a solid understanding of the 
implications of design choices
exists, prior to embarking on implementing a given design. It is highly 
unlikely that a BCP can
do more than guide readers on the high-level issues, and the deeper 
understanding is the
responsibility of the reader, not the authors.

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

Re: [DNSOP] short term document roadmap

[Brian Dickson]

Peter Koch wrote:
 3) draft-ietf-dnsop-respsize-10.txt

WGLC to start around mid April ending around 2005-05-05
   

I have reviewed this draft, and don't see any problems in it. I am in 
favor of it progressing.

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

Re: [DNSOP] short term document roadmap

[Brian Dickson]

Peter Koch wrote:
 2) draft-ietf-dnsop-as112-ops-01.txt
draft-ietf-dnsop-as112-under-attack-help-help-01.txt

   

I have reviewed these two documents.

There is one minor correction needed, in  draft-ietf-dnsop-as112-ops 
section 2.2, where
BLACKHOLE-2.IANA.ORG (192.175.48.6) should be changed to read
BLACKHOLE-2.IANA.ORG (192.175.48.42), i.e. the correct address for 
blackhole-2 should be used.

Other than that, I see no problems with the documents, and am in favour 
of them being sent to WG last call
and proceeding through the rest of the process.
These will go to WGLC together, WGLC starting early April until 2008-04-18.
   
Brian Dickson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping

[Brian Dickson]

Peter Koch wrote:
 Dear WG,

 in accordance with the roadmap posted the other day, this is to initiate
 a working group last call on

   Considerations for the use of DNS Reverse Mapping
   draft-ietf-dnsop-reverse-mapping-considerations-06.txt

 ending Friday, 2008-04-04, 18:00 UTC.

 The document is aimed at a status of BCP.
 Please review the draft and send comments and/or statements of support or
 non-support to the WG mailing list.  We have taken names of volunteers,
 but everyone is encouraged to review.  There will be a five reviewer threshold
 and _no_ default action.
   
I have reviewed the draft, and support it moving forward without any 
further changes.

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

Re: [DNSOP] Always registering the IP address of the name servers during a delegation?

[Brian Dickson]

[EMAIL PROTECTED] wrote:

On Tue, Nov 27, 2007 at 02:05:55PM -0500, Edward Lewis wrote:
  

At 6:25 PM + 11/27/07, [EMAIL PROTECTED] wrote:



then we have a small issue...  you as zone admin, can't
dictate which IP's i must use on my machines, since you don't
control my connectivity.  as zone admin, your job is to
provide accurate mapping betwn lable and address ... the
extent of your influence is over the lables used, not their
IP addresses.
  
It is the prerogative of you to do what it takes to get your machine 
to function correctly.  It's the prerogative of the zone admin to 
include (or not) your machine in the NS set.


A zone admin ought to be aware of what the state of the slave servers 
are.  (That's my main point.)  There are minor tweaks, like IP 
addresses, and then there are major tweaks, like letting the domain 
lapse.  A responsible zone admin would be up to date on what the 
slave server admins are up to.  So, in this case, when the slave 
server changes IP addresses, this goes to the zone admin, who would 
then have to update the IP addresses registered.



a concrete example:

i have a zone, example.org and chose the following
nameservers:

moe.rice.edu
ns.isi.edu
PDC.example.org

as the admin of PDC.example.org, I know what IP addresses
are assigned and can change them on whim.  However, It is
the Height of Arrogance to presume I can tell the rice.edu
or isi.edu people what IP addresses to use on their machines.
  

Kind of, and maybe.

Basically, glue is necessary only because NS records are allowed to be 
FQDNs instead of just IP addresses. (This is so that fewer NS records 
need to be updated when a nameserver changes IP address(es).)


And that glue is needed only, strictly speaking, when the NS FQDN is a 
subordinate of the (parent) zone.
(Any NS whose FQDN isn't subordinate, is out of zone data, and 
shouldn't be kept as glue in the zone.)


Sometimes the glue isn't really necessary, if the FQDN of the NS is 
served by zone whose own NS records don't need glue, e.g. are served by 
entirely out-of-zone name servers.
(But that leads potentially to a name-server race condition, which 
operators should know to avoid. Having example.net use ns.example.org as 
its NS, and having example.org use ns.example.net as *its* NS, is bad form.)


In the example above, moe.rice.edu and ns.isi.edu are outside of the 
'.org' zone, and their IP should neither be accepted nor kept.
If, on the other hand, the nameservers were PDC.example.org, and 
FOO.other-example.org, then:
- the IP for FOO may already exist, if it is a nameserver for 
other-example.org
- even if FOO is not a nameserver for other-example.org, it might be in 
future.


So, capturing its IP *might* make sense. But, even if it exists, it 
isn't authoritative, so likely won't (or shouldn't) be used.
Which means, unless it comes to pass that other-example.org uses 
FOO.other-example.org as their nameserver, the presence or absence of 
quote-glue-unquote for FOO is irrelevant and annoying.


And if/when other-example.org adds FOO as their nameserver, they really 
do need to provide the IP, at which time the registrar should require 
the IP, and the registry operator should accept it as authoritative.


(Whether the things pointed to by the NS records are serving the zone is 
a whole other kettle of fish. Lame fish at that.)


Brian


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

Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)

[Brian Dickson]

Brian Dickson wrote:
It operates in exactly the same way, as if there were two equal cost 
routes to two or more routers, each
advertising the existence of one of these servers, on the other side 
of a PPLB router - except that it has

the ability to handle the state issue for TCP.

Anyone who operates a network with PPLB towards *external* routes, via 
BGP multipath, would
have to be an idiot or a fool, and would certainly have trouble 
retaining customers with clue.
I should clarify this even further: the above is *completely 
independent* of the anycast issue itself.


Consider the following set-up:

A single prefix is announced by a single ASN, for each of which there is 
only one instance. (I.e. non-anycast.)


The prefix is used solely for offering services that are front-ended by 
a stateful load-balancer pair.
There are two LB's for redundancy reasons. The LB's participate in the 
IGP of the ASN, also for redundancy.


The ASN (call it X) has two upstream ASNs, call them A and B.
Each ISP is connected to a separate router, for redundancy.

Inbound traffic from upstream ASN A hits router X-A, and inbound traffic 
from upstream B hits router X-B.


Router X-A prefers LB-A, and router X-B prefers LB-B.

LB-A and LB-B are state-independent. The LB support for stateful traffic 
(e.g. TCP) works only if all incoming packets

for a particular TCP session hit the same LB.

This is *not* anycast to the world. Some *may* consider it to be 
IGP-anycast.


It is an extremely common set-up, perhaps *the* most common 
configuration for load balancers.


Anyone using PPLB between the two AS paths, the one containing A and the 
one contain B, *will*
absolutely have problems using TCP, as in, it won't work except in 
unusual circumstances (one of

the two paths is withdrawn, for instance.)

The real issue is, when any load-balancer is used to affect access to an 
advertised service:

- is the LB breaking that access?
- is the LB operated by the operator of the service?
- does the service have customers or potential customers on the other 
side of the LB?

- does the operator of the LB offer a competing service?

If the answers to all but the second question are yes, then the LB 
operator may in fact be interfering with someone
else's business. And if they are aware of that interference, it may in 
fact be considered tortuous interference.
Especially if that LB set-up is not considered standard in the industry, 
and even more so if it contracts any

widely-used best common practice document for the industry.

Services that use set-ups like X above, would include DNS hosting 
companies, web hosting companies, email
hosting companies, content distribution networks, any number of B2B 
services, etc.

A lot of those companies are big players, with big legal departments.

I know *I* wouldn't want to interfere with their business...

And if I was doing PPLB, I certainly wouldn't be telling everyone 
operating services that I could potentially
be interfering with about it, on the mailing list that they all 
participate on.


Even if I had been doing PPLB, and *had* told everyone, once I became 
aware of this interference issue,
I would very quickly turn off PPLB, and tell everyone I had done so, and 
that I was wrong, so as not to get

sued into bankruptcy.

IMHO.

Brian

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

Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)

[Brian Dickson]

bill fumerola wrote:

not all load balancers work the same.
direct server return aka one-arm load balancing does no translation or
rewrite of any headers (l3 or l4). all it does is make a switching
decision based on health check and other weighting criteria.
  

Just to clarify, for those who aren't familiar with the basic idea:

By leaving the IP headers unmodified, the individual servers all expect 
to receive packets
that look like they came directly from the internet (and in fact, did) 
unmodified.


The return packets are thus suitable for being sent straight out without 
needing any rewritee, and

thus without touching the LB.

The F5 BigIP LTM models I've looked at that do that are the 6400 and 
6800 series, running 9.* level code.
There's nothing secret about it - it's a generic, vanilla function they 
ship with. The documentation is on-line.
Google for l4 fast bigip. (I have no connection with F5 other than 
being employed by a satisfied customer.)


It means that the servers are configured identically, are reachable 
without NAT, and are,
in effect, anycast. The Load Balancer is making a stateful decision 
about which individual server
to send each stream to, in the case of TCP, and stateless in the case of 
UDP.


It operates in exactly the same way, as if there were two equal cost 
routes to two or more routers, each
advertising the existence of one of these servers, on the other side of 
a PPLB router - except that it has

the ability to handle the state issue for TCP.

Anyone who operates a network with PPLB towards *external* routes, via 
BGP multipath, would
have to be an idiot or a fool, and would certainly have trouble 
retaining customers with clue.


Brian

P.S. I do not respond to trolls.
P.P.S. I will not respond the troll.

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

Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)

[Brian Dickson]

Dean Anderson wrote:

The load balancer is really just a special kind of stateful NAT.
  

No.

Load balancers can load balance, without any translation being done at all.

And a load balancer is by definition doing *anycast*.
The same address is used as a destination, and the packets are delivered 
to multiple hosts.

That is anycast.

Anycast can be either, or both of, global load balancer (using network 
announcements for accomplishing anycast),
or local load balancer (using L2/L4 to serve multiple servers from a 
single apparent host address.)


It's sort of like how what we call a layer-2 switch, is just an n-port 
bridge.

Stateful NATs and load balancers keep TCP state for an hour+. Otherwise
your SSH sessions would drop.
  

I beg to differ. NATs may keep multi-hour sessions up, however...

The load balancers I am familiar with, and those would be the ones 
relevant to anycast, have default timeout on tcp of 5 minutes.

I haven't argued against using load balancers, or firewalls.
  

Well, I guess that makes you an *inconsistent* crackpot.

If you continue to argue against anycast, you should also argue against 
load balancers, application layer gateways, network address translators, 
and stateful firewalls. And perhaps seat belts.

And what exactly *is* the anycast problem

http://www.av8.net/IETF-watch/DNSRootAnycast/History.html
  
(BTW - many of the links from  your kitchen sink, return 404 errors. As 
does the admin link for av8.net's home page.)

For most people on this list, this is common knowledge.
  

After having read your sad story, I can only say: my condolences to them.

Of course, the history doesn't seem to do anything other than say, 
repeatedly, There is a problem with anycast.
(If you read my original request, I was asking what the problem is, not 
what the history is, or what any of the meta-arguments have been about.)


The one minor thing you seem to have raised in, what, several *years* 
(?), is your

RFC 1812 overture.

Which is basically, that unless a root server answers every query it 
gets, it is in violation of the RFC.


Well, guess what - if PPLB occurs, and the properly formed query
never *gets* to the root server, that's the *network's* problem, not a 
DNS problem or RFC violation. QED.


Oh, and it's only a real problem if it happens consistently, for 
requests to *all* authority servers for a given zone.
As long as there's a *single* non-anycast instance, or as long as the 
anycast instances don't *all* have the *same*

load balancing cost, it's not a big deal.

I'd now like to address the rest of the technical content of the site:

Okay. That was easy.

BTW, your history as such, ends with you being banned from *this* list.
How appropriate.

(Apologies to everyone else. Didn't realize I was feeding a troll.)

Brian

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