[dns-operations] All NSs for a TLD being in the TLD itself
daniel at digsys.bg
Tue Oct 29 13:10:25 UTC 2013
On 29.10.13 14:33, Einar Lönn wrote:
> On Oct 29, 2013, at 12:51 PM, Daniel Kalchev wrote:
>>> 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
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
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.
>>> 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.
> 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.
> 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
> ...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.
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
More information about the dns-operations