-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
op 11-04-14 23:12, Warren Kumari schreef:
Can folk please let us know if they would prefer: A: The child
SHOULD remove the CDS/CDNSKEY RR from the zone once the parent has
published it (currently documented behavior) or
B: The child SHOULD NOT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
op 12-04-14 00:06, Warren Kumari schreef:
The parent should use whichever one they choose, but MUST NOT query
for both and perform consistency checks between the CDS and CDNSKEY
records.
A parent MUST NOT perform a consistency check between CDS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
op 10-04-14 21:54, Patrik Fältström schreef:
We already have too many parents that have I do not know how many
stupid rules for what various values must be in the child hosting
situation, and in many cases that make it plain impossible to do
what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
op 12-04-14 09:28, Patrik Fältström schreef:
No, I want B. That CDS and CDNSKEY is staying in the zone.
To keep it in the same thread,
I want:
C: The child MAY remove the CDS/CDNSKEY RR from the zone once the
parent has published it, and this is
On 14 apr 2014, at 14:32, Antoin Verschuren antoin.verschu...@sidn.nl wrote:
op 12-04-14 09:28, Patrik Fältström schreef:
No, I want B. That CDS and CDNSKEY is staying in the zone.
To keep it in the same thread,
I want:
C: The child MAY remove the CDS/CDNSKEY RR from the zone once the
Perhaps again I’ll be labelled as a potential troll for this. Again, using an
example for a non-specific comment...
On Apr 14, 2014, at 7:09, one person wrote:
At 10-04-14 21:54, someone else:
We already have too many parents that have I do not know how many
stupid rules for ...
While
On 04/14/2014 02:32 PM, Antoin Verschuren wrote:
op 12-04-14 09:28, Patrik Fältström schreef:
No, I want B. That CDS and CDNSKEY is staying in the zone.
To keep it in the same thread,
I want:
C: The child MAY remove the CDS/CDNSKEY RR from the zone once the
parent has published it, and
On 04/14/2014 03:05 PM, Edward Lewis wrote:
I think it is silly to burn two RR types to communicate the same
thing. You’re inviting debate on testing and handling the two being
out of sync.
Would you prefer one RR type with varying RDATA format (like with
IPSECKEY)? I don't.
Best regards,
On 4/14/14, 8:50 AM, Patrik Fältström wrote:
On 14 apr 2014, at 14:32, Antoin Verschuren antoin.verschu...@sidn.nl wrote:
op 12-04-14 09:28, Patrik Fältström schreef:
No, I want B. That CDS and CDNSKEY is staying in the zone.
To keep it in the same thread,
I want:
C: The child MAY remove
On 14 apr 2014, at 15:16, Matthijs Mekking matth...@nlnetlabs.nl wrote:
On 04/14/2014 03:05 PM, Edward Lewis wrote:
I think it is silly to burn two RR types to communicate the same
thing. You’re inviting debate on testing and handling the two being
out of sync.
Would you prefer one RR
On 4/14/14, 9:21 AM, Patrik Fältström wrote:
On 14 apr 2014, at 15:16, Matthijs Mekking matth...@nlnetlabs.nl wrote:
On 04/14/2014 03:05 PM, Edward Lewis wrote:
I think it is silly to burn two RR types to communicate the same
thing. You’re inviting debate on testing and handling the two
In the world of trade-offs:
Having one record:
1) Can retrieve it in one query
2) Easier to specify what to publish and what to read
3) Parsing involved inspection of RDATA
Having two records:
1) Need two queries or rely on ANY
2) Have to explain to the client what to publish, server has to
On Mon, Apr 14, 2014 at 9:17 AM, Tim Wicinski tjw.i...@gmail.com wrote:
On 4/14/14, 8:50 AM, Patrik Fältström wrote:
On 14 apr 2014, at 14:32, Antoin Verschuren antoin.verschu...@sidn.nl
wrote:
op 12-04-14 09:28, Patrik Fältström schreef:
No, I want B. That CDS and CDNSKEY is staying in
On Mon, Apr 14, 2014 at 11:10 AM, Warren Kumari war...@kumari.net wrote:
On Mon, Apr 14, 2014 at 9:17 AM, Tim Wicinski tjw.i...@gmail.com wrote:
On 4/14/14, 8:50 AM, Patrik Fältström wrote:
On 14 apr 2014, at 14:32, Antoin Verschuren antoin.verschu...@sidn.nl
wrote:
op 12-04-14 09:28,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group
of the IETF.
Title : Automating DNSSEC Delegation Trust Maintenance
Authors : Warren Kumari
At Mon, 14 Apr 2014 15:10:56 +0200,
Matthijs Mekking matth...@nlnetlabs.nl wrote:
C: The child MAY remove the CDS/CDNSKEY RR from the zone once the
parent has published it, and this is how to do that safely.
So I'm ok if they stay in, but we need a way to get them out for the
ones that
On Mon, Apr 14, 2014 at 7:09 AM, Antoin Verschuren
antoin.verschu...@sidn.nl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
op 10-04-14 21:54, Patrik Fältström schreef:
We already have too many parents that have I do not know how many
stupid rules for what various values must be in
Hi folks,
Please find draft-mglt-dnsop-search-list-processing-00.txt [1] This draft
comes in the context of generic TLD with possible naming collision. In
order to keep naming resolution stable and reliable, it describes 1) how
resolver should generate their search list, 2) how resolver should
In message CADZyTkn2Wau99zfQR+jjwHVr4Jnq3Eo=Ht+OEScbvKBLc=7...@mail.gmail.com
, Daniel Migault writes:
Hi folks,
Please find draft-mglt-dnsop-search-list-processing-00.txt [1] This draft
comes in the context of generic TLD with possible naming collision. In
order to keep naming
http://www.ietf.org/id/draft-andrews-edns1-00.txt
--
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
20 matches
Mail list logo
