On Feb 12, 2014, at 6:38 PM, George Michaelson wrote:
> The previous draft (at least for some of the TLDs) was anchored in the
> reality that changing the name already in use was not practical, e.g. there's
> a sufficient deployed base that uses DNS-like names ending in ONION that
> proposals t
In message , Paul Wouters wri
tes:
> On Thu, 13 Feb 2014, Mark Andrews wrote:
>
> > I also think we should establish requirements for updating parent
> > zones. As a wg we have jumped in the deep end and gone straight
> > to solutions without working out the actual requirements.
>
> We tried be
On Thu, 13 Feb 2014, Mark Andrews wrote:
I also think we should establish requirements for updating parent
zones. As a wg we have jumped in the deep end and gone straight
to solutions without working out the actual requirements.
We tried before and failed
http://tools.ietf.org/html/draft-wou
In message ,
George Michaelson writes:
>
> >
> > On 2014-02-12, at 11:28, Marc Blanchet wrote:
> >
> > > - I like better that approach than the previous draft registering many
> > tlds.
> >
> > The previous draft (at least for some of the TLDs) was anchored in the
> > reality that changing the
On Thu, Feb 13, 2014 at 4:24 AM, Joe Abley wrote:
>
> On 2014-02-12, at 11:28, Marc Blanchet wrote:
>
> > - I like better that approach than the previous draft registering many
> tlds.
>
> The previous draft (at least for some of the TLDs) was anchored in the
> reality that changing the name alr
I think there should be some discussion on how to deal with nameservers
that fail to respond to legitimate queries.
draft-andrews-dns-no-response-issue contains some thoughts on the
matter.
I also think we should establish requirements for updating parent
zones. As a wg we have jumped in the dee
On 2/12/14, 10:40 AM, Ted Lemon wrote:
> On Feb 12, 2014, at 1:24 PM, Joe Abley wrote:
>> I suspect that there would be fewer roadblocks involved in choosing
>> an anchor ALT.ARPA than ALT, since ARPA is under the control of an
>> IETF family member while the root is controlled by distant cousins.
On Feb 12, 2014, at 1:24 PM, Joe Abley wrote:
> I suspect that there would be fewer roadblocks involved in choosing an anchor
> ALT.ARPA than ALT, since ARPA is under the control of an IETF family member
> while the root is controlled by distant cousins. If I'm right that this
> proposal is for
On 2014-02-12, at 11:28, Marc Blanchet wrote:
> - I like better that approach than the previous draft registering many tlds.
The previous draft (at least for some of the TLDs) was anchored in the reality
that changing the name already in use was not practical, e.g. there's a
sufficient deploy
Thanks. Indeed I was stupid: wrong base32 encoding
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/
- I like better that approach than the previous draft registering many tlds.
- I would prefer an IANA registry under .alt with "expert" review policy. A
namespace with possible collisions (past or future) have very low value to me.
names are leaking in various contexts, so collisions would be ba
Hi Nicholas
On Wed, Feb 12, 2014 at 07:35:47AM -0800, Nicholas Weaver wrote:
> Looking at com, the NSEC3 for "com" is:
> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - ...
>
> (Algorithm 1 -> SHA-1, flag = 1, iterations = 0, salt = None, fetched by "dig
> +dnssec MX com @a.gtld-ser
On Mon, Feb 10, 2014 at 12:58:38PM -0800,
internet-dra...@ietf.org wrote
a message of 36 lines which said:
> Title : The ALT Special Use Top Level Domain
> Authors : Warren Kumari
> Andrew Sullivan
> Filename: draft-wkum
It might be because NSEC3 uses base32 with extended hex alphabet.
Looks like you're using plain base32.
See http://tools.ietf.org/html/rfc4648#section-7
--Shumon.
On Wed, Feb 12, 2014 at 07:35:47AM -0800, Nicholas Weaver wrote:
> I'm trying to do my own implementation of NSEC3 as part of my dyna
I'm trying to do my own implementation of NSEC3 as part of my dynamic DNSSEC
server (in order to do NSEC3 lies for NXDOMAIN, since you can't do such a lie
with NSEC, NSEC lies only allow "0 answer noerror" which is unfortunately NOT
the same)
But I appear to be doing something stupid, and am no
15 matches
Mail list logo