Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

On May 14, 2012, at 10:46 PM, Jim Reid wrote:
> So now people with clue may well have to spend even more time at IGF, ITU and 
> the like to explain why this article is flawed.

Yep. It would be nice if somebody neutral and technically well-respected 
(DNS-OARC?) were to write up a less flawed article that folks who go to 
IGF/ITU/ICANN/et al. could use as a rebuttal.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Stephane,

On May 14, 2012, at 11:14 PM, Stephane Bortzmeyer wrote:
>> BTW "fair and equitable" is one of those unfortunate phrases that
>> gets Internet governance types very excited, not always in a good
>> way: eg "fair and equitable" distribution of IP addresses.
> 
> We disagree here. Asking for fairness and equity (for IP addresses or
> root name servers) seem reasonable to me.

Asking for 'fairness and equity' is indeed reasonable. The problem is defining 
(and getting consensus on) what 'fair and equitable' actually means, 
particularly in an IGF/ITU/ICANN context... 

In the context of this blog posting, I personally think having folks (ISPs in 
particular) pre-fetch/mirror the root zone in their caches is the right answer 
to pretty much any useful definition of "fair and equitable" related to serving 
the root zone :-).

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Todd,

On May 15, 2012, at 6:06 AM, Todd S wrote:
>>> Asking for fairness and equity (for IP addresses or root name servers) seem 
>>> reasonable to me.
>> The devil is in the details. Network elements should on the Internet be 
>> distributed according to network topology. .

While I agree, the counter-argument to this in Internet Political circles is 
that it reinforces the inequitable distribution of resources since the network 
topology is (by definition) defined by the "haves" and not the "have nots".

> I think this is the correct approach.  But I don't think it should be up to 
> the root server operators to figure this out - they put root servers out 
> there in reasonable network locations around the world.

Their (the root server operators) infrastructure, their decision on where to 
put instances.  Remember that no single entity is in control of the root server 
operators -- each operates independently (albeit potentially with cooperative 
coordination if it is in the root server operators business interests (loosely 
defined) to do so).

> One could logically assume that if a caching server is within a certain 
> radius of a node geographically, they are likely able to route to it (country 
> boundaries/geography may change this, but I did say roughly).  

This assumption is what leads folks to do what Pingdom has done.  It is a 
common mistake to assume network topology matches geo-political topology.  In 
many case, regulatory regimes, business rules, etc. result in the exact 
opposite. I suspect it would be an interesting experiment to actually collect 
the data to see what the actual correlation between network topology and 
geo-political topology is for root service.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Joe,

On May 16, 2012, at 8:33 AM, Joe Abley wrote:
> Right now we have a root server system that is measurable,

While I would agree that it would be more measurable, I'm not convinced that it 
actually is more measured.  

> Ad-hoc distribution of root zone operation to an unbounded set of operators 
> would result in a system that was much more challenging to measure, that was 
> operated by people whose focus was (properly) elsewhere, and with whom 
> reliable communication was probably not possible.

Ignoring the fact that anyone can set themselves up as a root zone operator 
now, I believe there are more options than either 12 XOR infinity.  For 
example, one could imagine a subscription-type of system where in order to 
"join the club" and get a TSIG key to a particular server or (say) NOTIFYs of 
zone updates, you have to agree to share name server stats, agree to have a 
24x7 contact, etc.  Other models are, of course, feasible.

> I am generally in favour of decentralisation, but in this specific instance I 
> can't see much benefit to offset the deficiencies.

Let's spell this out.  Benefits I see: 
- increased resilience to DoS attack
- reduced dependence on a single point (ok, 13 points) of failure
- potentially improved performance
- greater autonomy
- reduced political whinage about not having a root server
- greater openness and transparency

Deficiencies I see: 
- reduced opportunities of control (could be argued to be a benefit)
- reduction in theoretical measurement points
- potentially reduce performance if a mirror is operated poorly

What are the benefits and deficiencies you see?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

On May 16, 2012, at 11:56 AM, Joe Abley wrote:
>> While I would agree that it would be more measurable, I'm not convinced that 
>> it actually is more measured.  
> Well, some people at least are doing measurement.

Not sure why you'd assume new entrants would refuse to do measurement. I'd 
expect the opposite actually, although perhaps not universally (but we don't 
have that now as far as I'm aware).

> If we mad that measurement infeasible, there would surely be less :-)

Perhaps I'm misunderstanding: what would make doing measurement infeasible?

>> Let's spell this out.  Benefits I see: 
>> - increased resilience to DoS attack
>> - reduced dependence on a single point (ok, 13 points) of failure
>> - potentially improved performance
>> - reduced political whinage about not having a root server
> I don't understand why you're singling those out as benefits of the 
> slave-the-root scheme, when they are just as applicable to the current model 
> of (e.g.) L-Root deployment.

The assumption I'm making is that there would be wider deployment than has 
occurred in the current model.  While I commend your efforts with "L", I 
suspect there are a number of folks who would prefer not to enter into any form 
of contract ($0 or not) with ICANN. 

> I don't really understand your second point, though; there are many hundreds 
> more than 13 servers, if that's what you're counting.

I'm (of course) counting the IP addresses. My assumption is that a 
slave-the-root scheme would mean less reliance on responses from queries sent 
to the 13 root IP addresses.

> Is there an assumption is that there are orders of magnitudes more people who 
> would slave the root zone for $0 under contract to (say) the L-Root operator 
> than would let ICANN run a local root server for $0 under a different 
> contract?

Where did contracts come in again?

>> - greater autonomy
>> - greater openness and transparency
> 
> These are subjective, I guess.

Autonomy, no.  Openness and transparency, probably.

> Greater autonomy in what way?

In the sense that you would be less dependent on entities outside of your 
control. If you slave the root, you (objectively) operate autonomously of any 
events that might occur to the root servers.

> If the model was that people could deploy whatever infrastructure they 
> wanted, and there were many of them, that would surely make it more difficult 
> to characterise things like DNS software and operating systems than it is 
> today. Doesn't that mean less openness and transparency, and more uncertainty?

I was, of course, speaking about the often expressed disquiet about the root 
operators cabal/secret handshake society. Regardless of the reality, I have 
frequently encountered concerns about perceived inappropriate/unnecessary 
secrecy, opaqueness, and exclusion regarding root operations. 

In any event, this isn't either/or, particularly since folks can and do slave 
the root today.  The question is how can we improve root service and/or address 
(perhaps non-technical) concerns folks have regarding that service in the most 
effective/efficient way.  I'll admit it isn't clear to me that gating 
everything through the 12 organizations that through historical accident 
provide root service today is the best answer to that question, however it may 
well be. On balance though, I still believe that decentralized, locally slaved 
root service has more advantages than disadvantages.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] stealth slaving the root zone

[David Conrad]

Mark,

On May 16, 2012, at 3:26 PM, Mark Andrews wrote:
>   The root is currently small enough to have in a home CPE
>   router.  Add millions of signed delegations and it won't
>   be.

At the current artificially imposed rate limit, I suspect by the time there are 
"millions of signed delegations", CPE will be more than capable of handling 
them. 

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Joe,

On May 16, 2012, at 5:52 PM, Joe Abley wrote:
> The point was the importance of knowing who the stealth slaves are, if any 
> coordinated measurement of the root system is going to be possible.

Even ignoring folks who slave the zone now, is coordinated measurement of the 
root system realistically possible today given the 
business/political/philosophical environments of the root operators? This is 
not a rhetorical question. My impression is that we already do (a form of) 
sampling to obtain measurements.  I don't think this would change.

> This was the line of reasoning that led to you suggesting that perhaps people 
> could slave with a TSIG key under a contract with someone.

Perhaps a bit pedantic, but "agreement" does not necessarily mean "contract".  
As I said, there are numerous potential models here -- I did not mean to imply 
a contractual model was required or even necessarily desirable.

>> In the sense that you would be less dependent on entities outside of your 
>> control. If you slave the root, you (objectively) operate autonomously of 
>> any events that might occur to the root servers.
> Well, you're dependent on whoever you transfer the zone from.

Timeframes of dependence are obviously orders of magnitude different.

> All the possible outcomes I can think of that lie in this direction winds up 
> with pockets of broken DNS due to infrastructure that none of the current 
> operators can identify, and failures that affect only a subset of users so 
> that a fix is not necessarily obvious.

I believe the days in which people could set up a DNS server and forget about 
it are past due to DNSSEC so I guess I see this as a self-correcting problem.  
If a slave breaks root resolution for whatever reason, I would think the slave 
will be incentivized to fix it in order to stop their support lines getting 
saturated. If the slave is unwilling/unable to fix it, there's always 8.8.8.8 
(etc).  

>> In any event, this isn't either/or, particularly since folks can and do 
>> slave the root today.  The question is how can we improve root service 
>> and/or address (perhaps non-technical) concerns folks have regarding that 
>> service in the most effective/efficient way. 
> I agree that's the question. I guess it's probably clear to you that the 
> suggested alternative seems worse than what we have, to me.

As a member of the secret handshake society, this is not surprising (joking!).

More seriously, I acknowledge the risks associated with decentralization, 
however I do believe the benefits outweigh those risks. Unless/until all the 
root servers turn off zone transfer, ICANN decommissions their zone transfer 
servers, and the USG rewrites the contract with VeriSign to stop publishing the 
root zone on internic.net, clueful folks will be setting up root-as-slaves. Are 
you suggestion efforts should be made to stop this?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

On May 17, 2012, at 3:25 AM, Joe Abley wrote:
>> Even ignoring folks who slave the zone now, is coordinated measurement of 
>> the root system realistically possible today given the 
>> business/political/philosophical environments of the root operators?
> Yes.

[citation needed]

> However, there's a difference between making the data available for public 
> scrutiny and encouraging people to make poor operational choices about what 
> to do with it.

I think the idea is that given the data exists and (arguably) slaving the root 
addresses some concerns/can improve things, it would be nice to encourage 
people to make good operational choices about it.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Warren,

On May 17, 2012, at 9:20 AM, Warren Kumari wrote:
> On May 17, 2012, at 11:57 AM, David Conrad wrote:
>> On May 17, 2012, at 3:25 AM, Joe Abley wrote:
>>>> Even ignoring folks who slave the zone now, is coordinated measurement of 
>>>> the root system realistically possible today given the 
>>>> business/political/philosophical environments of the root operators?
>>> Yes.
>> 
>> [citation needed]
> 
> DITL

> CAIDA
> TLDMon
> DNS Measurements with RIPE Atlas Data
> DNS-OARC

Do any of these cover all instances of all root servers?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Warren,

On May 17, 2012, at 9:50 AM, Warren Kumari wrote:
>> Do any of these cover all instances of all root servers?
> Not as far as I know, but they cover enough to give you a picture of what's 
> happening…

Right. My point was that due to the various business/political/philosophical 
environments of the root operators we already do (a form of) sampling. This 
would continue to be the case in a slaved root model, albeit the level of 
sampling would depend on the arrangements (what is specified in 
agreements/contracts/eulas/HOWTOs/etc.) made.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Documenting root slave operation Re: The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Andrew,

On May 17, 2012, at 12:51 PM, Andrew Sullivan wrote:
> What is this supposed to solve?

 From earlier in the thread:

> - increased resilience to DoS attack
> - reduced dependence on a single point (ok, 13 points) of failure
> - potentially improved performance
> - greater autonomy
> - reduced political whinage about not having a root server
> - greater openness and transparency

If I'm reading your comments correctly, you're suggesting the right answer is 
to not document best practices for slaving the root and let folks figure it out 
on their own?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Documenting root slave operation Re: The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

Andrew,

On May 17, 2012, at 1:36 PM, Andrew Sullivan wrote:
> [rebuttals to suggested advantages]


I feel like this is going stuff already discussed so I won't bother going point 
by point as I suspect it would be a waste of both our time (particularly given 
your view as expressed below).

> I am claiming that there are, perhaps, best ways to do it, but that
> one shouldn't do it in the first place.  There's probably a best way
> not to get caught robbing banks, but I don't think we should publish
> manuals.  There's a best way not to get parking tickets while yet
> parking without paying, but I don't think we should publish manuals
> for that either.  This case lies somewhere between those examples.

This implies you believe slaving a root is (or should be) illegal. I would be 
surprised if you actually believed this.

It seems to me that since slaving the root is implemented today, will 
undoubtedly be implemented in the future, and that it can be argued (rightly or 
wrongly) to address some technical and non-technical issues related to root 
zone service, it would make sense to at least document the pros and cons, 
provide warnings on what to do and not do, etc.

Perhaps you would agree that there _may_ be benefits to slaving the root and 
that further study would be warranted (perhaps replicating/expanding upon the 
work David Malone did back in 2003 
(http://www.maths.tcd.ie/~dwmalone/p/rootslave03.pdf))?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

[David Conrad]

On May 18, 2012, at 4:52 AM, Simon Munton wrote:
> Absolutely. However, I guess the question I was asking is, if AXFR of the 
> ROOT zone was done as a matter of course, say on by resolvers, would the 
> increased TCP load be sustainable at the public facing nodes? or would it be 
> better to split the provision into public facing authoritative server and 
> public facing XFR provider?

This split is already being done.  See xfr.{cjr|lax}.dns.icann.org.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] I know I'm a curmudgeon but

[David Conrad]

On Jul 9, 2012, at 9:17 AM, Edward Lewis wrote:
> At 17:53 +0200 7/9/12, Benny Pedersen wrote:
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
>> 2 last zerro is bad sign

Not really. Some folks like minimal-response.

> The name isn't a problem, it's dig.  

Sounds like a "+no-ulabel" option feature request for dig ('cause dig needs 
more options).  I'm sure ISC will be happy to take your money to implement said 
feature :-).

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] thoughts on DNSSEC

