headers
Florian Weimer | 3 Aug 2009 08:02
Picon

Re: how DNS redirect works with empty response

* JINMEI Tatuya / 神明達哉:

> What does a recursive server that implements the DNS redirect service
> do in this case?

Empty responses are typically rewritten.  "NXDOMAIN redirect" is a
misnomer.

> then I guess authoritative server implementors who don't like
> NXDOMAIN redirect could introduce a "auto-site-finder" option,
> defaulting to yes, which automatically adds a wildcard name (of some
> meaningless RR type) at the apex of each authoritative zone:-)

I don't think this trick will work.
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 2 comments |
headers
Christopher Morrow | 3 Aug 2009 15:36
Picon

Re: how DNS redirect works with empty response

2009/8/3 Florian Weimer <fw <at> deneb.enyo.de>:
> * JINMEI Tatuya / 神明達哉:
>
>> What does a recursive server that implements the DNS redirect service
>> do in this case?
>
> Empty responses are typically rewritten.  "NXDOMAIN redirect" is a
> misnomer.
>
>> then I guess authoritative server implementors who don't like
>> NXDOMAIN redirect could introduce a "auto-site-finder" option,
>> defaulting to yes, which automatically adds a wildcard name (of some
>> meaningless RR type) at the apex of each authoritative zone:-)
>
> I don't think this trick will work.

with the unspoken reason of: "Because the redirctor has full control
over the dns reponse path and can 'at will' replace any response with
one of it's choosing."

For instance replacing all instances of: "isc.org" with
"dns-assist.com" because of either mal-intent or misconfiguration on
the part of the redirector service owner.

-Chris
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(Continue reading)

Permalink | Reply | 0 comments |
headers
JINMEI Tatuya / 神明達哉 | 3 Aug 2009 20:10

Re: how DNS redirect works with empty response

At Mon, 03 Aug 2009 08:02:40 +0200,
Florian Weimer <fw <at> deneb.enyo.de> wrote:

> > What does a recursive server that implements the DNS redirect service
> > do in this case?
> 
> Empty responses are typically rewritten.

Okay, then what about the followup question?

