On Mar 5, 2013, at 1:50 PM, Olafur Gudmundsson wrote:
>
> On Mar 5, 2013, at 3:50 PM, Paul Hoffman wrote:
>
>> On Mar 5, 2013, at 12:10 PM, Olafur Gudmundsson wrote:
>>
>>> I will try to organize a face to face meeting on the topic of moving DNS
>>> delegation information in-band (inside DN
On Mar 5, 2013, at 3:50 PM, Paul Hoffman wrote:
> On Mar 5, 2013, at 12:10 PM, Olafur Gudmundsson wrote:
>
>> I will try to organize a face to face meeting on the topic of moving DNS
>> delegation information in-band (inside DNS)
>> from child to parent, at the IETF next week (will send out
On Mar 5 2013, Paul Wouters wrote:
On Tue, 5 Mar 2013, Joe Abley wrote:
[...]
If the record is not in the same class, then it's not in the same zone.
That route takes us back to Vixie metazones.
Ahh, I had not realised that.
It dates all the way back to RFC 1033 - "A zone file should only
On Mar 5, 2013, at 12:10 PM, Olafur Gudmundsson wrote:
> I will try to organize a face to face meeting on the topic of moving DNS
> delegation information in-band (inside DNS)
> from child to parent, at the IETF next week (will send out report after
> meeting)
> If you are interested in atten
On 2013-03-05, at 15:18, Paul Wouters wrote:
> On Tue, 5 Mar 2013, Joe Abley wrote:
>
>> Every new RR is a zone syntax change.
>
> Not true. I am still running generic record syntax in some opendnssec
> signers because those systems don't know all new RRtypes.
RFC 3597
Joe
_
On Tue, 5 Mar 2013, Joe Abley wrote:
Every new RR is a zone syntax change.
Not true. I am still running generic record syntax in some opendnssec
signers because those systems don't know all new RRtypes.
It would be better to use a non-IN class PARENT
example.com. PARENT DS parental-hints.ex
I will try to organize a face to face meeting on the topic of moving DNS
delegation information in-band (inside DNS)
from child to parent, at the IETF next week (will send out report after
meeting)
If you are interested in attending let me know and in general what times are
good for you,
On 2013-03-05, at 15:01, Paul Wouters wrote:
> On Tue, 5 Mar 2013, Joe Abley wrote:
>
>> I presume this has already come up, and there are good reasons why the
>> apparent lexical flexibility in what I'm about to suggest are swamped by a
>> sea of vicious snakes, but if the goal is "transmitt
On Tue, 5 Mar 2013, Joe Abley wrote:
I presume this has already come up, and there are good reasons why the apparent lexical
flexibility in what I'm about to suggest are swamped by a sea of vicious snakes, but if
the goal is "transmitting general information to the parent which in some cases t
On Tue, 5 Mar 2013, Paul Hoffman wrote:
On Mar 5, 2013, at 8:44 AM, Paul Wouters wrote:
That said, I'm still with the authors. Keep the CDS format identical to
the DS format. (and let parent and child local policy determine what to
do with the CDS RRset)
Seeing that at least a few zones hav
On Mar 5, 2013, at 9:45 AM, Joe Abley wrote:
>
> On 2013-03-05, at 12:09, Paul Hoffman wrote:
>
>> On Mar 5, 2013, at 9:05 AM, Joe Abley wrote:
>>
>>> I presume this has already come up, and there are good reasons why the
>>> apparent lexical flexibility in what I'm about to suggest are swa
On 2013-03-05, at 12:09, Paul Hoffman wrote:
> On Mar 5, 2013, at 9:05 AM, Joe Abley wrote:
>
>> I presume this has already come up, and there are good reasons why the
>> apparent lexical flexibility in what I'm about to suggest are swamped by a
>> sea of vicious snakes, but if the goal is "
[ Quoting in "Re: [DNSOP] General comments on dra..." ]
> > parent which in some cases they might care about" why not think about a more
> > general RRType of the form
> >
> > ; zone cut
> > example.com. IN SOA ...
> > ;
> > example.com. IN PARENT SOMERRTYPE rrtype-specific-data...
> > . . .
>
>
On Mar 5, 2013, at 9:05 AM, Joe Abley wrote:
> I presume this has already come up, and there are good reasons why the
> apparent lexical flexibility in what I'm about to suggest are swamped by a
> sea of vicious snakes, but if the goal is "transmitting general information
> to the parent which
Moin!
On 05.03.2013, at 17:44, Paul Wouters wrote:
> On Tue, 5 Mar 2013, Antoin Verschuren wrote:
>
>> Our zone is not the start of any chain of trust
>
> That's a TLD corner case (and not entirely true at that, since you don't
> really know what I configure as trust anchor in my resolver)
Sure
On 2013-03-05, at 11:54, Paul Hoffman wrote:
> On Mar 5, 2013, at 8:44 AM, Paul Wouters wrote:
>
>> That said, I'm still with the authors. Keep the CDS format identical to
>> the DS format. (and let parent and child local policy determine what to
>> do with the CDS RRset)
>
> Seeing that at l
On Mar 5, 2013, at 8:44 AM, Paul Wouters wrote:
> That said, I'm still with the authors. Keep the CDS format identical to
> the DS format. (and let parent and child local policy determine what to
> do with the CDS RRset)
Seeing that at least a few zones have a good reason to take DNSKEY as input
On Tue, 5 Mar 2013, Antoin Verschuren wrote:
Our zone is not the start of any chain of trust
That's a TLD corner case (and not entirely true at that, since you don't
really know what I configure as trust anchor in my resolver)
There are many more parent-child relationships then just the
regis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 05-03-13 13:34, Olafur Gudmundsson schreef:
> But will you accept DS 12345 8 2 ….. DS 12345 8 3 …..
>
> Second question: DO you accept DS 12345 14 2 ……
We do not accept any DS.
We accept DNSKEY with algorithms 3,5,6,7,8,10,12.
We always use
DS 12
On Mar 5, 2013, at 5:25 AM, Antoin Verschuren wrote:
>
>> So, to clarify, can the operator of a child zone who prefers to use
>> an algorithm 14 DNSKEY send you that key, confident that you will
>> accept it? What about algorithm 253?
>
> No.
> If the child prefers to use an experimental algori
On 5 Mar 2013, at 01:24, Daniel Massey wrote:
> Hi,
>
> We have an approach for naming IP prefixes and have been using the naming
> scheme for about a year now. The scheme is documented at:
>
> draft-gersch-dnsop-revdns-cidr-04.txt
>
> Over the past several months, we have incorporat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 04-03-13 18:16, Joe Abley schreef:
> Hi Antoin,
Hi Joe
> It's clear that we have different opinions on this, and I don't
> want to argue for the sake of noisemaking. However, I have a couple
> of clarifying questions (see below).
And I'm shouting
22 matches
Mail list logo
