[dns-operations] Implementation of negative trust anchors?

[Paul Vixie]

David Conrad wrote:
> On Aug 22, 2013, at 3:25 PM, Paul Vixie <paul at redbarn.org> wrote:
>
>> ... over and above the absurd engineering economics behind it, i don't like NTA. if my signatures don't work because i've been attacked (for example, one of my name servers has been compromised), the last thing i'd want is comcast telling their customers that the data they're getting from my compromised name server is ok to consume because it's unsigned.
>
> Exactly so.  However pragmatically speaking if someone (say NASA perhaps?) screws up signing their zone, it isn't the zone-signing-screwer-upper that gets the phone calls, it is the eyeball networks that are doing the validation.  Without NTA, the eyeball network operators have a choice, eat the cost of those calls or turn off validation _for ALL signed zones until the zone-signing-screwer-upper fixes their problem_.
>
> I gather you believe eating the cost is the right answer.  ...

indirectly, yes.

with RPZ, we made it possible for full service resolver operators
(recursive name server operators) to edit zone content as a matter of
local policy. NTA is not different in principle, but it's different in
an important way: in RPZ, the content being edited is malicious and/or
criminal. where my mind isn't bending well at the moment is where we
edit in resolvers content belonging to people who aren't malicious.
since we can't know the reason why their signatures are failing, telling
our full service resolver and its downstream stubs that there are no
signatures is overreach.

if nasa.gov had screwed up its delegation or had allowed its public
secondary servers to expire the zone due to primary unreachability, i do
not think the phone at comcast would have rung less, but i also don't
think that comcast would have fixed nasa's error in local policy. we're
only talking about this because DNSSEC is new.

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130823/45c797b5/attachment.html>