There are basically two reasons to have split DNS
1. to prevent unreachable/ambigious addresses being used at the wrong time
2. to hide "internal" names
#1 can be addresses by minor changes to A/ records to include scope
information and then make getaddrinfo scope aware(). This would al
On 17/06/2010 5:34 PM, Eric Rescorla wrote:
On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson wrote:
Background #3: Key strengths and life time
RSA and DSA algorithms have the interesting property that the number of bits
in the key can be selected, by adding bits to the key the key gets stron
On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson wrote:
> Background #3: Key strengths and life time
> RSA and DSA algorithms have the interesting property that the number of bits
> in the key can be selected, by adding bits to the key the key gets stronger.
> Stronger keys can be used longer.
Currently section 3 of the document "mandates" that all zones be signed
using the KSK+ZSK model, I content this is outdated advice.
Background #1: Why bring this up now
While reviewing draft-ietf-dnsop-dnssec-dps-framework I found myself
loving certain sections of the document and hating othe
At 14:51 +0200 6/17/10, wrote:
Yes, but how to decide that?
That's a multi-homed device issue. Not a DNS issue. (This is a DNS
mailing list.) I am sure you are more on top of multi-homed device
issues than I so I'll stick to the DNS implications.
I think the importance of "DNS server s
On Thu, Jun 17, 2010 at 02:19:57PM +, bmann...@vacation.karoshi.com wrote:
> "ANY TIME"?? ever?
>
> how about "... deletions from the registry will allow the domain
> names to be resolved on the public Internet at some reasonable
> time after removal from the regist
On Thu, Jun 17, 2010 at 01:15:06PM +0200, Peter Koch wrote:
> (2) is covered in the IANA considerations section but while that section
> refers to a formal policy it does not offer guidance for review.
> We should capture the considerations from the most recent as well as
> previous dis
Hi,
Obviously I'm interested in this work as well.
If chairs approve, I would like to present the
draft-savolainen-mif-dns-server-selection at dnsop's IETF#78 meeting. As a
starting point for this discussion, or separately.
Teemu
> -Original Message-
> From: dnsop-boun...@ietf.org [m
Edward,
> Not necessarily. What I mean is that it is up to the multi-homed
> device to decide what interfaces are candidates (for the pending data
> transmission) and consult the DNS on each interface. However, what
Yes, but how to decide that? Some information is required, and this draft
prop
Dear WG,
"DNSSEC Key Timing Considerations", draft-morris-dnsop-dnssec-key-timing-02.txt,
and its predecessors were presented to the working group in Anaheim the
last time. There was discussion on the document itself as well as its
relation to draft-ietf-dnsop-rfc4641bis. The authors asked for a
On Tue, Jun 15, 2010 at 02:32:54PM +1000, Mark Andrews wrote:
> > Probably true, but not relevant to the discussion. The idea is to force
> > imple
> > menters to look at the registry so that they see *future* additions to it,
> > ev
> > en if they get there from reading this RFC-to-be.
>
> You
11 matches
Mail list logo