[David Conrad]

On Jul 19, 2012, at 7:25 AM, wbr...@e1b.org wrote:
> And in order to pass OT&E testing, NetSol's client application must pass 
> muster.  So they must be able to handle DNSSEC.  Maybe I should give up 
> tilting at this windmill and live with DLV for now.  

IMHO, I think this sends the wrong message.  One of the highest bandwidth 
signals a for profit companies can receive is money walking away. Enough money 
walks away and priorities will get shifted. Using DLV and staying with NetSol 
merely reaffirms their de-prioritization of DNSSEC. 

Regards,
-drc


___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] "Authoritative Name Server" at Wikipedia

[David Conrad]

Paul Mockapetris founded Nominum? How offensive! I'm shocked to hear Wikipedia 
got something wrong.

Oh. Wait. Did you mean to highlight something else?

:-)

Regards,
-drc

On Aug 8, 2012, at 1:23 PM, Jan-Piet Mens  wrote:
>> From [1]:
> 
>"Authoritative Name Server
> 
>The Authoritative Name Server (ANS) is high-end commercial
>authority-only DNS server software product from Nominum, a
>company founded by Paul Mockapetris, the inventor of the DNS.
>ANS was designed to meet the needs of top level domain servers."
> 
> [sic]. Just so you know. ;) 
> 
>-JP
> 
> 
> [1] https://en.wikipedia.org/wiki/Authoritative_Name_Server
> ___
> dns-operations mailing list
> dns-operations@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

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] go daddy refuses to register NS not otherwise associated with go daddy controlled domains

[David Conrad]

On Sep 12, 2012, at 12:02 PM, Andrew Sullivan  wrote:
> On Wed, Sep 12, 2012 at 11:23:53AM -0700, Fred Morris wrote:
>> Also following from lemmas 1 and 2: The registries could obviate the
>> need for most of this charade by allowing CNAMEs above the zone cut. But
>> they don't.
> 
> I would be fascinated to learn what "CNAMEs above the zone cut" are
> supposed to do -- not to mention how they're supposed to work.

If I'm interpreting this correctly (i.e., "CNAME at zone apex"), what they're 
supposed to do is allow folks to (e.g.) have example.com, example.org, etc. 
point to www.myhostingservice.biz.  My impression is that they're supposed to 
work by returning the CNAME if the answer isn't in the zone data.  That is, if 
you have:

$ORIGIN foo.com.
@ IN NS ns.nsservers.com.
  IN MX 1 my.email.com.
  IN CNAME mysite.hostingprovider.com.

then an MX query for foo.com would return "1 my.email.com", an NS query would 
return "ns.nsservers.com" and a query for anything else would return "CNAME 
mysite.hostingprovider.com".

Of course, I'm probably misinterpreting this.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] go daddy refuses to register NS not otherwise associated with go daddy controlled domains

[David Conrad]

On Sep 12, 2012, at 1:00 PM, Jan-Piet Mens  wrote:
>> $ORIGIN foo.com.
>> @ IN NS ns.nsservers.com.
>>  IN MX 1 my.email.com.
>>  IN CNAME mysite.hostingprovider.com.
> 
> No CNAME and other data -- that is illegal. (c.f. [1] :-)
> 
>-JP
> 
> [1]: https://twitter.com/dns_borat/status/141872826536837121

Mumble.

I had a "P.S. Yes, I know CNAME at zone apex is illegal, I'm merely responding 
to Andrew's question" in my message but figured no one on the dns-operations 
list would think anyone on the list wouldn't know this.  My bad.

Yes, I'm quite well aware that CNAME and other data is illegal, thanks. 
However, non-DNS people see value in it, configure it, and then get quite 
unhappy when various rare applications (e.g., Microsoft Exchange) get confused. 
Quoting RFCs at folks, particularly when there are (arguably) reasonable 
unambiguous ways in which it could be implemented, typically generates more 
unhappiness. So it goes.

Regards,
-drc


___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] How to Launch a 65Gbps DDoS, and How to Stop One

[David Conrad]

On Sep 19, 2012, at 12:56 AM, Stephane Bortzmeyer  wrote:
>> http://blog.cloudflare.com/65gbps-ddos-no-problem
> 
> I specially appreciate the detailed responses of the CloudFlare engineer to 
> the questions asked in the comments.

Actually, Matthew is the CEO... :-)

Regards,
-drc
(consultant to CloudFlare)
 

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] dotless domains

[David Conrad]

Stephane,

On Sep 21, 2012, at 1:40 AM, Stephane Bortzmeyer  wrote:
>>  I'm not particularly against the idea of using "dotless"
>>  domains, but we know who's going to live with the support
>>  questions when users start complaining. Paul's piece on
>>  CircleID sums it up nicely. Caveat emptor.
> 
> For the consultation mentioned in Paul Vixie's original message, the
> issue is not whether one-label domains are a good idea or not but
> whether ICANN has really nothing better to do than to add yet another
> stupid regulation in an already very thick book.

According to its bylaws, ICANN's responsibility is to ensure the security and 
stability of the top level of the DNS (among other resources) at the same time 
as it is supposed to increase competition to improve service, reduce cost, 
foster innovation, blah blah blah. I'm not sure how ICANN is supposed to do 
that without 'regulations'.

The ICANN community has, through a 10+ year excruciatingly painful process, 
decided to allow for an unprecedented expansion of the root zone. Regardless of 
whether the expansion is a good idea, I personally believe that given it is 
going to occur, it is appropriate to be conservative in the degrees of freedom 
in which we can shoot ourselves in the foot. 

As documented in SAC053 (and discussed on this list), weird shit happens 
because many software developers assumed that a domain name has a dot in it. 
Given there is one root and that pretty much everybody is dependent upon it, 
you probably want to minimize the surprises that are associated with the root. 
To me, this means that you make exceptions to allow for surprises rather than 
the opposite. Over time, as software developers fix their broken code, it 
should become easier to get those exceptions for folks that care.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] keeping ICANN busy

[David Conrad]

Randy,

On Sep 21, 2012, at 5:23 PM, Randy Bush  wrote:
>> first, this discussion isn't fruitful and won't be. the place to send
>> your comments is:
>> http://www.icann.org/en/news/public-comment/sac053-dotless-domains-24aug12-en.htm
> i did

Thanks!

> is outside the root zone and none of their damned business

I understand and sympathize with this point of view, however, as a 
counter-example: wildcards in .COM were outside of the root zone, was that also 
none of ICANN's business?

My personal view: as opposed to the ccTLDs, ICANN is in a contractual 
relationship with gTLD providers and thus bears some responsibility to ensure 
the actions of those providers are in keeping with expected behavior.  Because 
the behavior of dotless domains (like wildcards in TLDs) has 
unexpected/undesirable consequences, I believe it is appropriate for ICANN, as 
a party to allowing those TLDs to be created, to limit those behaviors.  This 
is not to say I think they should be forever outlawed, rather I believe the 
parties that introduce them should be required to go through existing processes 
(ones created after the SiteFinder situation) to ensure there is foreknowledge 
of potential weirdness.

YMMV.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] dotless domains

[David Conrad]

Florian,

On Sep 24, 2012, at 12:07 AM, Florian Weimer  wrote:
> * Paul Vixie:
>> those are country code top level domains. cctld's enjoy national sovereignty
> Uhm, most of them are companies, and not subjects of international law.  Few 
> of them, however, have entered binding contracts with ICANN.


Because ccTLD administration is considered an issue of national sovereignty, 
ICANN has no license to insert itself between the government and the contractor 
the government chooses to operate the ccTLD.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Massive DNS poisoning attacks in Brazil

[David Conrad]

On Oct 2, 2012, at 12:54 PM, Paul Vixie  wrote:
> if ietf hadn't declared the dns protocol finished, and were not even now
> working to close up the dnsext working group, i'd propose that we
> develop a standard for carrying edns over tcp/80 and/or tcp/443, which
> is for most mobile users what "the internet" consists of.

What's stopping you from proposing a BOF at the next IETF (with the intent of 
spinning up a new WG if the BOF suggests that would be a good idea)?  I thought 
killing off DNSEXT was to move away from the omnibus working group model and 
back to the topic-of-interest WG model? Did the IETF Illuminati declare a 
moratorium on all new DNS work when I wasn't looking?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Massive DNS poisoning attacks in Brazil

[David Conrad]

On Oct 2, 2012, at 5:49 PM, Vernon Schryver  wrote:
> The only reasonable solution is to give stub resolvers some of the
> features of recursive resolvers including DNSSEC validation and caching
> to make the costs of DNSSEC tolerable.

Why not get rid of stub resolvers completely and simply use recursive resolvers?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Massive DNS poisoning attacks in Brazil

[David Conrad]

Vernon,

On Oct 3, 2012, at 6:38 AM, Vernon Schryver  wrote:
> Any popular scheme that works around DNS, HTTP, ssh, etc.
> man-in-the-middle attacks that become popular will be blocked,
> proxied, or hijacked unless most users normally use tools that
> detect and refuse to work with men in the middle.

You're assuming the MITM attacks are intentional. My impression is that the 
majority of the issues in getting EDNS0-requiring protocols to work are due to 
ignorance, e.g., valid DNS responses are always UDP<512bytes or valid DNS types 
are {A,MX,SOA,NS,PTR,TXT}. If this is true, than egregious hack workarounds 
like using HTTP/S as a transport will solve most of the problem (not that I 
think this is the best solution).

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Massive DNS poisoning attacks in Brazil

[David Conrad]

Vernon,

On Oct 3, 2012, at 8:57 AM, Vernon Schryver  wrote:
>> You're assuming the MITM attacks are intentional. 
> No, I assume only either that the men in the middle will back off if
> they irritate enough users or that they can be detected.

They can only back off if they're aware they are doing it.

> (Never mind corrupt DNS registrars or registries attacking DNSSEC.)

Not corrupt, just inept. Which is, of course, a much more significant threat 
today than anything DNSSEC can protect against, but that's a rant for a 
different thread.

> Breaking DNS is not accidental, not even with NAT.

Sure it is. CPE/firewall vendors have a long history of implementing the 
absolute minimum they can get away with that still sort of works (which, from a 
business perspective). In the past, DNS UDP<512 (for CPE) and limited types 
(for firewalls) sort of worked.  Then those evil greedy DNSEXT bastards went 
and modified the protocol, thereby breaking simplistic implementation 
assumptions. However, there is a lot of CPE/firewalls out there that needs to 
be upgraded.  Hence suggestions like Paul's of egregious hacks like 
DNS/TLS/HTTP.

> On the other hand, if many user computers have validating stubs that
> compute SERVFAIL for broken DNSSEC and so make gethostbyname() in
> applications fail, then many users will yell at hotel concierges for
> $15/day WiFi that doesn't work and use LTE instead of paying $15/day.
> Many hotels would change and allow EDNS0 after the sign-on.  Employers
> would either do the same or point to conditions of employement.  State
> actors would either do the same or send whiners to gulags.

I want to live in your world.  In my world, the vast majority of users would 
simply turn off the features that caused their laptops/phones/etc. to not work 
and would rarely (if ever) complain to their service provider (even if they 
knew what to complain about).

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] AT&T DNS Cache Poisoning?

[David Conrad]

On Oct 26, 2012, at 10:02 PM, Phil Pennock  wrote:
> On 2012-10-27 at 04:23 +, Tim Huffman wrote:
>> Any ideas what I can do to help my customer? This is the first time
>> we've ever had something like this...
> 
> Continue trying to reach AT&T and the other operators of DNS servers in
> that link?

If it is an attack, I suspect that's going to be a game of whack-a-mole, but 
I'd agree it's about the only thing that can be done.

> You can look at deploying DNSSEC for their domain, so that those DNS
> resolver operators who deploy validating caches will be immune to this.
> The .edu zone is signed.  If you get ben.edu signed as well, then you've
> done everything technical to help resolvers only get valid data.

Yep, assuming it is cache poisoning. I'm trying to think of alternative 
explanations, but given reports (e.g., from Frank) that the issue is affecting 
other resolvers, it's hard to see other answers. A bit odd, given ben.edu isn't 
very high up on the Alexa (et al) list...

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] AT&T DNS Cache Poisoning?

[David Conrad]

Robert,

On Oct 27, 2012, at 1:37 PM, Robert Edmonds  wrote:
> i don't think it's cache poisoning.  note that there are two out-of-zone
> nameservers for ben.edu:
...
> and that bobbroadband.com was updated recently,

Good catch! Makes sense.  I checked the history on ben.edu but didn't think to 
check the rest of the delegation tree. D'oh.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] AT&T DNS Cache Poisoning?

[David Conrad]

