gmane.ietf.dnsop

gtld-tech mailing list

Francisco Arias — 2013-05-16T23:29:19

Colleagues,

This is to let you know that we are launching a public, open mailing list
for technical discussions regarding gTLD registries and registrars. The
intention is to provide a forum for discussion of issues that may appear
during ongoing operation and particularly with the upcoming launch of new
gTLDs.

You can subscribe to the list at:

https://mm.icann.org/mailman/listinfo/gtld-tech

Regards,

Re: DS transfer requirements

Paul Wouters — 2013-04-29T19:01:49


Note that any sensible child already does that right now for the DS/DNSKEY
intersection.

Paul
_______________________________________________
DNSOP mailing list
DNSOP< at >ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: Thoughts on CDS

Dickson, Brian — 2013-04-29T19:01:11

 And to make this work really well, we have to figure out how I'd get a DS record for an unpublished DNSKEY into a zone like .NL (Antoin's - well, not his personally) that wants keys to work on, not DS records.  To hark back to Wes, I don't have answer for that, I don't want to propose a solution - like, hey Antoin, you're wrong, use DS instead - that would prevent Antoin from operating under his model.  I can see having CDS be used to indicate what DNSKEY Antoin would have to pull - if the key is in the DNS.

Okay, here's an open question (as in, if anyone knows, please chime in):

Is it possible/feasible/easy, to use DNSKEYs as public/private crypto tools' keys, generally?

E.g. If I have a public key (from a DNSKEY), say for my zone's parent-zone's ZSK, could I encrypt something (like a public DNSKEY value, which has not been published), and have the parent-zone's operator decrypt it (with their private key(s), either offline, online, or using an HSM which performs decryption without exposing the private

Re: DS transfer requirements

Edward Lewis — 2013-04-29T18:07:44

On Apr 24, 2013, at 9:57, Antoin Verschuren wrote:

In the sense that having to tell the parent that "I want these 10 DS records now" and then later "I want these 9 DS records now", resulting in the transfer of 19 records.  I could say, "please delete this one record now."  I.e., less to transfer.

The tradeoff is whether you value the mythical property of idempotent operations (where an unintentional repeated request has no bearing) or value minimizing verbiage exchanged.

Idempotent operations has appeal, but having lived through it, it's not "all that."  The alternative approach means the child has to maintain state and an eye on the parent.

Anyway, that's a rationale behind it.  Not a judgement.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

_______________________________________________
DNSOP mailing list

Re: Thoughts on CDS

Edward Lewis — 2013-04-29T18:00:41

Another omnibus response to a few.  (Had to step away for a few days.)

On Apr 23, 2013, at 17:02, Wes Hardaker wrote:


I think that the above statement is indicative of what I see wrong in the IETF process.  Sorry that this is off-topic, but I feel the need to pick this out as something to look out for in the consideration of the proposal.

"A lot of people like it" - but that is not consensus.  And, I can't say that I even agree with "a lot" and "like it".  What is "a lot" when you consider that very, very few people have ever recorded a public opinion on this?  I haven't counted (to be fair) but I bet it is less than 25.  We had more than that in the DNSOP meeting in Orlando.  To go quickly to the point, there are a lot of people in the DNS industry that don't participate in the IETF, so "a lot" is kind of a weak bar.  As for "like it", this is a first draft and I'd say I like it because it has potential.  Olafur has a framework for going forward which is good.  As for an concrete alternative - if I'm no

Biggest Fake Conference in Computer Science

2013-04-27T17:05:42

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without

Re: Thoughts on CDS

P Vixie — 2013-04-26T05:55:37

Mark's right.

Mark Andrews <marka< at >isc.org> wrote:

Re: Thoughts on CDS

Mark Andrews — 2013-04-26T05:50:44

In message <d1b81df4-99d1-4e1f-9654-e73a90d196a1< at >email.android.com>, P Vixie wr
ites:

Which doesn't work if you have a DNAME at the zone apex.
 

If there is going to be zone scraping then the record must be at
the zone apex.

Mark

Re: Thoughts on CDS

Joe Abley — 2013-04-25T19:19:05

On 2013-04-25, at 14:14, P Vixie <paul< at >redbarn.org> wrote:


Note that the type code for CDS has already been assigned, see:

http://www.iana.org/assignments/dns-parameters/dns-parameters.xml

