4 ms·

I strongly disagree with the notion that only the zone owner should be able to generate records for it. Nothing else on the Internet behaves like that. And an

by davidu 16y ago

I strongly disagree with the notion that only the zone owner should be able to generate records for it. Nothing else on the Internet behaves like that. And anyways, Paul has changed his thinking since then on this subject too. He now prefers the model that OpenDNS has done since 2005: http://www.isc.org/community/blog/201007/taking-back-dns-0 http://www.isc.org/community/blog/201007/taking-back-dns-0 He may disagree with the NXDOMAIN wildcard that we do (which we will probably phase out in the long run anyways) but there is no question that allowing end-users to control their responses as they see fit makes tremendous sense. Do you think you should have to receive all email sent to your mail server? Of course not. Why should DNS be any different? Your network, your rules.

trotsky 16y ago
I'm confused as to why you claim DNSSEC removes user choice. Clearly any client that wishes to can simply fail to set DO and ED and will receive a traditional, non-validated response. If the client identifies that they wish authenticated data, they still have plenty of opportunities to act once they receive the authentic zone response. You mention mail host blacklisting, but typical DNS based blacklists have always been based on secondary lookups ie - 1.2.3.4.dnsbl.example.com - and not by forging the originator domain records. I'm returning signed content from my server to an end user, whether I am a root server, tld, or single domain server. There is no more reason you should have the authority to alter that data than there would be if I was returning an HTTPS response. It's only in the case where the client explicitly asks you to provide authenticated original zone data but you wish to return to them unauthenticated and modified zone data that you run into problems with DNSSEC.
- davidu 16y ago
  Actually, you are not returning signed content from your server to an end user. End users are stub resolvers, which are not DNSSEC aware. I believe that should change, as I mentioned previously, but even the DNSSEC proponents pretend to assume the edge is DNSSEC-aware. It most certainly was and is not from their design and implementation stand-point. A position I find ridiculous. But back to your point -- Of course, we could support DNSSEC and validate responses and then modify them as we see fit. Which is exactly why DNSSEC does not prevent our service from working. We already have some of the largest companies in the world forwarding DNS to us, when we enable DNSSEC validation for them, nothing will change. FWIW, none of them have us wildcard NXDOMAIN responses either, which is not surprising. They do have us block content, however. Some of these are Fortune 50 companies, btw.

by davidu 16y ago

trotsky 16y ago

I'm confused as to why you claim DNSSEC removes user choice. Clearly any client that wishes to can simply fail to set DO and ED and will receive a traditional, non-validated response. If the client identifies that they wish authenticated data, they still have plenty of opportunities to act once they receive the authentic zone response. You mention mail host blacklisting, but typical DNS based blacklists have always been based on secondary lookups ie - 1.2.3.4.dnsbl.example.com - and not by forging the originator domain records. I'm returning signed content from my server to an end user, whether I am a root server, tld, or single domain server. There is no more reason you should have the authority to alter that data than there would be if I was returning an HTTPS response. It's only in the case where the client explicitly asks you to provide authenticated original zone data but you wish to return to them unauthenticated and modified zone data that you run into problems with DNSSEC.

davidu 16y ago
Actually, you are not returning signed content from your server to an end user. End users are stub resolvers, which are not DNSSEC aware. I believe that should change, as I mentioned previously, but even the DNSSEC proponents pretend to assume the edge is DNSSEC-aware. It most certainly was and is not from their design and implementation stand-point. A position I find ridiculous. But back to your point -- Of course, we could support DNSSEC and validate responses and then modify them as we see fit. Which is exactly why DNSSEC does not prevent our service from working. We already have some of the largest companies in the world forwarding DNS to us, when we enable DNSSEC validation for them, nothing will change. FWIW, none of them have us wildcard NXDOMAIN responses either, which is not surprising. They do have us block content, however. Some of these are Fortune 50 companies, btw.