Bert,

On Oct 27, 2012, at 10:55 PM, bert hubert  wrote:
> Thus continuing the trend that all purported cache poisonings observed have 
> been registry hacks.

Looks that way, although it looks like this wasn't really a registry hack but 
rather what happens when a domain name expires these days. With that said, I 
still believe the most critical vulnerability in the DNS is in the security of 
the registrars.

> It appears that source port randomization works. 

Was there ever any doubt?  The question wasn't (isn't?) whether source port 
randomization would work, it was how long it would work.  Source port 
randomization simply protects the communication channel, not the data -- it 
kicks the can down the road (yet again). DNSSEC protects the data making the 
communication channel irrelevant. IMHO, it is a better long-term solution 
(folks who know my opinion on DNSSEC may now require smelling salts).

> Probably the only vulnerable servers are those behind NAT that derandomizes
> the source port. But important servers are unlikely to suffer from network
> address translation.

Heh.  Let me introduce you to CGN... :-)

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] responding to spoofed ANY queries

[David Conrad]

Vernon,

On Jan 12, 2013, at 3:11 PM, Vernon Schryver  wrote:
>> We just need to admit that self-regulation by the industry has failed
>> to address this matter adequately.
> That statement is wrong and irritating.

While I might agree it is irritating, it is so because it is true. Industry 
self-regulation has indeed failed.

> The tool is too tempting and potentially effective for too many government
> projects ranging from national hostilities to operations by law
> enforcement against criminals to expect governments to entirely
> support BCP38 or even allow its complete deployment.  This is like
> the prospects for governments and politicians limiting their own spam.

A possibility but I've not yet reached that level of cynicism. I suspect that 
when there is a sufficient demonstration of the effectiveness of source address 
spoofing against government or infrastructure targets, laws will suddenly 
appear that require ISPs to take steps to ensure the traffic they source has 
appropriate source addresses, just as laws appeared to allow lawful intercept 
of traffic.

I personally believe it is only a matter of time.

> IP source address forging is like spam.

Not really.  Spam doesn't affect anything except email.  Source address 
spoofing can affect _anything_ on the Internet.

Regards,
-drc


___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] responding to spoofed ANY queries

[David Conrad]

Paul,

On Jan 12, 2013, at 4:51 PM, Paul Vixie  wrote:
> in that having only spoofing and not amplification would mean there would be 
> a smaller problem, it's less true.

In a world of million-zombie botnets, amplification is merely icing on the cake.

> the internet is extra-legal because it is  extra-national. 


While I would agree that national laws do not apply outside of national 
boundaries (Predator drones not withstanding), pragmatically speaking, in the 
face of a massive infrastructure outage caused by an attack facilitated by 
spoofed addresses, I suspect the distinction you are making isn't going to be 
made by lawmakers.  

More to the point, I suspect such nationally-based laws would actually have a 
positive impact: it would force spoofing to move from domestic circuits to 
international circuits where the situation is slightly different.

However, I don't think this is really all that related to dns-operations... 

Regards,
-drc
 
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] responding to spoofed ANY queries

[David Conrad]

Vernon,

On Jan 12, 2013, at 5:55 PM, Vernon Schryver  wrote:
> Laws requiring that all routers support one or more of the BCP 38
> mechanisms sound rather late and redundant and wouldn't do much to
> make ISPs turn them on,

Do you really believe that in the aftermath of a successful spoofing-based 
infrastructure attack in which (say) people die that politicians and lawmakers 
would care about the fact that the law was late or redundant?

I suspect you're misunderstanding what I'm saying: while I might believe 
nationally-based legislation may (possibly) have a positive impact in that it 
might reduce domestic spoofing and change the dynamics (forcing ISPs and 
hosting providers to wipe their own butts), whether or not a law is effective 
is beside the point.  In the face of a high profile event which demonstrates 
industry self-regulation has utterly failed, politicians will feel a need to 
"do something" and the only thing they can do is pass laws.  Yes, it is yet 
another form of "security theatre", but when has that stopped anyone?

However, I'm pretty sure this isn't appropriate fodder for dns-operations...

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] getting .CW recognised in the Google ccTLD tables/databases ...

[David Conrad]

A nit:

On Jan 20, 2013, at 4:35 PM, Doug Barton  wrote:
> ISO-3166-1 table which shows valid ccTLDs in green:
> http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm

Yellow ("exceptionally reserved") code elements used for ccTLDs are also 
considered 'valid'.

> This is an uphill battle which is only going to get steeper when the next 
> round of new TLDs is released.

It might eventually improve as folks who make broken assumptions keep getting 
whined at.  And world peace might break out too.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] getting .CW recognised in the Google ccTLD tables/databases ...

[David Conrad]

Hi,

On Jan 21, 2013, at 1:07 AM, Jaap Akkerhuis  wrote:
>>> ISO-3166-1 table which shows valid ccTLDs in green:
>>> http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm
>> Yellow ("exceptionally reserved") code elements used for ccTLDs
>> are also considered 'valid'.
> Just some of them.

I was speaking from IANA/ICANN's perspective in the sense that for a 2-letter 
TLD to be delegated, the first condition that must be met is that the 2-letter 
ISO-3166 code point must be allocated by ISO-3166/MA. At this point in time, 
IANA/ICANN considers code points marked in green and in yellow in the decoding 
table as 'allocated'.  This, of course, is not the only condition for a 
2-letter TLD to be delegated out of a 2-letter ISO-3166 code point.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] What's a "suffix"?

[David Conrad]

On Jan 21, 2013, at 1:00 AM, Stephane Bortzmeyer  wrote:

> On Mon, Jan 21, 2013 at 09:25:03AM +0100,
> Stephane Bortzmeyer  wrote 
> a message of 21 lines which said:
> 
>> A "suffix" is any string ending a domain name. 
> 
> A reader even more nazi than I am suggested a definition closer to the
> DNS semantics:
> 
> A suffix is any sequence of labels ending a domain name.


The term 'suffix' isn't really the issue -- it is the subset of 'suffixes' 
deemed 'public'.

Quoting RFC 6265:

  NOTE: A "public suffix" is a domain that is controlled by a
  public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
  This step is essential for preventing attacker.com from
  disrupting the integrity of example.com by setting a cookie
  with a Domain attribute of "com".  Unfortunately, the set of
  public suffixes (also known as "registry controlled domains")
  changes over time.  If feasible, user agents SHOULD use an
  up-to-date public suffix list, such as the one maintained by
  the Mozilla project at .

I have to admit this definition has confused me for some time (e.g., what does 
"public registry" mean in this context?), but ignoring this, I find it odd that 
a registry as important to Internet operations as the "public suffix list" is 
not maintained by IANA. The fact that .CW was not automatically added to the 
list increases the oddness factor for me.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Monday rant againt the uses of the Public Suffix List

[David Conrad]

On Jan 28, 2013, at 4:31 AM, Franck Martin  wrote:
> There are plenty errors in the public suffix list for Pacific Island
> countries. I guess the operators of the ccTLDs there, never heard of the
> PSL.

Should they have?

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Another whitepaper on DDOS

[David Conrad]

On Feb 22, 2013, at 2:58 AM, Stephane Bortzmeyer  wrote:
> they keep pretending that the DNS attack in Brazil was cache poisoning, while 
> it has been widely documented for a long time 
> .

I keep running into the "Brazil had an attack that could've been prevented by 
DNSSEC" too.  Gets boring after a while.

Has there been any documented attack that would have been prevented by DNSSEC 
that one can point to?

Thanks,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Another whitepaper on DDOS

[David Conrad]

Warren,

On Feb 22, 2013, at 7:42 AM, Warren Kumari  wrote:
> http://dnssec-deployment.org/pipermail/dnssec-deployment/2012-July/006003.html

Thanks!  Missed that message somehow.

BIND 4.8. in 2010? I weep for humanity.

Regards,
-drc


___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] N-Root

[David Conrad]

On Apr 1, 2013, at 2:40 PM, Lutz Donnerhacke  wrote:
> * Stephane Bortzmeyer wrote:
>> Congratulations: you've solved the easy problem, the technical one,
>> and left open the really hard one, finding who has the legitimacy to
>> hire/fire root name server operators :-)
> 
> Oh, this problem was solved years ago. ICANN was founded to bind all efforts
> of gouvernments, private people, and orgranisations in a burocracy impossible 
> to
> understand nor to survice, with the simple goal to keep all those from
> affecting the real work of the real root server operators. The funny part
> is, that the root server operators (which does not exist as an organization)
> appears to be an organisation within ICANN. But this is only just another
> level of indirection and confusion. ICANN is very successful in doing their
> (hidden) primary goal: Let the operators work.

I love April 1.

:)

Regards,
-drc


___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Geoff Huston on DNS-over-TCP-only study.

[David Conrad]

Geoff,

I personally think this is really interesting work. A question about 
methodology:

On Aug 21, 2013, at 4:36 PM, Geoff Huston  wrote:
> - Our experiment used a modified DNS server that truncated all UDP at 512 
> bytes, and over 10 days we enlisted some 2 million end clients to perform a 
> set of tests by using online ads. The ad used a very wide geographic and 
> network variety, so there is good grounds to see this set as a reasonable 
> representative sample of the internet's end user population.

If I recall correctly, you're using a Flash thingie to do this.  Is that right?

If so, have you looked at how platforms that don't do Flash (notably, Apple 
IOS-based devices by default) behave (at least in a lab)?  I know those devices 
had an ... interesting impact on the IANA servers providing the root trust 
anchor... 

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

Doug,

On Aug 22, 2013, at 12:06 PM, Doug Barton  wrote:
> As stated before, the problem is that after the "early adopter" period is 
> over we'll be stuck with NTAs forever.

A resolver operator deploying an NTA is making an assertion that data behind a 
name is safe despite protocol indications that is may not be.

I would think corporate lawyers might quiver with ... righteous indignation in 
situations like this. As such, I have some skepticism that corporate resolver 
operators will be allowed to leave NTAs up for much longer than necessary.

But maybe I overestimate lawyer nervousness.

Regards,
-drc

___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

On Aug 22, 2013, at 3:19 PM, Paul Hoffman  wrote:
> On Aug 22, 2013, at 2:47 PM, David Conrad  wrote:
>> A resolver operator deploying an NTA is making an assertion that data behind 
>> a name is safe despite protocol indications that is may not be.
> 
> Where is that stated? I ask, because it would seem that a better description 
> would be that they are asserting that the data behind a name is unprotected 
> by DNSSSEC.

Apologies for using shorthand.  The term 'safe' in my comment meant that it was 
what was intended by the zone editor.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

On Aug 22, 2013, at 3:25 PM, Paul Vixie  wrote:
>>> A resolver operator deploying an NTA is making an assertion that data 
>>> behind a name is safe despite protocol indications that is may not be.
>> Where is that stated? I ask, because it would seem that a better description 
>> would be that they are asserting that the data behind a name is unprotected 
>> by DNSSSEC.
> agreed, and that's why, 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.  

> madness test: would we have bothered with DNSSEC at all, back in the day, if 
> NTA had been known as a definite requirement?

Sure.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

On Aug 22, 2013, at 5:06 PM, Paul Vixie  wrote:
> i just find it indescribable that a content owner who signs their zone as a 
> means to protect themselves against corruption in their secondary servers, 
> can have that tool taken out of their hands by a distant resolver operator 
> who uses NTA to keep their own phone from ringing.

They already have that regardless of NTA.  In BIND configuration language it's:

dnssec-validation no;

NTA simply gives the resolver operator the ability to limit the damage to a 
single zone instead of ALL zones.

> what i would like in local policies like nta or dlv which seek to be 
> distributed and scalable is,

A local policy pretty much by definition is not supposed to be distributed and 
scalable.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

Vernon,

On Aug 22, 2013, at 5:07 PM, Vernon Schryver  wrote:
> You get the status quo ante by simply turning off validation.

If the only solution to someone else screwing up signing is to turn off 
validation for all zones and the likelihood of someone screwing up signing 
scales with the number of folks signing, why bother ever turning validation on?

> On the contrary, NTA is a new tool for deliberately introducing new
> faults in the data you give your DNS clients.  It is a tool for lying
> to your DNS clients with data that you swear is valid and signed but
> that you know is at best unsigned and quite possibly invalid or worse.

True.  This is why I suspect corporate types will have hesitancy to use NTAs 
and wish to remove them as soon as possible.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

On Aug 22, 2013, at 5:13 PM, Paul Vixie  wrote:
> Randy Bush wrote:
>> < from a conversation with a friend wiser than i >
>> 
>> the problem is that we are going through a deployment phase where there
>> is little penalty for sloppy server ops because so few are validating.
>> 
>> patching over this to be more tolerant of sloppy server ops is going in
>> the wrong direction.  ...
> 
> +1. we're currently debating placement of first mover advantage. today
> if you sign incorrectly you lose. with NTA at scale, if you sign
> incorrectly you won't lose.

Sure you will.

You screw up signing and you instantly lose.

NTA allows other folks to not lose with you if they decide the pain of your 
screwing up to them is sufficiently high to justify manual intervention.

Not everyone will make the same value judgement and they all won't make it at 
the same time.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

