[dns-operations] Implementation of negative trust anchors?

[Warren Kumari]

On Aug 23, 2013, at 12:19 PM, Paul Vixie <paul at redbarn.org> wrote:

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

Sure, true.

The untenable position for Comcast is having it not work for them, while still working for everyone else. In the scenario you described it would break for everyone, and you avoid the "but it works at Verizon, I'm moving to them" issue.


> we're only talking about this because DNSSEC is new.
> 

Yup. And those trying to do the right thing (enabling validation for clients) should get the carrot, not the stick.
Explaining to bean counters that you are going to enable something that might drive customers to $competitor is hard, especially if a: the customers are not asking for it, b: your competitors don't offer it and c: handwaving is needed to explain the benefits. 

Much respect to Jason and the rest of the Comcast folk to being one of the first major NA ISPs to turn it on.
W

> vixie
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)