[dns-operations] All NSs for a TLD being in the TLD itself

[Einar Lönn]

On Oct 29, 2013, at 2:10 PM, Daniel Kalchev wrote:

> 
> On 29.10.13 14:33, Einar Lönn wrote:
>> On Oct 29, 2013, at 12:51 PM, Daniel Kalchev wrote:
>> <snip>
>>>> Furthermore this relatively tiny risk could be compared to the risk of a hijack of a name server residing out-of-zone which silently captures X percent of all your traffic. As you say you could consider this as having all your eggs in one basket; however I kind of like the idea of having 100% control, especially with DNSSEC-signed NS' and glue, and this is tricky to achieve in any other way.
>>> DNSSEC is here to help you. No matter what happens with any of your
>>> secondaries, as long as they do not have the secret part of your
>>> DNSKEY(s), this does not matter. This kills the incentive to
>>> hijack/attack DNSSEC signed zones secondaries, because it is not an
>>> attack vector that works. Those X percent of responses, will simply be
>>> ignored by all validating resolvers.
>> Oh really? How will I sign the glue of out-of-zone nameservers? In theory they could be in a signed-zone themselves, and thus signed etcetera, but it's still not even close to having them in a non-delegated zone controlled in one single place if you want full control (all these steps add complexity and security implications regardless of how you perform them to be honest, however; you do win stability).
>> 
>> Currently every single A & AAAA is signed for .SE, and signed with our own key inside our own zone. There are no dependancies outside of root.
> 
> This is not what I said. Perhaps my command of English is not good 
> enough to communicate it properly, so I will try again.
> 
> Suppose, .se had an out of zone secondary, say ns.iana.org. Obviously, 
> "outside of .SE control".
> 
> Your worry is that somehow things might go wrong with this name server, 
> because something went wrong with .iana.org or with .org. Of course this 
> is possible.
> Your next concern is that control of ns.iana.org might go in the wrong 
> hands. This is also possible.
> 
> Without DNSSEC, whoever controls that name server can respond on behalf 
> of your zone, and you resolvers see "X percent" answers, that you did 
> not authorize.
> 
> With DNSSEC, none of this is possible. You should know why.
> This is irrespective of whether the zone holding that name server is 
> signed or not, and by whom. At worst, you will be operating with one 
> name server less, which is logical, because that name server is 
> compromised and you should not be using it anyway. DNSSEC simply makes 
> that "ignore the broken name server" process automatic.

I'm not a DNSSEC-expert, but I really think you're wrong in what DNSSEC can and cannot do.

Afaik: If a record is not signed in-zone it *can* be faked and the cache *can* be poisoned. With your example above I can indeed sign the NS RRSET containing "ns.iana.org" but I cannot protect it's glue and this, if all the other zone(s) are not properly protected with DNSSEC, gives opportunity for anyone to poison at any level; I could either attack the glue itself for NS.IANA.ORG or I could attack the zone IANA.ORG or I could attack ORG (if these are not signed).

If DNSSEC would automatically secure the entire Internet if a single zone was signed, I suppose that'd be great, this is however not so. There is a chain of trust similar to the delegation chain and you cannot secure or control anything outside your own zone(s).

I cannot poison the cache when using signed in-zone names, but I can sure poison the cache for glue of unsigned out-of-zone name servers (or even redelegate the zones themselves if they are not signed). That is the definition of cache poisoning and DNSSEC doesnt help you except for protecting the *name*, which no computer cares about in the slightest.

>>>> Had to speak with some people internally before composing this, thus the delay. Saw more emails concerning this later in the thread; they are actually (somewhat) incorrect, out-of-zone NS' would have helped us. Still not worth it though imho, considering control and security mentioned above.
>>> I believe you need to open that discussion again, in consideration of
>>> the DNSSEC properties mentioned above.
>>> 
>>> Daniel
>> Honestly I think it's a matter of policy; how much is security and control worth if you pitch it against stability?
> 
> With DNSSEC, there is no downside.

Are there no stability concerns with DNSSEC you say? Let me just politely disagree with you, strongly. ;) The security benefits outweigh the stability concerns, yes, but this does NOT mean there are no stability concerns to address. If DNSSEC had no downsides everyone would use it from day 1, without hesitation, and the world would be a happier place.

>> Our current delegation of .SE I think is pretty much focused on security and control, it's only natural that we lose some stability due to this but basically… it's a cost we're willing to take (and you could perhaps argue that we've paid the price for it with this incident).
> 
> Policy has it's costs. Too strict policy, and it costs you more than it 
> brings benefit.

Yes, however we're still using the same policy... for a reason.

>> ...I wish I could find that survey, it was quite good and talked about exactly this for a lot of different TLDs. ;p No one remembers it? Annoying that I cant refer/point to it... ;(
> 
> Don't know about that, but I came recently across one that was giving 
> .BG as an abysmal example of using out of bailiwick glue. I believe, it 
> was authored by Verisign. For some reason, there are people who believe 
> that because we are small registry in a small country we don't know what 
> we are doing. ;-)
> 
> In summary, there is no wrong way to do it. I just wanted to point out, 
> that when using DNSSEC, the reasons you outlined as to why you want to 
> keep all glue in-zone are not valid.
> 
> Daniel
> 
> PS: By the way this situation reminds me of a story every child in my 
> land learns: http://www.slideshare.net/ts_taralova/the-legend-of-khan-kubrat

If you *only* use out-of-zone, unsigned names in a dnssec-signed zone then you might actually deserve some serious doubts. ;p But that's a personal opinion really. I just dont see the point of securing something that inherently cannot be secured, because in that case you try and secure something that you have no control over… ;p

However; if the out-of-zone names/zones are signed then it's another matter entirely, although I still feel quite strongly about not having *any* in-zone names as you're then 100% dependant on third parties' competence for your own continuing existence on the Internet...

I'm an OpenBSD person. Only the truly paranoid survive. ;)


	/Regards, Einar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4057 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131029/c3ee1381/attachment.bin>