On Aug 23, 2013, at 9:02 AM, Vernon Schryver  wrote:
> Eyeball networks would be best served by turning off DNSSEC.  

I believe this is what they're trying to avoid.

> Let's be honest and admit that talk about NTA today and tommorow (as
> opposed to last year) is really a statement of regret about DNSSEC and
> a demand that DNSSEC just go away.  

If this were the case, it is much easier to just put 

dnssec-validation no;

in configurations and let others get the arrows in the back.

> } > On the contrary, NTA is a new tool for deliberately introducing new
> } > faults in the data you give your DNS clients.
> } True.  This is why I suspect corporate types will have hesitancy to use =
> } NTAs and wish to remove them as soon as possible.
> On the contrary, given minimal cover such as an RFC,

RFCs provide no cover.  If a validator operator sets an NTA and their customers 
are compromised by an attack that would have otherwise been prevented by 
DNSSEC, I strongly suspect the validator operator will have set themselves up 
for an interesting set of meetings with their customers' lawyers.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

On Aug 23, 2013, at 9:19 AM, Paul Vixie  wrote:
> 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.

That's because every resolver operator would have been affected, not just 
Comcast, so the screams that Comcast (alone) was censoring NASA for http://nasawatch.com/archives/2012/01/comcast-blocks.html

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

Of course. NTA is a mechanism that allows folks who want to do the right thing 
to do so without incurring costs that folks who aren't interested in doing the 
right thing won't incur.  As more folks start validating, the playing field 
levels out and the need for NTA decreases.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

Vernon,

On Aug 23, 2013, at 11:10 AM, Vernon Schryver  wrote:
> They would be better served by `rndc validation off X hours` with 
> a limit on the "X hours" of 24 than any sort of NTA hook.

So, because one zone messes up signing, instead of opening up that one zone to 
spoofing attack you think it is better the resolver operator opens up all zones 
to spoofing attack?

This seems wrong to me.

> If you don't let them to use `rndc validation off X hours`, most will
> use `rndc nta gov` because their users will be shouting about governement
> web site problems and they won't have the time, inclination, or
> permission to discover that it's only the apod.nasa.gov.

I'd suggest that in the BCP/RFC/whatever, in addition to recommending that NTAs 
be time capped and not written to permanent storage, it should also recommend 
NTAs be written as specifically as possible.  (Should be obvious, but doesn't 
hurt to reiterate I suppose).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Implementation of negative trust anchors?

[David Conrad]

Randy,

On Aug 26, 2013, at 6:08 AM, Randy Bush  wrote:
>> So what would your advise be to the people running resolvers/validators?
> in internet operations we open a ticket with the op that has the problem.
> we even use  voice phones, if that is what it takes.

The issue is the support costs/reputation damage/etc the validator operator has 
to absorb for doing the right thing when the signer makes a mistake that a 
non-validator operator does not have to absorb. Since at this point in time, 
doing DNSSEC is purely cost with little (observable) benefit, how many times 
should a validator operator absorb those costs before the beancounters and PHBs 
say, "why are we doing this to ourselves?"

> report and fix bugs, do not paper over them.

The bug was reported to NASA and it was fixed (eventually), yet it was Comcast 
that was blamed. 

I suspect everyone agrees there should be better tools, but shit happens even 
with the best tools. Given the state of deployment, the lack of (observable) 
benefit from deployment, and the impact particularly to large eyeball networks, 
NTAs seem pretty much a requirement if you actually want DNSSEC deployed.

Regards,
-drc


___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

[David Conrad]

On Oct 14, 2013, at 7:08 PM, Paul Hoffman  wrote:
> A fictitious 100-person company has an IT staff of 2 who have average IT 
> talents. They run some local servers, and they have adequate connectivity for 
> the company's offices through an average large ISP.
> 
> Should that company run its own recursive resolver for its employees, or 
> should it continue to rely on its ISP?

Given the information provided (and interpolating): they should run their own 
recursive servers.

Running a recursive server is (should be) far easier than running the vast 
majority of other "local servers".  If it isn't, they're using the wrong 
recursive server.  With the exception of root key rollover, running a recursive 
server is a fire-and-forget type service (modulo some initial configuration to 
avoid being an open resolver).

Given the role DNS has, if they do not run their own resolver they are 
investing a vast amount of trust both in the resolver operator and the wire 
(air, in the case of wireless) between their stubs and their resolver.  That 
trust is constantly being violated through crap like redirection. Further, in a 
DNSSEC environment, validation is pointless if the channel between the resolver 
and the stub is subject to attack.  Until that channel can be protected, it is 
far safer to run local resolvers if you are interested in security.

Regards,
-drc
 




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

[David Conrad]

Florian,

On Oct 15, 2013, at 10:24 PM, Florian Weimer  wrote:
> There's a tendency to selectively block DNS traffic, which can be a
> pain to debug.  

True. Hate that. A lot.

> Various network issues might only affect DNS recursor traffic.

Given the information provided in the scenario, I feel it safe to assume a 
company of 100 with 2 full-time IT staff would have a clear channel for 
Internet traffic.  If not, I would agree with your caveat (and question the 
company's sanity).

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] ALERT: .QA CCTLD in wrong hands currently

[David Conrad]

On Oct 19, 2013, at 5:36 AM, Kauto Huopio  wrote:
> It seems that .QA TLD could be currenty in wrong hands:
> https://twitter.com/Official_SEA16/status/391339315562688513

The TLD appears to be fine (that is, it hasn't been redelegated).  Looks like 
the registry might be having issues however -- the domain referenced on the 
IANA page for registration information (domains.qa) does not resolve (NXDOMAIN).

% whois -h whois.registry.qa domains.qa
Domain Name: domains.qa
Last Modified:   19-Oct-2013 00:02:13 UTC
Registrar Name:  Qatar Domains Registry
Status:  pendingDelete (Client requested policy delete)

Registrant Contact ID:   QT50010
Registrant Contact Name: Mohamed El-Bashir - Qatar Domains Registry
Registrant Contact Email:Visit www.domains.qa

Tech Contact ID: QT50010
Tech Contact Name:   Mohamed El-Bashir - Qatar Domains Registry
Tech Contact Email:  Visit www.domains.qa

Name Server: ans0.qaregistry.qa
Name Server IP:  178.23.18.5
Name Server: ans1.qaregistry.qa
Name Server IP:  178.23.18.6
Name Server: ns1.registry.qa
Name Server IP:  178.23.16.104
Name Server: ns2.registry.qa
Name Server IP:  178.23.17.104

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

[David Conrad]

On Oct 20, 2013, at 2:16 PM, Vernon Schryver  wrote:
> Should the people working on DNS implementations prioritize making
> their DNSSEC code more robust and easier to use above or below
> addressing your issues?

I'd say "below".

Resolver operators (hopefully) want to protect their caches.  DNSSEC will do 
that, but only if people are signing their zones. There are lots of external 
parties (e.g., registries, registrars, software developers, resolver operators, 
etc) to get DNSSEC deployed and there remains very little incentive for anyone 
to sign their zones, regardless of how robust and easy it might be made.

The alternative would be to disregard current and future cache poisoning 
attacks.  Pragmatically speaking, I personally think it highly questionable to 
ignore cache poisoning vulnerabilities because something which isn't yet 
deployed to 10% of the Internet will fix it.

This would be a bit like saying "don't deploy RRL because BCP38 is the correct 
answer to the problem".

> Your work would be valuable if it helped pressure people to get busy on 
> DNSSEC.  

Seems to me the work they have done is valuable, regardless of DNSSEC.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] It's begun...

[David Conrad]

On Nov 5, 2013, at 8:52 AM, Matthäus Wander  wrote:
> The operator of xn--80asehdb. and xn--80aswg. is using a custom-made
> name server according to their version.bind.

I don't know if I'd call http://www.irondns.net "custom".

Regards,
-drc



smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Opinions sought .... have I come to the right place?

[David Conrad]

Stephan,

On Nov 7, 2013, at 7:33 AM, Stephan Lagerholm  
wrote:
> Keep in mind that most cache system are using Least Recent Used Algorithm for 
> their cache without any removal of expired records.  
> So the reason that stuff gets thrown out is not because of TTL expiry, but 
> rather because the cache is full.

That's a very interesting assertion. Do you have more data on this, e.g., how 
much memory is consumed, whether it is being consumed for positive or negative 
caches, etc.? It could have interesting implications with regards to adding new 
TLDs...

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] It's begun...

[David Conrad]

On Nov 14, 2013, at 1:41 PM, Joseph S D Yao  wrote:
> When it will get "interesting" is when there are 5000+ TLDs, 2500+ of which 
> have been abandoned because the entrepreneurs who proposed them decided it 
> wasn't fun and abandoned them, leaving lame servers galore.  Is there any 
> mechanism in place to remove lame TLDs?

http://www.icann.org/en/resources/registries/ebero

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Issue with www.bing.com resolution in Time Warner

[David Conrad]

On Nov 18, 2013, at 1:54 PM, Ashley Flavel  wrote:
> I’ve had reports that users in TWC are getting incorrect IPs back from their 
> local resolvers.  Both of the IPs below are proxy servers and sometimes 
> redirect the user to dnsrsearch.cominstead of bing.com.

Perhaps relevantly (or perhaps not):

% whois -h whois.markmonitor.com msedge.net
Server is too busy, try again later!

(connections to http://whois.markmonitor.com also time out)

Markmonitor getting DoS'd?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

[David Conrad]

Ed,

On Nov 27, 2013, at 6:00 AM, Edward Lewis  wrote:
> My excuse is - operators limit "the effort expended in fighting entropy."  
> Imagine an average operations environment operating as most environments go.
> ...
> Eventually one day something breaks and then...  ...include here "the 
> only one who can fix it has left."

I suspect this argument applies _far_ more to configuring/operating DNSSEC than 
it does to slaving the root zone, particularly when you take into account the 
rolling of the root key. For one thing, consider the time intervals between 
change events that might cause problems.

> I'd argue that the resolver admin is also incentivized to do a good or better 
> job too.  Joe's right in general,

Actually, he isn't... :)

Slaving a zone is not (or perhaps should not be, despite BIND configuration 
language) rocket science. Hand wringing about poor resolver operators being 
unable to master the complexities feels like the "don't look behind the 
curtain" scene of the Wizard of Oz.

The root represents one of the few single points of failure on the Internet. 
Continued reliance on that single point of failure, particularly in the days of 
multi-hundred of gigabit DoS attack at the flip of a switch potential, is ... 
questionable. Given the lack of ability for the Internet operations community 
to effectively deploy BCP 38, I anticipate this situation to only get worse.  
Arguments along the lines of "but anycast!" don't really help when the root 
instances you get routed to have fallen over due to the latest DoS attack. Yes, 
the system as a whole can still be said to be responsive, but you're SOL.  

I would agree that existing resolver technology makes it more challenging than 
it should be to decentralize the root. Fixing that is long overdue IMHO.

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

[dns-operations] Fwd: [perpass] A reminder, the Network is the Enemy...

[David Conrad]

Hi,

I'm taking the liberty of forwarding the following off the IETF perpass list as 
Nicholas' analysis matches my own intuition. Stephane Bortzmeyer asked on the 
same list:

> Very convincing reasoning. But I would feel better if it were actually
> tested in a lab with common resolvers. Any volunteer here?

I figure this list is a better place for volunteers for this sort of thing than 
perpass. So, anyone volunteering? :)

Regards,
-drc

Begin forwarded message:
> From: Nicholas Weaver 
> Subject: Re: [perpass] A reminder, the Network is the Enemy...
> Date: December 2, 2013 at 8:56:26 AM PST
> To: Stephane Bortzmeyer 
> Cc: perpass , Nicholas Weaver 
> 
> On Nov 27, 2013, at 7:05 AM, Stephane Bortzmeyer  wrote:
> 
>> On Wed, Nov 20, 2013 at 12:42:53PM -0800,
>> Nicholas Weaver  wrote a message of 70 lines 
>> which said:
>> 
>>> http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/
>> 
>> You mention DNSSEC twice, as a solution against some man-on-the-side
>> attacks (injecting false DNS answers).
>> 
>> The Schneier paper
>> 
>> about QUANTUM mentions packet injection but not the DNS. We don't know
>> if the NSA does DNS poisoning (but we may assume they - and other
>> actors - do it).
> 
> We can bet they do:  Its the easiest way (and just about the only way) to 
> privilege escalate a man on the side to a MITM, which is needed to use things 
> like a fake cert for SSL decryption.  
> 
> A full MITM on a backbone link is a very dangerous thing to install, because 
> failures get noticed and its also far easier to get the friendly ISP to 
> install something that is "just a tap", while installing a full MITM closer 
> to the victim may often be very difficult or downright impossible to do 
> without getting caught.
> 
>> However, if the attacker is the NSA, we have to take into account the
>> possibility that they can sign data with the root's private key, which
>> is under US management. Therefore, is DNSSEC still useful?
> 
> Actually spoofing DNSSEC replies even with knowledge of the root key is going 
> to be difficult...
> 
> Simply put, the attacker is going to need to create a fake path of trust or 
> an insecure delegation.  So, eg, assuming the target is:
> 
> target.example.com
> 
> and the attacker only has a copy of the root key.
> 
> 
> They are going to have to create a fake NSEC for .com, wait for a query for 
> .com to go to the root (to enable the fake NSEC record), and then wait until 
> the victim queries for victim.example.com or the victim does another query 
> back to the root, which makes getting caught far more likely.  
> 
> And since .com and other TLDs support DNSSEC, you could hardcode "there must 
> be DS record from . for these TLDs", this wouldn't work.  (An alternative 
> would be a fake DS, and then fake EVERY reply from .com with new RRSIGs...  
> And for that, you have a timing problem because your injector may not know 
> the answer TO inject!)
> 
> And at the same time, its still packet injection (and therefore still 
> detectable, see http://conferences.npl.co.uk/satin/papers/satin2012-Duan.pdf‎ 
> ).
> 
> 
> So although its possible that the root ZSK gets compromised by the NSA, its 
> something that I'd not only consider rather unlikely, but something that even 
> if they did, it would be something they wouldn't want to use, especially now 
> that packet injection IS on everybody's radar and if they got caught, the 
> own-goal damage against US interests (so much of DNSSEC on the authority side 
> has been driven by DHS) would be huge.
> 
> 
> --
> Nicholas Weaver  it is a tale, told by an idiot,
> nwea...@icsi.berkeley.edufull of sound and fury,
> 510-666-2903 .signifying nothing
> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Best practices for Linux/UNIX stub resolver failover