>> If it's the latter, what if only one of A and AAAA answers is empty
>> (which is actually today's common situation)?

I've quickly tested it against OpenDNS. Its server seems to behave as
follows:

1. if the query name has A but no AAAA, it returns an empty answer for
   a AAAA query
2. if the query name has AAAA but no A, it returns a "lied" A for an A
   query (while returning a correct answer for a AAAA query)

Aside from the point that any weird thing could happen with such a
server in the first place, case #2 is more problematic because a dual
stack end host may not be able to connect to an IPv6-only web server
that the host could otherwise, depending on the destination address
selection algorithm in the host.

> > then I guess authoritative server implementors who don't like
> > NXDOMAIN redirect could introduce a "auto-site-finder" option,
> > defaulting to yes, which automatically adds a wildcard name (of some
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Sullivan | 4 Aug 2009 05:31

Re: Question about detecting generated local-zones (relates todraft-ietf-dnsop-default-local-zones-08)

As usual when posting to this list, I am wearing no hat.

On Wed, Jul 29, 2009 at 01:59:08PM +1000, Mark Andrews wrote:

> 	Having a local copy of the root zone is a much better
> 	way to deal with queries to the root.

Is that really the advice we are giving people these days?  It strikes
me that in other contexts, a similar suggestion has been derided as
foolhardy, dangerous, and susceptible to evil behaviour by ISPs and
others.

Confused,

A

--

-- 
Andrew Sullivan
ajs <at> shinkuro.com
Shinkuro, Inc.
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 1 comment |
headers
Mark Andrews | 4 Aug 2009 06:22

Re: Question about detecting generated local-zones (relates todraft-ietf-dnsop-default-local-zones-08)


In message <20090804033135.GB4206 <at> shinkuro.com>, Andrew Sullivan writes:
> As usual when posting to this list, I am wearing no hat.
> 
> On Wed, Jul 29, 2009 at 01:59:08PM +1000, Mark Andrews wrote:
> 
> > 	Having a local copy of the root zone is a much better
> > 	way to deal with queries to the root.
> 
> Is that really the advice we are giving people these days?  It strikes
> me that in other contexts, a similar suggestion has been derided as
> foolhardy, dangerous, and susceptible to evil behaviour by ISPs and
> others.
> 
> Confused,
> 
> A

It has always been the best way to deal with garbage queries to the
root as it is the only method that deals with spread of query names
from unqualified queries being tried at the root.

Some people think that it may be abused by ISP's which replace the
root with a alternate content.  This is a bogus worry as they have
always been able to do that.  They could also just as easily point
the hints at alternate root servers.

Some people think that the copy may become outdated which can easily
be addresses by using automated methods to keep the local copy in
sync.  AXFR/IXFR from the root servers works as does a regularly
(Continue reading)

Permalink | Reply | 0 comments |
headers
W.C.A. Wijngaards | 21 Aug 2009 16:08
Picon
Favicon

new version: trust-history-02 draft

Hi,

http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02

Is available for review and comment.  This represents my take on how
to perform trust-anchor management for a validator without having
a system update mechanism (which works with unsafe DNS).

I have incorporated substantial comments and feedback.

o From Ted Lemon, Fixed the 'poison one upstream server'-attack.
o From Bert Hubert, Fixed the 'history in reverse'-attack.
o From Ed Lewis, Fixed so keys do not 'last forever'.
o From Mark Andrews, considerations for 5011-revocation.
o From Steve Crocker, Easy to test.
o From Bill Manning, can work on its own.
o From Wolfgang Nagele, zone owner advertising and 30days tweakable.
o From Olaf Kolkman, made the text easier to understand.
And more, sorry if I forgot here.

There is exactly one open issue:
o Publication of expired RRSIGs.
[ various people, Ed Lewis, Olaf Kolkman ]
This specification puts expired RRSIGs into the DNS and expects them
to be delivered.  What about 'smart' boxes that remove expired
signatures?  I think that boxes are not allowed to remove 'expired'
signatures.  This is why we have the CD flag.  This is good to put
into dnssec-bis-updates?
One solution may be a 'HISTORICAL_RRSIG' new type.  Which needs a
new type allocation, where perhaps RRSIG serves perfectly fine.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Joe Abley | 25 Aug 2009 03:22
Picon

Re: new version: trust-history-02 draft


On 21-Aug-2009, at 10:08, W.C.A. Wijngaards wrote:

> Is available for review and comment.  This represents my take on how
> to perform trust-anchor management for a validator without having
> a system update mechanism (which works with unsafe DNS).

I don't remember whether I've expressed my concerns about this work in  
e-mail before. I remember talking to people in Stockholm about it.

Keys are rolled for a reason. You can't always tell from the outside,  
as an automated device, what the reason was -- it could be that it's a  
conservative defence against a possible factoring attack having been  
executed within a particular time, or it could be due to a key  
compromise.

A historical key has been replaced by a new one. A historical key is  
not to be trusted. Signatures made by a historical key are not to be  
trusted.

This work seeks to solve a real problem, as far as I can see -- the  
problem of how a validator which has been disconnected from the  
network for some period of time can bootstrap itself based on a trust  
anchor that was once good.

It's not clear to me that using signatures from keys which are known  
not to be trusted is a good way for such validators to bootstrap  
themselves. In fact, I suggest that in general it's a bad way to do  
it, since in the event of key compromise the result could be the  
propagation of rogue trust anchors which might be hard to identify
(Continue reading)

Permalink | Reply | 10 comments |
headers
Todd Glassey | 25 Aug 2009 16:53
Picon
Favicon

Re: new version: trust-history-02 draft

Joe Abley wrote:
>
> On 21-Aug-2009, at 10:08, W.C.A. Wijngaards wrote:
>
>> Is available for review and comment.  This represents my take on how
>> to perform trust-anchor management for a validator without having
>> a system update mechanism (which works with unsafe DNS).
>
> I don't remember whether I've expressed my concerns about this work in 
> e-mail before. I remember talking to people in Stockholm about it.
>
> Keys are rolled for a reason. You can't always tell from the outside, 
> as an automated device, what the reason was -- it could be that it's a 
> conservative defence against a possible factoring attack having been 
> executed within a particular time, or it could be due to a key 
> compromise.
>
> A historical key has been replaced by a new one. A historical key is 
> not to be trusted. Signatures made by a historical key are not to be 
> trusted.
>
> This work seeks to solve a real problem, as far as I can see -- the 
> problem of how a validator which has been disconnected from the 
> network for some period of time can bootstrap itself based on a trust 
> anchor that was once good.
>
> It's not clear to me that using signatures from keys which are known 
> not to be trusted is a good way for such validators to bootstrap 
> themselves. In fact, I suggest that in general it's a bad way to do 
> it, since in the event of key compromise the result could be the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Joe Abley | 25 Aug 2009 17:07
Picon

Re: new version: trust-history-02 draft


On 25-Aug-2009, at 10:53, Todd Glassey wrote:

> Joe - the question becomes one of the integrity of the records process

Yes, that's my point.

> That said there are all kinds of PKI Operations Practice reasons  
> including "its part of our policy to roll keys periodically"

If there's no practical motivation to roll keys, then let's not do it.  
Rolling keys is a pain.

If there *is* a practical motivation to roll keys, then let's not  
infer any trust at all from old keys.

Joe

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 6 comments |
headers
Todd Glassey | 25 Aug 2009 18:48
Picon
Favicon

Re: new version: trust-history-02 draft

Joe Abley wrote:
>
> On 25-Aug-2009, at 10:53, Todd Glassey wrote:
>
>> Joe - the question becomes one of the integrity of the records process
>
> Yes, that's my point.
But your point is as a Systems Administrator rather than a Systems 
Auditor - the reasons for rolling the keys periodically pertain to 
Security Policy and the Practice which implements it.
>
>> That said there are all kinds of PKI Operations Practice reasons 
>> including "its part of our policy to roll keys periodically"
>
> If there's no practical motivation to roll keys, then let's not do it. 
> Rolling keys is a pain.
That's because of the design of the technical system - and if the policy 
controls specific to the use model had been designed before the protocol 
was implemented this wouldn't be so hard.
>
> If there *is* a practical motivation to roll keys, then let's not 
> infer any trust at all from old keys.
I agree that if a KEY is rolled it needs to have its application as a 
reliable TRUST ANCHOR revoked or terminated for events moving forward - 
but it still needs to be available for reviewing and re-certifying 
events from a forensic viewpoint. It *(the rolled key) still needs to be 
rolled so that requirement is still real.

Todd
>
(Continue reading)

Permalink | Reply | 4 comments |

Gmane