(it's 59)


Joe
_______________________________________________
DNSOP mailing list
DNSOP< at >ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: Thoughts on CDS

P Vixie — 2013-04-25T18:14:06

Note that this is rendezvous information for the management plane and has no protocol significance. A distinct name in the child like _cds._dnssec.< at > could hold a DS record without confusion.

Similarly, the current DS RR should really have been placed at _ds.child label._dnssec.parentdomain to keep it unambiguously in the parent zone and away from the delegation name.

Is to late for the latter but not for the former.

Let's not burn a type code just to keep CDS separate.

Tony Finch <dot< at >dotat.at> wrote:

Re: Thoughts on CDS

Tony Finch — 2013-04-25T18:03:43

Re-using DS simply won't work, because you can't specify which side of the
zone cut to query when the child and parent are on the same server.

From the point of view of name servers and resolvers, CDS is not special.

It is slightly special for signers, and the parent update systems that
consumes CDS records need slightly special validators.

Tony.

Re: DS transfer requirements

Wes Hardaker — 2013-04-24T14:30:27


Well, I agree: you should be able to say "publish this list" and have it
be the entire set.  But others have indicated (in random conversations)
they want to be able to distinctly say do this or that.  I suspect that
it would be fine to bulk-publish a list for most people, however.

But the one caveat is that if we end up adding a hold-down time, and you
want to make another (but different) change half way through the
hold-down time then your only choice is to restart entirely or wait.
But it depends on what the hold down is watching too.

The real requirement could probably be better worded to indicate some
sort of independence between add/remove operations.

Re: DS transfer requirements

Joe Abley — 2013-04-24T13:59:14

Hi Wes,

On 2013-04-24, at 09:18, Wes Hardaker <wjhns1< at >hardakers.net> wrote:


I like your list. I think it's useful.

I think it's also instructive to write down the workflow of how changes might occur. For example,

1. each polling party (registry, registrar, parent zone operator, something) maintains a list of child zones that should be polled for CDS RRSets (which could be "all children", "all customers who have clicked a button to say they want to be polled", "child zones that we publish a DS for" or something else)

2. those child zones are polled regularly and the result is occasionally the construction of change requests for the DS RRSet

3. the polling party satisfies their requirements that a change should be made (e.g. automatic so long as technical checks pass, signal the child zone operator and request an out-of-band confirmation, something else)

4. the change is made in the parent zone (e.g. through direct changes to a locally-maintained parent zone, EPP signalling to a registry, something els

Re: DS transfer requirements

Antoin Verschuren — 2013-04-24T13:57:53

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 24-04-13 15:18, Wes Hardaker schreef:


I don't understand the rationale behind this one.
Can someone please explain to me?

I would think a child knows what "the rest" is at all time, and it's
best for him to have that oversight before he changes anything.
What am I missing, unknown standby keys?

When I change one nameserver in my delegation, I have to fill in the
other ones too with most parents. Where is DS different in that it
needs this requirement?

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschuren< at >sidn.nl
XMPP: antoin.verschuren< at >jabber.sidn.nl
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRd+ThAAoJEDqHrM883Agnw7sH/jtoBv0FeyMOKxikhIf/XXi2
WdPa2qIXKMd6OlVAkIKZ5lk5YO+1vOjwJpXdh6YvjrEfcF+dYtuOscWc8WUTIRtq
23/jGUBZPkxQR/KuHDPLbiln3yxMyXL614aqCo1SUwstQm54liobokfxQxArFXzq
yx0RHCa

DS transfer requirements

Wes Hardaker — 2013-04-24T13:18:45

Ed pointed me to a message he wrote [1] and some of the text there
triggered my "oh yeah; we need to start with the requirements" bell.  I
think part of the problem has been we don't have a good list of
requirements to compare any given solution to and we're talking around
them all because they're not written down (at least in one place).  So,
stealing bullets from Ed's text and adding some, what are in these lists
that shouldn't be, or is in the wrong place and what is missing
entirely?  There are some I surely suspect people disagree about their
location in the list.  This is very much a working-document list.

* MUST be able tos

  + Let the child be able to signal a desire to:
    - add a DS record for a key that is not yet published.
    - delete a DS record for a key that has never been published.
    - add a DS recrord for a key that is in use.
    - delete a DS record for a key that is in use.
    - add DS records for hashes not previously supported.
    - add DS records for hashes I am moving away

Re: Thoughts on CDS

Antoin Verschuren — 2013-04-24T11:36:39

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 23-04-13 17:18, Edward Lewis schreef:

I think this is the essence of why previous attempts to automate
technical DNS maintenance were unsuccessful.
I actually think it's the ICANN-style translation of the RRR model
that is wrong and why we don't go forward.

Registrars were invented to distribute administrative load for the
registry, and create competition in financial and customer care.

Because we started to use that same channel for the technical
bootstrapping of a delegation by the absence of a technical channel to
do so, ICANN has translated that into it's agreement as not only
bootstrapping, but also maintenance of technical data.

It is my firm believe that a registrar's role is administrative, and
after the sale is done, the registrant controls the technical data.
I can see that registrars are happy with the ICANN mistake because
they can now control their customers by allowing or disallowing
transfer of technical data, but it breaks the technical DN

Re: Thoughts on CDS

Andrew Sullivan — 2013-04-24T00:07:43


I confess that I haven't been following this discussion as closely as
I ought (every time I start to try to read the thread, I feel like the
thread gets longer).  But in the little I've managed to read, it
seemed to me that the points Ed was making were (1) that this is an
important additional move on the supposed insignificance of the SEP
bit, and that is worrisome and (2) if this mechanism were altered
slightly, then it could be more generic and therefore more useful.

Those both seem to me to be substantive and important points that
ought to give us pause about the existing proposal.  If I had a hope
of getting through Zeno's mail thread this week, I'd try to read it
all and respond.  Instead I'm just pointing out that a dismissal along
the lines of "just don't use it" seems to ignore at least part of the
point of reviewing things in the IETF.

Best,

A

Re: Thoughts on CDS

Wes Hardaker — 2013-04-24T00:03:52


And that's why we probably need to agree to disagree.  They're very
similar to me.  It's easy, using standard tools today, to create a RRSIG
on a DNSKEY with a revoke bit set that signals "something about DNSSEC"
to external parties that can't be used because it was signed with the
wrong key.  I'd been assuming you'd probably have a problem with this
too, since it meets the criteria you've been against with CDS as well.

Anyway...  I'm perfectly fine agreeing to disagree about this.  I do
think we are understanding each other and much more text won't help get
beyond the disagreement, which is not stemming from lack of
communication.

Re: Thoughts on CDS

Wes Hardaker — 2013-04-23T23:55:44


Well, I'll happily retract it then.  It certainly wasn't meant in a
negative way.  I have an amazing amount of respect for Ed as his
arguments are always well thought out and well stated.  The only
argument I have against Ed in this particular discussion is that the
resulting solution will be harmful to him since he can simply "not use
it".

Re: Thoughts on CDS

Doug Barton — 2013-04-23T22:26:45

Wes, that's not only not true, it's at best inflammatory, and IMO ad 
hominem.

As I pointed out in previous posts (where I was loudly shouted down) 
there is a rather large opportunity cost to creating something that's 
sort of good, but not likely to be deployed due to fundamental flaws. 
Arguably there are several opportunity costs involved, but the most 
important may be that by the protocol wonks claiming to have solved the 
problem, but the RRR community not deploying the solution because it 
doesn't meet their needs, we risk a repeat of the same situation we have 
had in the past where both sides stand in their respective corners 
pointing fingers and calling each other names.

Completely ignore me and my registry/registrar experience if you like. 
Ed is coming from the perspective of one of the largest registries in 
the world (read, the intended audience for this draft[1]), and telling 
you that there are problems with it. It might be worth a listen.

Doug

[1] I realize that non-TLD parents can al

Re: Thoughts on CDS

Doug Barton — 2013-04-23T22:17:18

Yeah, I get that. What I'm saying is, that's the problem.


No, the cases you describe bear only a surface similarity (they both 
have RRSIGs). Whereas given that CDS is a record specifically designed 
to signal something to the parent _about DNSSEC_, the fact that (from 
the customer's perspective) the DNSSEC is valid would cause confusion as 
to why the parent won't accept it.

I realize that you and I understand the fine distinction you are 
attempting to make, my point is that customers won't.


I would argue that as a matter of protocol clarity it shouldn't be 
possible for a signer to create a RRSIG that the intended consumer of 
that signature will discard as ... inappropriate(?) in spite of the fact 
that it validates just fine. But from the standpoint of having been in 
the registrar business in the past, I would not want to have to explain 
this problem to a customer (not to mention the revenue-destroying nature 
of any customer support call in the first place).


https://dougbarton.us/DNS/MX.html