[David Conrad]

On Apr 22, 2014, at 12:26 PM, Stephane Bortzmeyer  wrote:
>>We need an independent, system-wide DNS cache, and always point
>>resolv.conf to 127.0.0.1 to solve this fundamental design
>>problem with how name resolution works on a Linux system.
>>Windows has had a default system-wide DNS cache for over a
>>decade.  It is about time that Linux catches up."
> 
> I agree and, by the way, this is also necessary to do DNSSEC
> validation in the right place (on the user's machine).

+1

In my view, the benefits of a local cache vastly outweigh the costs.  The only 
downside is it can be a real PITA if you travel and have to rely on #)@)@# 
broken middleboxes to authenticate to networks. DNS-over-HTTPS: it seems like 
it's as inevitable as the heat death of the universe (and about as desirable)...

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Uptick in number of domains losing delegation recently

[David Conrad]

Jothan,

On Apr 22, 2014, at 8:45 PM, Jothan Frakes  wrote:
> Actually I am all about making sure contact info is correct and trimming away 
> "perp" abuses.

My understanding is that the toolbox to do this is somewhat limited.  What 
other mechanisms than domain suspension would you propose?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Uptick in number of domains losing delegation recently

[David Conrad]

Dave,

On Apr 22, 2014, at 9:57 PM, Dave Warren  wrote:
>> On Apr 22, 2014, at 8:45 PM, Jothan Frakes  wrote:
>>> Actually I am all about making sure contact info is correct and trimming 
>>> away "perp" abuses.
>> My understanding is that the toolbox to do this is somewhat limited.  What 
>> other mechanisms than domain suspension would you propose?
> 
> One thought would be to defer the suspension until the domain's renewal date, 
> since users will tend to expect their domain goes down if they don't take 
> some action at this time. Since the users are contacting us and anticipating 
> interaction, it's a good time ask for updated information (and verify it)

So, there can be inaccurate/junk registration info for up to a year (does 
anyone offer less than a year?) with no way to remedy?

What's the point in collecting the data again?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Uptick in number of domains losing delegation recently

[David Conrad]

Mark,

On Apr 23, 2014, at 4:12 PM, Mark Andrews  wrote:
>> So, there can be inaccurate/junk registration info for up to a year (does
>> anyone offer less than a year?) with no way to remedy?
> What is this 1 year figure.  

The default registration period in the registrars I looked at?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Uptick in number of domains losing delegation recently

[David Conrad]

Jothan,

On Apr 22, 2014, at 11:17 PM, Jothan Frakes  wrote:
> David I think the desired outcome is honorable and important, but the 
> mechanism needs to be thought out a bit so it doesn't crush the innocent in 
> pursuit of the guilty.

My understanding that the RAA requirements have been under discussion for quite 
some time. I'm surprised there is a perception that the mechanism for registry 
accuracy is now considered to be not well thought out.

> Suspension certainly gets attention from the registrant, but for a lot of the 
> existing domains have been auto-renew / set and forget for more than a couple 
> decades in a lot of cases.  Update a contact on those where the admin doesn't 
> respond, like is exampled in the article, and have your domain deactivated.

Right, but isn't the point of the contact information to be able to actually 
contact the party responsible for the domain in the event of abuse or ill-use?  
If the admin has changed and the contact information hasn't been updated, 
doesn't that make the registration database entry useless?

> I don't have a great solution in mind, other than perhaps as other group 
> wisdom would unfold from the community suggestions that have been made around 
> the validation at renewal on existing names, so at least they are not swept 
> into the same wood chipper designed to mulch newly created domains that may 
> have bad contact info.  

Reports of abuse only apply to newly created domains?

> That seems patently reasonable because they are potentially separate issues, 
> or if they are not, the "solution space" could be separated to that it is 
> less likely to take down existing websites that are legitimate.

I guess I'm confused as to the point of the Whois database...

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] most of root NS and com's NS fail from here

[David Conrad]

Ken,

On Apr 28, 2014, at 7:43 PM, Ken Peng  wrote:
> Recent days I found most of the root nameservers, and com/net's
> nameservers can't work from here. When accessing to them I always got
> timeout.

If you're querying from inside China, probably the first thing you should check 
is to see if the root server IP addresses you're querying match the following 
list (a-m):

a.root-servers.net. - 198.41.0.4
b.root-servers.net. - 192.228.79.201
c.root-servers.net. - 192.33.4.12
d.root-servers.net. - 199.7.91.13
e.root-servers.net. - 192.203.230.10
f.root-servers.net. - 192.5.5.241
g.root-servers.net. - 192.112.36.4
h.root-servers.net. - 128.63.2.53
i.root-servers.net. - 192.36.148.17
j.root-servers.net. - 192.58.128.30
k.root-servers.net. - 193.0.14.129
l.root-servers.net. - 199.7.83.42
m.root-servers.net. - 202.12.27.33

and

a.root-servers.net. - 2001:503:ba3e::2:30
b.root-servers.net. - 
c.root-servers.net. - 2001:500:2::c
d.root-servers.net. - 2001:500:2d::d
e.root-servers.net. - 
f.root-servers.net. - 2001:500:2f::f
g.root-servers.net. - 
h.root-servers.net. - 2001:500:1::803f:235
i.root-servers.net. - 2001:7fe::53
j.root-servers.net. - 2001:503:c27::2:30
k.root-servers.net. - 2001:7fd::1
l.root-servers.net. - 2001:500:3::42
m.root-servers.net. - 2001:dc3::35

You then might want to do a traceroute to those IP addresses and see if it 
looks like they're going towards the right places (a little complicated given 
anycast routing, but if they all stay within China, you might be a bit 
suspicious).  You then might want to try pinging those IP addresses to see the 
loss/latency stats.

> I am from China, ISP telecom.
> Can you tell what happens?

Probably not definitively without more information...

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] most of root NS and com's NS fail from here

[David Conrad]

Hi,

On Apr 29, 2014, at 2:29 AM, Ken Peng  wrote:
> I checked them, all seem correct.

Yep.

> This is the traceroute info for one of the failed nameservers.
> 
> $ traceroute h.root-servers.net
> traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 60 byte packets
> 1  113.108.228.129 (113.108.228.129)  0.404 ms  0.886 ms  1.064 ms
> 2  121.14.46.93 (121.14.46.93)  0.475 ms  0.941 ms  1.227 ms
> 3  121.14.37.33 (121.14.37.33)  6.604 ms  6.958 ms  7.168 ms
> 4  121.14.37.6 (121.14.37.6)  0.369 ms  0.377 ms  0.393 ms
> 5  121.14.50.13 (121.14.50.13)  1.569 ms  1.615 ms  1.694 ms
> 6  113.108.208.97 (113.108.208.97)  4.362 ms  3.704 ms  3.624 ms
> 7   (202.97.34.202)  2.973 ms  2.976 ms  2.972 ms
> 8  202.97.61.234 (202.97.61.234)  1.429 ms  1.421 ms  1.297 ms
> 9  202.97.52.154 (202.97.52.154)  161.854 ms  161.380 ms  161.363 ms
> 10  202.97.49.158 (202.97.49.158)  157.784 ms  157.338 ms  157.326 ms
> 11  218.30.54.198 (218.30.54.198)  255.352 ms  255.432 ms  255.425 ms
> 12  los-edge-05.inet.qwest.net (67.14.22.130)  251.492 ms 
> los-edge-05.inet.qwest.net (67.14.22.106)  256.656 ms 
> los-edge-05.inet.qwest.net (67.14.22.130)  251.350 ms
> 13  65-126-18-214.dia.static.qwest.net (65.126.18.214)  360.808 ms 360.171 ms 
>  360.426 ms
> 14  143.56.244.2 (143.56.244.2)  258.023 ms  254.128 ms  254.172 ms
> 15  ap-1-1-1-nd.level3-lax.core.dren.net (140.6.244.1)  249.144 ms 248.882 ms 
>  249.567 ms
> 16  np-5-1-1-nd.sandiego.core.dren.net (140.6.0.1)  359.050 ms  358.964 ms  
> 359.087 ms
> 17  138.18.190.89 (138.18.190.89)  349.903 ms  349.947 ms  349.974 ms
> 18  * * *
> 
> The ping info:
> 
> $ ping -c 3 h.root-servers.net
> PING h.root-servers.net (128.63.2.53) 56(84) bytes of data.
> 64 bytes from 128.63.2.53: icmp_seq=1 ttl=45 time=355 ms
> 64 bytes from 128.63.2.53: icmp_seq=2 ttl=45 time=356 ms
> 64 bytes from 128.63.2.53: icmp_seq=3 ttl=45 time=257 ms
> 
> --- h.root-servers.net ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 21549ms
> rtt min/avg/max/mdev = 257.609/323.121/356.333/46.325 ms

Assuming your traceroute uses UDP, it looks to me like your source address is 
having (at least) UDP filtered once it hits the DREN. "H" might not have been 
the best choice to test since it probably isn't too surprising there might be 
reachability issues given the DREN is the US Defense Research and Engineering 
network and I believe there have been a number of UDP (DNS) amplification 
attacks originating from China. It may be that the issues you are facing with 
access to root servers can be attributed to folks trying to mitigate DDoS 
attacks.  

Are you seeing the same sort of behavior (UDP-based traceroute failing, ping 
succeeding) from the other root servers you're unable to reach?

As a mitigation, I might suggest having your resolvers slave the root zone...

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] most of root NS and com's NS fail from here

[David Conrad]

Emmanuel,

On Apr 29, 2014, at 3:05 AM, Emmanuel Thierry  wrote:
> If i'm not mistaken, the Chinese filtering is performed on a per-service 
> basis.

The (presumably UDP) based traceroute appears to get stuck just after entering 
the DREN, not at the Chinese border... 

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] about the underline in hostname

[David Conrad]

Phillip,

On May 29, 2014, at 8:17 AM, Phillip Hallam-Baker  wrote:
> And that is a problem because all numeric names are valid DNS hostnames.

Not really. An all numeric string is a valid DNS _label_, however not all 
collections of DNS labels that make up a domain name are valid as a hostname. 
Specifically, RFC 1123 states (four paragraphs down from the bit you quoted):

 [...] However, a valid host name can never
   have the dotted-decimal form #.#.#.#, since at least the
   highest-level component label will be alphabetic.

