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 keys)? This would avoid the act of publishing the DNSKEY, while still having the general mechanism of using DNS to publish CDS data. The DNSKEY is transferrable only to the parent, presuming no leakage of private keys on the parent's side, so the DNSKEY remains "unpublished", yet Antoin's model should still work (albeit with the addition of "encrypt" to the web-form).

If so, then I think this may be a feasible solution:

Have support for encrypted DNSKEY data, with fields indicating signer name (parent zone apex), key tag and algorithm.

NB – the parent's DNSKEY used for encrypting the child's DNSKEY, might possibly be used ONLY for encrypting/decrypting CDS data, I.e. be yet another member of the DNSKEY set, but be neither a ZSK nor a KSK. Maybe we could have another bit assigned to signal this particular use/purpose?

Thoughts?

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

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
DNSOP< at >ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 not mistaken, this is a working group. I have ideas, but because I time slice through life's issues, I don't want to fix my mind up with a solution that I'd fall in love with.

I have in the past offered up criteria for opening this up. But I don't have a solution. I'm trying to avoid having an opinion, because I don't think the problem is completely understood. Sorry for this rant, took more time than I thought.

Frankly, I really don't have even just the time to think about that much less launch a complaint. If the IETF promotes a document, I let it go. I honestly don't care that much about the process. There are a lot of bad documents out there already, what's one more? Well, in this case, if the proposal isn't general, you've added one more obstacle to a general solution. I do care about engineering something useful, document quality is not what I'm going to bark about - just not enough time.

On Apr 23, 2013, at 20:07, Andrew Sullivan wrote:

Exactly.

(I guess this is more of +1 to Andrew's message.)

On Apr 24, 2013, at 7:36, Antoin Verschuren wrote:

That's not a a helpful response to the problem. Whether you are right or not, you can't wave a wand and see requirements go away. No matter what one feels about a set of business rules, you have to deal with anything that others want to participate in. I have a hard time seeing how a model that accounts for 100's of millions of domain registrations can be so flawed it can't work - especially when there are, what 250 million total domain registrations? I"m just saying - you can't discount something that is so prevalent even if it is flawed.

On Apr 26, 2013, at 1:55, P Vixie wrote:

Not so much as a reply to that but a reply to the alternate engineering solutions and a reason to keep an open mind. If this were easily solved, it would have been in RFC 4034 and RFC 4035. Recall that in 2002-2003 (when the work behind the RFCs happened) we did not have the experiences we have now. And EPP had just started rolling out, etc....

Pretty much we need to have something in the CDS record at the apex of the zone. 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. And yes, there is a DS record in the root zone (as of last time I checked) that pointed to an un-published DNSKEY. And it is not one I put there just to mess with Antoin's model. ;)

I'm looking forward to the next document on this, and we can continue working on it. Problems are solvable, even more so when the problem statement is clear and agreed upon. And - the problem statement might morph as we progress.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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
DNSOP< at >ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

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

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 else)

Perhaps this could be made more general, but those four steps seem fairly integral to me, regardless of the shape of the relationship between child zone operator and parent zone operator.

A parent zone operator who wants to generate her own DS RRSets for a child zone could use the CDS signalling as method to identify a DNSKEY, could retrieve the DNSKEY RR in question (checking signatures) and generate their own DS RR for publication. The problem of how to signal the desire to publish a DS for a key that has not yet been published remains.

It occurred to me that there may be use cases where including a "do not process before <date>" and "do not process after <date>" on a CDS RR might be useful, especially if the time taken for the parent to poll is not predictable. But I haven't thought that through very hard.

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

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
yx0RHCauHgycsu9mOneJAZZS6OO2+go7NePtj3ZIjJAE7y+jWpV1hl2BDkBKZV5b
v6IQ+0gFVSeIXBiSJc+g5X/RDoQr2ISG6wd44GMxJyOXXvyg7HjyJMpCvhS9eudh
Yu5xt/N9YNAHP/F0p97t8i9CYdhMzMxxh9jL84f15CGAc3ByDCVQjzFS4OSvXVo=
=9fvB
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP< at >ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 from.

  + Allow the insertion/deletion action to be done by the parental agent
    when the child and parent both agree that one of these will trigger
    a "go" indication:
    - A child operator indicates "go" via a secondary mechanism (e.g., http)
    - Immediately after successful data verification within the transfer
      mechanism 

  + Not change existing DNSSEC validation steps (see [2] below)

* SHOULDs if possible
  + be able to signal using key material
  + be able to signal using DS hash material
  + operate on a single record at a time (publish this DS, don't touch
    the rest)

* MAYs
  + [2] If DNSSEC is used to validate the data, there may be other
    data verification steps (cryptographic or not) required before a
    "go" can occur

* Explicitly *not* a requirement:
  + Use the DNS itself as the transport


What else?  I'm quite sure there are more.  (And I'm pseudo-deliberately
stopping here to make sure that I don't sound like I'm trying to impose
only just my ideas or the ones I pulled from Ed's message).

Footnotes: 
[1]  http://www.ietf.org/mail-archive/web/dnsop/current/msg10293.html

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 DNS model if
registrars do this based on business rules rather than that it
technically has to work parent to child. But registrars couldn't care
less, as they are not responsible for any part of the technical
infrastructure. It's about power and money, not correctness.

Since I'm not a lawyer, nor have lot's of money or trademarks or both,
it's almost impossible to bring this to the ICANN agenda, and we are
all hostage of this situation.

- -- 
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)

iQEcBAEBAgAGBQJRd8PHAAoJEDqHrM883AgnIgUIAIKHKJXlgUU3JW/EyGNVa6or
51qqR3FiX68XXClPAWGaDeoEeyiZRMZX/hbj9AB92BIGi0DLKNwj38ouI9HVh+B0
tmRkkyzmOSuNIHVgqYk9n2ngfg0cMZSzas/hf00AAehYq6qEw/glyhSSL+pmljx1
Zb0pVz8l6Hay1sjBpYH3UL8bdeGXQigSOlhYKjJUgy6WJicf61y9/Z1nFkyTJXhe
U+QajMr80l9r3TaDS2jLW5cVlT6llZ5p7ACasR86jCKR4sqhXGdkQdpybHsrLvLK
UFLSQuZxgc5mUBGp3SyNvmalC7ruKkbCv8FhomSRiNm186GmHPn3kW4ZC8+cWOw=
=9NCD
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP< at >ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 also use this mechanism, but that 
use case is in the margins relative to the utility that it would have at 
the TLD level.

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

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  :)


Sorry, I don't regard that situation as equivalent at all. I understand 
your reasoning, I just don't agree with it.

Doug

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