This implies that ICANN can't delegate an all-numeric TLD, and in fact, ICANN 
(in section 2.2.1.3.2, sub-section 1.2.1 of the Applicant's Guide Book) states:

"The ASCII label must consist entirely of letters (alphabetic characters a-z), 
or [a valid IDNA A-Label]"

> At any rate, given the state of the specs, I don't see cause for being
> rude when people ask questions about them.

I don't believe there is cause for being rude when people ask honest questions 
period.

> There is a document quality issue here. None of these specs would be
> published as a proposed standard today.

Very true. It is, in fact, somewhat difficult to come up with "the" DNS specs 
that define the DNS today. IIRC, there was an attempt in DNSEXT before it was 
shut down to try to address that, but it didn't attract significant interest.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] about the underline in hostname

[David Conrad]

On May 29, 2014, at 9:54 AM, Phillip Hallam-Baker  wrote:
>> This implies that ICANN can't delegate an all-numeric TLD, and in fact, 
>> ICANN (in section 2.2.1.3.2, sub-section 1.2.1 of the Applicant's Guide 
>> Book) states:
> I am rather worried when specifications rely on what is implied rather than 
> what is stated.

Well, what was stated (in RFC 1591, section 2) was:

"It is extremely unlikely that any other TLDs will be created."

We seem to have gotten over that.  More seriously, 1123 seems pretty clear to 
me, even if it is indirect: a valid hostname must have as its highest-level 
component an (all) alphabetic label. ICANN has followed that restriction in its 
acceptance of applications for new top-level domains.

I would agree that it would be preferable if there was a single document in 
which a hostname and the distinction between a hostname and a  domain name were 
clearly and unambiguously spelled out. However, there hasn't been enough energy 
for anyone to actually do this in the past, so we're sort of stuck with what 
we've got.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] First new gTLD using ICANN's "Name Collision Occurrence Management Framework"

[David Conrad]

Hi,

On Aug 28, 2014, at 11:59 PM, Patrik Fältström  wrote:
> On 29 aug 2014, at 07:04, SM  wrote:
>> At 14:13 28-08-2014, Rod Rasmussen wrote:
>>> I note that these documents speak to many of the issues being exposed here 
>>> (and yes, full disclosure, I wrote a small portion of the text/reviewed 
>>> them):
>> 
>> Was there a response to those issues?

For details of ICANN’s efforts related to name collisions, please see 
https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

> Some, but also referrals to issues still under a disclosure policy not made 
> public.

For clarification:

During the analysis associated with name collision, JAS Global Advisors 
discovered a vulnerability. In keeping with ICANN’s “Coordinated Vulnerability 
Disclosure Reporting” policy, JAS notified ICANN and the affected vendor(s). 
The exact nature of the vulnerability has not yet been released as the 
vendor(s) work to mitigate the potential impact of the vulnerability.

Full disclosure: I was on contract to JAS during their name collision efforts 
and have since joined ICANN.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Validating or not validating (ICANN controlled interruption)

[David Conrad]

Rubens,


But isn’t it better we shake these sorts of things out now?


Regards,
-drc

On Sep 3, 2014, at 5:41 AM, Rubens Kuhl  wrote:

> 
> What I can tell you is that registries and applicants suggested ICANN to not 
> require DNSSEC-signign of wildcard controlled interruption due to likely 
> differences in resolver behaviour, including some known bugs. 
> 
> Rubens
> 
> On Sep 3, 2014, at 4:00 AM, Stephane Bortzmeyer  wrote:
> 
>> BIND validates "A nimportequoi.otsuka" and yields an answer with AD bit
>> set.
>> 
>> Unbound gives back the answer but without the AD bit.
>> 
>> [Try it yourself, 'dig @unbound.odvr.dns-oarc.net A
>> nimportequoi.otsuka' and 'dig @bind.odvr.dns-oarc.net A nimportequoi.otsuka']
>> 
>> In some cases (difficult to pinpoint, depending on the resolver's
>> state), both BIND and Unbound return SERVFAIL.
>> 
>> Who's right?
>> 
>> PS: dnsviz claims that names like eb2dz5xm4s.otsuka are "secure,
>> non-existent" while they elicit an answer.
> 
> 
> ___
> dns-operations mailing list
> dns-operations@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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD

[David Conrad]

Franck,

On Sep 13, 2014, at 2:19 AM, Franck Martin  wrote:
> I’m not sure why the dot prod was not first set up to return NXDOMAIN, 
> queries logged, and then source IP contacted to warn them of such upcoming 
> change.

The source IP is a resolver, not the original querier. I’m guessing Google 
doesn’t need to be warned :).

> May be this is an insight now, may be this is something to do for ALL newly 
> introduced TLDs, set up the resolution for a month with NXDOMAIN and then 
> analyze the logs and see if it could be an issue.

You might want to look at 
https://www.jasadvisors.com/namespace-expansion-i.pdf. Interestingly, .prod had 
only 146 (filtered) unique SLDs in the DITL data. 

This was discussed in the last year or so of ‘discussions’ related to name 
collision. Trivial to game, difficulties finding the actual source, 
difficulties in establishing what could be an issue vs. a false positive, etc.

The behavior of returning 127.0.53.53 is specifically intended to interrupt 
normal behavior in a less damaging way (at least compared to the alternative 
interruption approaches) so people notice and can go and fix things. See 
https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf
 for a longer explanation of the current approach used to deal with name 
collision.

Regards,
-drc
(ICANN CTO, but speaking only for myself)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] resolvers considered harmful

[David Conrad]

On Oct 22, 2014, at 10:16 AM, Andrew Sullivan  wrote:
>>  leaving recursive resolution to the clients.  We show that the two
>>  primary costs of this approach---loss of performance and an increase
>>  in system load---are modest and therefore conclude that this approach
>>  is beneficial for strengthening the DNS by reducing the attack
>>  surface.
> 
> As long as you only count costs _to you_, externalizing costs is often
> a good idea.
> 
> There's a third cost here, and that is a large increase in costs to
> authoritative server operators.  

That cost is discussed in the paper (section 5).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] resolvers considered harmful

[David Conrad]

On Oct 22, 2014, at 10:27 AM, Florian Weimer  wrote:
> I've suggested multiple times that one
> possible way to make DNS cache poisoning less attractive is to cache
> only records which are stable over multiple upstream responses, and
> limit the time-to-live not just in seconds, but also in client
> responses.  

Why not just turn on DNSSEC?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] resolvers considered harmful

[David Conrad]

Mark,

On Oct 22, 2014, at 12:18 PM, Mark Allman  wrote:
>>> Why not just turn on DNSSEC?
>> Important zones are still unsigned, so I can understand why there is a
>> desire for altenative solutions.
> 
> Right.  It isn't like we are lacking for ways to solve the problems we
> know about.  E.g., we know how to mitigate the Kaminsky attack.  But,
> yet, still there are plenty of vulnerable resolvers (per our PAM paper
> From this past spring).  

It might be the case that a good proportion of those vulnerable resolvers 
(e.g., the stupid CPE that responds to DNS queries on their WAN ports) are 
actually already following your proposal.

> E.g., we know how to secure DNS records with
> crypto.  But, yet, broadly speaking we don't do it.  So, perhaps we need
> to re-think things.

As I understand it, you're proposing pushing the resolvers out to the edges 
(something I'm in favor of), however if you're not doing DNSSEC at the edges, 
won't those edge caches still be vulnerable to cache poisoning attack?  
Granted, the impact would be less than in the case of a shared resolver, but a 
shared resolver probably has more folks watching to detect the attack and is 
more likely to be operated by someone with clue...

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] resolvers considered harmful

[David Conrad]

Mark,

On Oct 22, 2014, at 6:07 PM, Mark Allman  wrote:
> David Conrad :
>> As I understand it, you're proposing pushing the resolvers out to the edges 
> That is not what we are proposing.  We are not suggesting resolvers be
> *moved*, but rather *removed*.  That is, clients simply do name lookup
> on their own.

Perhaps I'm being unclear and/or we're having a terminology mismatch. To be 
concrete: are you suggesting that (a) every application on an 'endpoint' 
provide its own iterative resolution, (b) the 'end point' effectively runs an 
iterative caching resolver at 127.0.0.1/::1, or (c) something else?

> All I am saying is that the resolver
> cannot do its job without accepting requests from other hosts.

As a person who frequently runs unbound listening only to 127.0.0.1 on my 
laptop, we may have differing opinions of the scope of the job of a resolver.

> David Conrad :
>> if you're not doing DNSSEC at the edges,
> Let me be clear I am not arguing against DNSSEC.  A crypto signed
> record is always better than a clear text record.  But, DNSSEC is still
> not here

It's getting there (cue Geoff Huston :)). BTW, while it may be true that 1% of 
resolvers validate as you mention in your paper, a more interesting number is 
the percentage of clients that are getting validated answers.  IIRC, I believe 
Geoff's numbers are suggesting that percentage is upwards of 20% (too lazy to 
look it up).

> and it seems to me that factoring out some of the
> intermediaries that we know sometimes both play games and have games
> played on them may well be a useful path.

I don't disagree (and have argued the same thing numerous times). By moving 
resolution "to the endpoint" (whichever way you mean it), you are presumably 
reducing the attack surface, specifically erasing the stub-to-resolver vector 
of attack, at a cost (as Andrew notes) of increased network/authoritative load 
and latency (whether that cost is negligible is an interesting question).  Of 
course, this doesn't remove the resolver-to-authoritative vector of attack, it 
lessens the impact (specifically, a successful attack only impacts the 
endpoint, not the multiple system that are using the resolver).  My point was 
that to definitively fix resolver-to-authoritative, you're going to need 
something like DNSSEC.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] resolvers considered harmful

[David Conrad]

Hi,

On Oct 23, 2014, at 6:29 AM, Jelte Jansen  wrote:
> I don't think there's an essential difference between a resolver at the
> edge and a shared resolver in any other way than the 'shared' part.

Yep, although that obviously has impact implications (fewer potential victims 
of a successful attack).

> One 'type' it haven't seen discussed it the root
> servers. Perhaps it won't be noticed in all the garbage they get right
> now, but perhaps the garbage they get will increase by a lot.

In addition to moving the resolvers to the edge, we could also include 
mirroring the root zone in those resolvers (a la Warren's draft). I believe 
that would significantly reduce the traffic to the root servers, even if there 
were a vast increase in the number of resolvers.  Of course, that doesn't help 
auth server operators farther down the tree...

> I do not think putting multiple questions in one request isn't reliably
> possible without heavy protocol changes;

I presume you mean "is" not "isn't".  Not sure it would require 'heavy' 
protocol changes -- I suspect all it would take would be to document how the 
multiple questions are packed into the query and how the multiple answers to 
those questions are packed into and parsed from the response. Since the 
question is included in the response, it shouldn't be too hard, just a small 
matter of programming... (:)).

> sure the protocol doesn't
> forbid adding more records to the question section, but it doesn't
> really have any way to answer them either; mostly because there is only
> one rcode field. So I don't think that option is as easy as the paper
> makes it out to be.

Agreed -- it would require redeployment of the entire infrastructure (albeit 
that could be done in a backwards compatible way). However, I actually think 
this would be a good enhancement to the DNS for performance/latency 
reduction/efficiency reasons.

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] resolvers considered harmful

[David Conrad]

Hi,

On Oct 23, 2014, at 10:36 AM, Paul Vixie  wrote:
> until you have done this and have results to report, you'd be wise not
> to make any claims about this possibility.

I've done so, on an off over the years (including mirroring the root zone), and 
found that it mostly just works. In the past, T-Mobile Hotspots and (currently) 
many hotels/Internet cafes can be problematic and that can definitely impact 
the people who read this mailing list due to our relatively high mobility, 
however for the vast majority of Internet users who aren't as mobile, I'm 
fairly certain local resolvers will just work.

However, with that said, I would agree that it would be an interesting area of 
study.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] cool idea regarding root zone inviolability

[David Conrad]

Patrik,

On Nov 26, 2014, at 10:40 PM, Patrik Fältström  wrote:
> FWIW, I have been working on this for a while with the Diplo foundation, and 
> I am happy to answer questions (and of course listen to concerns).

It is an interesting idea, but I don't get how it would work.  I asked Jovan 
back when he initially proposed it, but never heard back.

Is the theory behind this that governments around the world would enter into 
some sort of treaty or some other formally binding vehicle that would make the 
root zone inviolable? What would be the sanctions should the holder of the root 
zone (whoever it might be) ignore the inviolability of the root zone and how 
would they be enforced? How is that going to work given (e.g.) the US hasn't 
even been able to ratify the Treaty of the Sea and internal domestic politics 
will generally override any international agreement at politicians' whim?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] knot-dns

[David Conrad]

Hi,

I'm having a bit of trouble believing this isn't April 1.

On Dec 14, 2014, at 10:38 AM, Florian Weimer  wrote:
>> While it sounds good on phosphor, the concept of code diversity is so
>> abstract, compared to the significant operational challenges and
>> associated security challenges of operating separate systems
>> performing the same functions (sort of), but differently, that any
>> potential benefit is generally outweighed by the negative impact to
>> security posture of said challenges.

Sorry, this is simply wrong.

A monoculture invites catastrophic failure. We've seen this over and over again.

Sure, there are a wide variety of other possible failure points, but it would 
be simply insane to (say) have everyone run the exact same code base would mean 
that everyone is subject to the same Packet-of-Death.

Are you seriously arguing that it is better to have your entire infrastructure 
subject to a PoD because it's a bit more challenging to run different software 
bases?

> In particular, running different implementations behind a load
> balancer on the same public IP address can break EDNS detection by
> resolvers, and crafted queries sent to a resolver can make data
> unavailable to that resolver (until a timeout occurs).

Huh?

If you're running multiple implementations behind a load balancer and one is 
not following the protocol specifications such that it breaks EDNS detection, 
the answer is to fix the broken resolver or run a different resolver that 
responds correctly, not run an identical code base.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] knot-dns

[David Conrad]

On Dec 14, 2014, at 12:28 PM, Matthew Ghali  wrote:
> How many different responses did we see to the recent recursion cve?

What I've seen so far:

Vulnerable:
- BIND 9, Unbound, PowerDNS Recursor

Not Vulnerable:
- Nominum, dnsmasq, djbdns, BIND 8

Haven't heard about Microsoft's recursor yet.

> How does code diversity fix protocol vulns?

Because different people implement the protocol differently (as evidenced by 
the above)?

Of course, one might argue that the fact that there were different behaviors 
might suggest a bug in the protocol specification, but that doesn't argue 
against code diversity.  Code diversity is to help mitigate implementation bugs.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] knot-dns

[David Conrad]

On Dec 14, 2014, at 3:05 PM, Roland Dobbins  wrote:
> I've never run into a situation in which a monoculture would've made things 
> any worse.

?? 

Two words: Microsoft Windows.

> a) packet-of-death vulnerabilities are rare,

Sure, but they happen. For example:

- the resolver bug we're talking about
- pretty much any one of 
https://kb.isc.org/article/AA-00913/74/BIND-9-Security-Vulnerability-Matrix.html
 (not to pick on BIND, other DNS servers have DoS vulnerabilities as well of 
course)
- 
http://www.eweek.com/c/a/IT-Infrastructure/Bug-in-Juniper-Router-Firmware-Update-Causes-Massive-Internet-Outage-709180/
- http://blog.krisk.org/2013/02/packets-of-death.html
- etc.

Presumably you too can google "packet of death".

The point is that it is a risk that is easily mitigated by having diversity in 
your infrastructure.

> b) operators ought to have mechanisms in place to filter them when they do 
> show up (*not* silly 'IPS'),

Does the term "closing the barn door after the horses have fled" mean anything 
to you?  

> c) gross incompetence with a heterogeneous software base is no different than 
> gross incompetence with a monoculture - except that it's more certain.

Sorry, where is gross incompetence being demonstrated in this particular case?

> If we could ever get to the point where a monoculture was the biggest 
> challenge we face, we'd be a lot better off than we are today.

Are you really arguing that we should not have diversity in the Internet 
infrastructure because there are a bunch of problems diversity in the 
infrastructure won't fix?

> And 'a bit more challenging' is a significant understatement, especially at 
> scale.

Too bad no one has come up with something like Puppet, Chef, Ansible, etc., to 
help manage infrastructure configuration at scale.

> Worrying about software monoculture at this juncture is like worrying about 
> urban planning when you don't even have indoor plumbing.

Software diversity is a tool that network administrators use to improve 
resiliency in their infrastructure.  I agree it is not a silver bullet but if I 
was building out critical infrastructure like (oh say) a root server or a 
resolver cloud that my customers depend on, I would want to minimize the risk 
that my infrastructure was vulnerable to a single bug.

I am honestly surprised you're arguing against this.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] knot-dns

[David Conrad]

Matt,

On Dec 14, 2014, at 6:08 PM, Matthew Ghali  wrote:
> Given the set of practical issues we’re worried about today, delivering a 
> service via multiple codebases certainly isn’t a magic bullet.

Agreed. I would be surprised if anyone seriously argues that it is.

> Upon closer inspection heterogeneity might reduce exposure to catastrophe 
> much less than you’d expect.

If you built out your customer resolver cloud with a set of Nominum servers and 
Unbound servers behind load balancers, would the resolver bug being discussed 
have taken out your infrastructure?

Do you believe managing the configuration of a set of Nominum servers and 
Unbound servers (regardless of how many) is in any way challenging?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] knot-dns

[David Conrad]

Florian,

On Dec 14, 2014, at 10:55 PM, Florian Weimer  wrote:
> When you aim for diversity, you get the union of all bugs, not the 
> intersection.  

In the sense that some portion of your infrastructure may be affected by all 
bugs, sure.

The point is that _all_ your infrastructure won't be affected by a single bug.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] knot-dns

[David Conrad]

Roland,

I am suggesting that when building out infrastructure, it is prudent to try to 
minimize single points of failure.  One such single point of failure is 
reliance on a software monoculture. 

You appear to be suggesting that the Internet is so broken that taking steps to 
minimize single points of failure in your own infrastructure is pointless.

I suppose we'll have to agree to disagree.

Regards,
-drc

On Dec 14, 2014, at 8:21 PM, Roland Dobbins  wrote:
>> Two words: Microsoft Windows.
> 
> Here're two words for you:
> 
> Linux botnet.
> 
> Or three:
> 
> Linux router botnet.
> 
> Or two more:
> 
> OSX botnet
> 
> And two more, for good measure:
> 
> Android botnet.
> 
>> Presumably you too can google "packet of death".
> 
> I don't need to search for anything - I know at least as much about them as 
> you do.
> 
> Since you so conveniently elided my comments to that effect, I'll reproduce 
> them here:
> 
>> Having worked for a major vendor of telecommunications gear which is quite 
>> dominant in its space, and having dealt with packet-of-death issues from 
>> said vendor's perspective, I'm here to tell you that all this preaching 
>> about avoiding monoculture is a sideshow compared to the real issues faced 
>> every day in the trenches.
> 
> I've dealt with packet-of-death issues - router input queue wedges, for one - 
> which would've literally brought the entire Internet to its knees.
> 
> And yet, it didn't happen.
> 
> Maybe you ought to think about that before you tell me to search for anything.
> 
>> The point is that it is a risk that is easily mitigated by having diversity 
>> in your infrastructure.
> 
> Maybe so, for small networks which are operated by a handful of competent 
> admins.
> 
> But it doesn't scale, and my contention, based upon direct operational 
> experience, is that it often ends up with a negative effect on security 
> posture, as it's easier to be incompetent at securing multiple platforms than 
> it is to be incompetent at administering a single platform.
> 
>> Does the term "closing the barn door after the horses have fled" mean 
>> anything to you?
> 
> Again, see above.
> 
>> Sorry, where is gross incompetence being demonstrated in this particular 
>> case?
> 
> Gross incompetence like, say, ~27M open resolvers?  Gross incompetence, like, 
> say, storing passwords in a plaintext file on a network share in a folder 
> called 'Passwords'?
> 
> Those are the *real* types of problems we face.  Beside those, software 
> monoculture is noise.
> 
> Actually, the problems with software are even more fundamental.  Since we've 
> known about buffer overflows for about forty years, and experienced them in 
> the wild for at least the last 26 years (Morris worm, anyone?), why do 
> software developers persist in using non-typesafe languages?
> 
> Until these very basic issues are resolved (pardon the pun), software 
> diversity is a red herring.
> 
>> Are you really arguing that we should not have diversity in the Internet 
>> infrastructure because there are a bunch of problems diversity in the 
>> infrastructure won't fix?
> 
> I'm saying that, given the current levels of utter incompetence which are the 
> norm in all aspects of the IT and networking industries, expecting people who 
> are utterly unqualified to securely design, deploy, operate, and defend a 
> single platform to magically be able to do so for multiple platforms, without 
> further reducing their organizational security postures, is wishful thinking.
> 
> I'm saying that until such time as average people can design, deploy, 
> operate, and defend a single platform effectively, it's utterly unrealistic 
> to expect them to do so for multiple platforms.
> 
>> Too bad no one has come up with something like Puppet, Chef, Ansible, etc., 
>> to help manage infrastructure configuration at scale.
> 
> No - what's too bad is that due to aforementioned incompetence (as well as 
> the fact that they aren't as easy to utilize as they ought to be), they're 
> only used on a fraction of networks/deployments worldwide.
> 
>> Software diversity is a tool that network administrators use to improve 
>> resiliency in their infrastructure.
> 
> For above-average - emphasis on *average*, it actually means something - 
> personnel in focused organizations, sure.
> 
> Not at scale, and not with average personnel.  Quite the opposite, in my 
> experience and observation.
> 
>> I agree it is not a silver bullet but if I was building out critical 
>> infrastructure like (oh say) a root server or a resolver cloud that my 
>> customers depend on, I would want to minimize the risk that my 
>> infrastructure was vulnerable to a single bug.
> 
> You'd be a lot better off worrying about all the BCPs and other mechanisms 
> required to keep those services up and running, and ensuring that you've done 
> them *all*, before you start worrying about software diversity.
> 
> If you make so much progress that software diversity is your bi

Re: [dns-operations] Lack of tlsa support

[David Conrad]

On May 27, 2015, at 6:16 PM, Mark Andrews  wrote:
> Do we really have to fight to get every new type supported?

Is this a trick question?

The Empirical Evidence 8-ball would appear to say "Yes".

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@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

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

[David Conrad]

Adam,

On Oct 10, 2019, at 8:28 AM, Adam Vallee  wrote:
> In my opinion, a new C root operator should be chosen based on the fact that 
> Cogent is not fulfilling its duty to operate their root servers for the 
> benefit of the internet as a whole.
> 
> It seems to me that they are operating the root for the benefit of their 
> customers only. And the fact that they do block access from HE.net 
>  over IPv6 should be grounds for their agreement to be torn 
> up,

What agreement?

> the responsibility should be assigned to a group of ISPs.
> 

> And don't get me started on G root, or H root.

I’d recommend reading "A Proposed Governance Model for the DNS Root Server 
System” (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf)

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

[David Conrad]

Adam,

On Oct 11, 2019, at 12:36 AM, Adam Vallee  wrote:
> On Thu, Oct 10, 2019 at 10:40 AM David Conrad  <mailto:d...@virtualized.org>> wrote:
> Adam,
> 
> I’d recommend reading "A Proposed Governance Model for the DNS Root Server 
> System” (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf 
> <https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf>)
> 
> Regards,
> -drc
> I think you are only helping my point, in that it says the following in that 
> document:
> ...
> 7.RSOs must operate with integrity and an ethos demonstrating a commitment to 
> the common good of the Internet.
> ...
> 11.RSOs must be neutral and impartial.
> 
> Cogent is not activating in a commitment to the common good of the internet, 
> and they are not neutral nor impartial.

I have no comment on Cogent’s behavior in this context, however I think you 
missed my point.

RSSAC 37 is a proposal. It has not been implemented as yet, so it’s a bit hard 
to apply it in this particular case.

More directly, today, there are no agreements that dictate what root server 
operators must do.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[David Conrad]

On Nov 26, 2019, at 11:33 AM, Jim Reid  wrote:
>> On 26 Nov 2019, at 09:16, Florian Weimer > > wrote:
>> 
>> Up until recently, well-behaved recursive resolvers had to forward
>> queries to the root if they were not already covered by a delegation.
>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>> was just how the protocol was expected to work.
> 
> So what? These RFCs make very little difference to the volume of queries a 
> resolving server will send to the root. QNAME minimisation has no impact at 
> all: the root just sees a query for .com instead of foobar.com 
> . A recursive resolver should already be supporting 
> negative caching and will have a reasonably complete picture of what's in (or 
> not in) the root. RFC8198 will of course help that but not by much IMO.

It would appear a rather large percentage of queries to the root (like 50% in 
some samples) are random strings, between 7 to 15 characters long, sometimes 
longer.  I believe this is Chrome-style probing to determine if there is 
NXDOMAIN redirection. A good example of the tragedy of the commons, like water 
pollution and climate change.

If resolvers would enable DNSSEC validation, there would, in theory, be a 
reduction in these queries due to aggressive NSEC caching.  Of course, practice 
may not match theory 
(https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf).

Of course, steady state query load is largely irrelevant since root service has 
to be provisioned with massive DDoS in mind. In my personal view, the 
deployment of additional anycast instances by the root server operators is a 
useful stopgap, but ultimately, given the rate of growth of DoS attack capacity 
(and assuming that growth will continue due to the stunning security practices 
of IoT device manufacturers), stuff like what is discussed in that paper is the 
right long term strategy.

Regards,
-drc
(Speaking for myself)



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[David Conrad]

Petr,

> I think there is even more fundamental problem:
> Someone has to pay operational costs of "the new system”.

The “new system” is simply the existing network of resolvers, augmented to have 
the root zone.  As far as I can tell, the operational cost would be in (a) 
ensuring the resolver is upgraded to support obtaining the root zone and (b) 
dealing with the fetch of the root zone with some frequency.

There would be an additional cost, that of making the root zone available to 
myriads of resolvers, but I believe this is an easily handled issue.

> Personally I do not see how transition to another root-zone-distribution 
> system solves the over-provisioning problem - the new system still has to be 
> ready to absorm absurdly large DDoS attacks.

Two ways:
- greater decentralization: there are a lot more resolvers than the number of 
instances root server operators are likely to ever deploy. While an individual 
resolver might melt down, the impact would only be the end users using that 
resolver (and it is relatively easy for a resolver operator to add more 
capacity, mitigate the attacking client, etc).
- the cost of operating and upgrade the service to deal with DDoS is 
distributed to folks whose job it is to provide that service (namely the ISPs 
or other network operators that run the resolvers).  Remember that the root 
server operators have day jobs, some of which are not particularly related to 
running root service, and they are not (currently) being compensated for the 
costs of providing root service.

> Have a look at https://www.knot-dns.cz/benchmark/ 
>  . The numbers in charts at bottom of the 
> page show that a *single server machine* is able to reply *all* steady state 
> queries for the root today.
> ...
> Most of the money is today spent on *massive* over-provisioning. As an 
> practical example, CZ TLD is over-provisiong factor is in order of *hunderds* 
> of stead-state query traffic, and the root might have even more.


Yep. As mentioned before, steady state is largely irrelevant.

In my view, the fact that root service infrastructure funnels up to a (logical) 
single point is an architectural flaw that may (assuming DDoS attack capacity 
continues to grow at the current rate or even grows faster with crappy IoT 
devices) put the root DNS service at risk.  One of the advantages of putting 
the root zone in the resolver is that it mitigates that potential risk.

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)


signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[David Conrad]

[Sorry for the slow response — US holidays and a resolution not to look at my 
computer over said holidays got in the way]

> On Nov 28, 2019, at 12:42 AM, Petr Špaček  wrote:
> On 27. 11. 19 21:49, David Conrad wrote:
>> Petr,
>> 
>>> I think there is even more fundamental problem:
>>> Someone has to pay operational costs of "the new system”.
>> 
>> The “new system” is simply the existing network of resolvers, augmented to 
>> have the root zone.  As far as I can tell, the operational cost would be in 
>> (a) ensuring the resolver is upgraded to support obtaining the root zone and 
>> (b) dealing with the fetch of the root zone with some frequency.
> 
> I hypothetise that in the end requirements for "the new system for root zone 
> distribution" will be fairly close to current requirements for current DNS 
> root system... so I do not see where the cost reduction comes from.

Root zone distribution is on different timescales than root query service.  
Even if the root zone distribution service relies only on AXFR, an effective 
DDoS of that service based on SOA timers would need to be maintained for far 
longer than a DDoS against root service based on cache TTLs.  And, of course, 
folks have already been looking at distributing the root zone via stuff other 
than AXFR (e.g., HTTPS).

Further, the root servers have to respond to pretty much every DNS query that 
gets thrown at them, both UDP and TCP. A root zone distribution service would 
only need respond to AXFR/IXFR requests over TCP (and this could even be gated 
by whitelisting/blacklisting).

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Input from dns-operations on NCAP proposal

[David Conrad]

Hi,

On Jun 1, 2022, at 12:39 AM, Petr Špaček  wrote:
> On 24. 05. 22 17:54, Vladimír Čunát via dns-operations wrote:
>>> Configuration 1: Generate a synthetic NXDOMAIN response to all queries with 
>>> no SOA provided in the authority section.
>>> Configuration 2: Generate a synthetic NXDOMAIN response to all queries with 
>>> a SOA record.  Some example queries for the TLD .foo are below:
>>> Configuration 3: Use a properly configured empty zone with correct NS and 
>>> SOA records. Queries for the single label TLD would return a NOERROR and 
>>> NODATA response.
>> I expect that's OK, especially if it's a TLD that's seriously considered.  
>> I'd hope that "bad" usage is mainly sensitive to existence of records of 
>> other types like A.
> 
> Generally I agree with Vladimir, Configuration 3 is the way to go.
> 
> Non-compliant responses are riskier than protocol-compliant responses, and 
> option 3 is the only compliant variant in your proposal.

Just to be clear, the elsewhere-expressed concern with configuration 3 is that 
it exposes applications to new and unexpected behavior.  That is, if 
applications have been “tuned” to anticipate an NXDOMAIN and they get something 
else, even a NOERROR/NODATA response, the argument goes those applications 
_could_ explode in an earth shattering kaboom, cause mass hysteria, cats and 
dogs living together, etc.

While I’ve always considered this concern "a bit" unreasonable, I figure its 
existence is worth pointing out.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] How should work name resolution on a modern system?

[David Conrad]

Mark,

On Jun 15, 2022, at 6:57 PM, Mark Andrews  wrote:
> Views come down to lack of IPv4 address space forcing RFC 1918 on people

No. Split DNS existed before RFC 1918 was written. What ISC defined as “views" 
in BIND 9 is simply an implementation of an independent namespace. The fact 
that it is (now) most frequently used in the context of an independent address 
space is irrelevant.

> and security theatre that hiding names actually protects anything at all.

As people tend to use descriptive names (e.g., “printer”, “rtr”, “gw”, “Mark 
Andrew's iPhone”, etc.), useful information can be obtained from DNS names.

> After 27 years we, as an industry, shouldn’t be requiring anyone to use
> RFC 1918 addresses at all but the laggards in various places across the
> planet have prevented this being cleaned up.

Sorry, who are the Internet Police that are requiring the use of RFC 1918?  
Regardless, people are using split DNS in IPv6 too.

Regards,
-drc





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: in-addr.arpa. "A" server "loopback network" misconfiguration

[David Conrad]

Mark,

Kim indicated the relevant IETF Area Director advised that no action be taken.  
I suspect instead of reiterating what the changes are that you believe should 
be made, a more useful course of action would be to understand why the relevant 
IETF Area Director provided the advise that they did and whether the 
circumstances have changed after 6 years to change that advice.

Regards,
-drc

> On Jun 23, 2023, at 2:38 PM, Mark Andrews  wrote:
> 
> Thanks
> 
> All the zones listed in RFC6303 (as well as any added to the registry 
> subsequently) need to have insecure delegations. At the moment some do and 
> some don’t. The simplest way to do this is to delegate to the same servers as 
> those of the parent zone.  This keeps the traffic going to the same place and 
> you have a known set of machines to touch (unlike AS112).
> 
> e.g.
> 
> 127.in-addr.arpa NS a.in-addr-servers.arpa.
> …
> 127.in-addr.arpa NS f.in-addr-servers.arpa.
> 
> Where the zone contents are just the SOA record and the NS RRset.  This is 
> also the minimalist change that needs to be made.
> --
> Mark Andrews
> 
>> On 24 Jun 2023, at 02:38, Kim Davies  wrote:
>> 
>> Hi Mark, Hi all,
>> 
>> Quoting Mark Andrews on Friday June 23, 2023:
>>> There should be an insecure delegation for 127.in-addr.arpa. In the 
>>> in-addr.arpa zone. IANA have instructions from the IETF to do this in RFC 
>>> 6303.
>>> There has been a ticket open for years with IANA to correct the missing 
>>> insecure delegations.
>> 
>> I looked into this in our ticketing system. Our practice is to review
>> all open tickets at least weekly until they are resolved, so there are
>> no tickets that are left open indefinitely without activity.
>> 
>> In this case, it looks like we communicated with the relevant IETF Area
>> Director and were advised to take no further action. Since it is now
>> almost 6 years later, happy to take a fresh look at this and see what
>> may need to be done.
>> 
>> kim
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Single label queries on Windows (11)

[David Conrad]

A very long time ago (i.e., back when I was executive director of ISC and 
BINDv9.0.0 was being released) we tried to encourage people to NOT use nslookup 
as it tends to try too hard to “help", leading to all sorts of confusion, e.g., 
the kind you experienced. Instead, we recommended dig as (a) it provides all 
sorts of options that help with pretty much every form of diagnostic you can 
imagine and (b) it doesn’t try to “help”.  We obviously didn’t succeed and it’s 
far too late now (it was back then too).  Ah well…

Regards,
-drc

> On Jul 7, 2023, at 10:35 PM, Petr Menšík  wrote:
> 
> Ah, this is embarrassing. Yes, trailing dot have helped.
> 
> I am sorry for the confusion.
> 
> 
> >nslookup -type=ns org.
> Server: pihole
> Address: 192.168.88.9
> 
> Non-authoritative answer:
> org nameserver = b2.org.afilias-nst.org 
> org nameserver = a2.org.afilias-nst.info 
> org nameserver = c0.org.afilias-nst.info 
> org nameserver = b0.org.afilias-nst.org 
> org nameserver = a0.org.afilias-nst.info 
> org nameserver = d0.org.afilias-nst.org 
> 
> a0.org.afilias-nst.info  internet address = 
> 199.19.56.1
> a2.org.afilias-nst.info  internet address = 
> 199.249.112.1
> b0.org.afilias-nst.org  internet address = 
> 199.19.54.1
> b2.org.afilias-nst.org  internet address = 
> 199.249.120.1
> c0.org.afilias-nst.info  internet address = 
> 199.19.53.1
> d0.org.afilias-nst.org  internet address = 
> 199.19.57.1
> a0.org.afilias-nst.info   IPv6 address = 
> 2001:500:e::1
> a2.org.afilias-nst.info   IPv6 address = 
> 2001:500:40::1
> b0.org.afilias-nst.org   IPv6 address = 
> 2001:500:c::1
> b2.org.afilias-nst.org   IPv6 address = 
> 2001:500:48::1
> c0.org.afilias-nst.info   IPv6 address = 
> 2001:500:b::1
> d0.org.afilias-nst.org   IPv6 address = 
> 2001:500:f::1
> 
> 
> On 7/7/23 20:32, Viktor Dukhovni wrote:
>> On Fri, Jul 07, 2023 at 08:09:39PM +0200, Petr Menšík wrote:
>> 
>>> I have tested recently how Windows 11 behaves when resolving single
>>> label queries.
>>> 
>>> I have expected it might try to use LLMNR. But I did not expect it would
>>> do so also when trying nslookup, a tool which should be DNS only tool.
>>> 
>>> I have tried:
>>> 
>>> nslookup -type=ns com 9.9.9.9
>> It is not too surprising if this is also subject to the default suffix
>> list of the network "connection", which initialises the resolution
>> context, and then just overrides the server.  Have you tried:
>> 
>> nslookup -type=ns com. 9.9.9.9
>> 
>> with an explicit trailing "."?
> I thought I have tried that, but turns out I have tried that only when
> testing behavior of systemd-resolved installation on Linux, where it was 
> useless.
> On Windows it helps. Parameter -debug showed it indeed
> appends default domain suffix and does not try without it after negative
>  response.
> 
> nslookup from ISC BIND9 behaves a bit better, but that is an acceptable 
> difference.
> 
> $ nslookup -domain=home.arpa -debug -type=ns org
> 
> Server:127.0.0.1
> Address:127.0.0.1#53
> 
> 
> QUESTIONS:
> org.home.arpa, type = NS, class = IN
> ANSWERS:
> AUTHORITY RECORDS:
> ->  home.arpa
> origin = localhost
> mail addr = nobody.invalid
> serial = 1
> refresh = 3600
> retry = 1200
> expire = 604800
> minimum = 10800
> ttl = 10800
> ADDITIONAL RECORDS:
> 
> ** server can't find org.home.arpa: NXDOMAIN
> Server:127.0.0.1
> Address:127.0.0.1#53
> 
> 
> QUESTIONS:
> org, type = NS, class = IN
> ANSWERS:
> ->  org
> nameserver = b0.org.afilias-nst.org.
> ttl = 1824
> ->  org
> nameserver = b2.org.afilias-nst.org.
> ttl = 1824
> ->  org
> nameserver = c0.org.afilias-nst.info.
> ttl = 1824
> ->  org
> nameserver = d0.org.afilias-nst.org.
> ttl = 1824
> ->  org
> nameserver = a0.org.afilias-nst.info.
> ttl = 1824
> ->  org
> nameserver = a2.org.afilias-nst.info.
> ttl = 1824
> AUTHORITY RECORDS:
> ADDITIONAL RECORDS:
> 
> Non-authoritative answer:
> orgnameserver = b0.org.afilias-nst.org.
> orgnameserver = b2.org.afilias-nst.org.
> orgnameserver = c0.org.afilias-nst.info.
> orgnameserver = d0.org.afilias-nst.org.
> orgnameserver = a0.org.afilias-nst.info.
> orgnameserver = a2.org.afilias-nst.info.
> 
> Authoritative answe

Re: [dns-operations] [DNSSEC] Venezuela ccTLD broken

[David Conrad]

Hi,

On Jul 20, 2023, at 7:29 AM, Viktor Dukhovni  wrote:
> Finally, for the RSAC (yes not the right forum to formally lodge the
> question), should the root zone DS TTL still be 1 day?  Would a change
> to one hour be acceptable (aligning with it with the practice of many
> TLDs and aiding in more time recovery from mistakes)?


Haven’t thought about the implications enough to comment on the idea, however 
instead of RSSAC, this sounds to me like a question for RZERC to (eventually) 
weigh in on. In the Byzantine world of ICANN, it would need to be brought to 
RZERC by "any of [RZERC’s] members, PTI staff, or by the Customer Standing 
Committee (CSC)”, many of which are on this mailing list.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS Operations

[David Conrad via dns-operations]

--- Begin Message ---
Hi,

On Mar 2, 2024, at 4:57 AM, Lee  wrote:
> On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
> dns-operations  wrote:
>> 
>> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
>> DNS server software in the world.

ChatGPT is the weaponization of “I saw it on the Internet so it must be true."

> I'm guessing that "most popular" is what most home users use

Probably.

> - which seems to be pi-hole

I’d be very surprised if this were the case.  I’d have thought the vast 
majority of what end users would use (at least on the recursive side) would be 
whatever their ISP was providing, which I strongly suspect is not pi-hole. 

> If you want to define "most popular" as what the root servers 

This would be an odd definition of “most popular”.

> If you want to define "most popular" as DNS servers accessible on the 
> Internet, I'd kind of like to know too.  Maybe bind, maybe not.. I dunno.


Historically (as in the 80s and 90s), it was probably BIND because it was 
pretty much the only DNS package out there. My memory was that when Microsoft 
came out with Active Directory (and, to a lesser extent djbdns), BIND’s market 
share dropped rapidly. There was (is) a tool known as “fpdns” that could be 
used to provide interesting stats on what DNS servers were running, but I 
believe this stopped being effective as developers ‘fixed’ the information 
leakage fpdns made use of.

Fortunately, there are a lot of name servers, both authoritative and recursive, 
out there these days so monoculture concerns aren’t that significant anymore.

Regards,
-drc



signature.asc
Description: OpenPGP digital signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations