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

[Warren Kumari]

On Oct 16, 2013, at 9:41 AM, David Conrad  wrote:

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

And I wouldn't -- a company of 100 with 2 full-time IT folk probably have 
installed a heap-o-random "protection" devices that get in the way (some sort 
of "web firewall" type thing lSonicWall / websense, a Barracuda, etc), have 
configured their router[0] with some ACLs (because, you know, DNS only uses UDP 
53, apart for some transfer thingie which we don't use, etc. ) There is a whole 
set of these sorts of appliances, and they are sold as an easy way to add 
"security" to your network. They have (usually) web gui's and folk like to 
click all the "protections".


Companies *seem*[1] to follow the trajectory of:
1: We have 1-10 employees, we'll just use whatever Netgear / Linksys someone 
had lying around / the DSL we ordered came with. This is largely a home network.

2: We now have 10-50 employees, let's get a consultant to give us a hand. 
Wheee, now we have a Windows  "server" and a (consumer) NAS.

3: Now we have 50-200 employees and 2 IT type folk. We are a "real" company and 
so have a slew of "servers", and probably some AD goodness. We are concerned 
about all of the time that our employees are spending on Facebook and doing 
their banking and such, so we need to monitor (and curtail) their usage of this 
sort of stuff. The IT group has a budget, and a large number of companies are 
willing to provide appliances that will undoubtedly make this problem (and that 
of viruses and "insecurity" and cyber-attacks and similar scary things) go 
away. One of the IT chappies does some network stuff, and so has configured the 
firewall to be secure -- there were some checkboxes for this. He also 
configured some ACLs on the router. This consisted (largely) of blocking 
everything and then allowing bits when folk complained. There is some 
monitoring now -- but the alerts are annoying, and so go to a mailbox that 
no-one looks at.

4: We now have 200-400 employees. We realized that our IT stuff was costing way 
more money than expected, and we had many issues. We "promoted" the current 
Director of IT out of the way and hired someone new. He spent much time finding 
many kludges and cruft. Things got very squirrely for a while, but are now 
looking much better. We removed all of the user behavior modifying stuff, and, 
bizarrely enough, productivity improved…

5: 400- more. This is very similar to #4, but with a few departments and 
specialization and such…

I suspect that the majority of folk on this list have a fairly different 
experience -- but, I suspect that this is because most folk on this list are 
involved in more technical organizations…

W
[0]: Well, the random consultant / friend of someone / guy who read a 
networking book once did.
[1]: This is from chatting with a large number of my wife's customers, helping 
some friends who do consulting for companies of this sort of size, etc.

> If not, I would agree with your caveat (and question the company's sanity).

It's not their sanity, it is just that they are in the moving business or are a 
construction company, or manufacture reflectors for LED lights or run cabs to 
the airport or fix your heating system when it explodes are 3AM on a Sunday.

This is just not something that they are familiar with….

W

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

--
My memory is failing, so I changed my password to "incorrect".
That way, when I login with the wrong password the computer tells me… "Your 
password is incorrect".





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?

[Jared Mauch]

On Oct 15, 2013, at 7:28 PM, Vernon Schryver  wrote:

>> Folks like Comcast have large validating resolvers.  Their customers should 
>> use them.  Folks here are surely going to do the right thing the majority of 
>> the time.  The vast majority of others are going to set things up once and 
>> it *will* be left to rot.  This isn't intentional, but it naturally happens.
> 
> The question had nothing to do about J. Sixpack with 37 televisions,
> phones, and other devices behind a NAT router owned by and remotely
> maintained by Comcast.  Instead the question concerned a business with
> 2 IT professionals.  Relying on distant DNS servers is negligent and
> grossly incompetent for a professionally run network. 

As with many things we will have to disagree.

Not everyone has the same skill set as those on this list, and that curve goes 
down rather quickly.

- Jared
___
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] Alert: Massive increase in type A6 queries.

[Roy Arends]

Hi,

Since october the 12th, 2013, starting at approximately 16:00 UTC, we see a 
massive increase in type A6 queries. This is not due to a single resolver, but 
due to several resolver exhibiting the same behaviour. We're investigating, but 
want to alert the TLD community while asking for help as well: If anyone has 
more info, it would be greatly appreciated.

Thanks

Roy Arends
Nominet UK


___
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?

[Warren Kumari]

On Oct 16, 2013, at 10:59 AM, Jared Mauch  wrote:

> 
> On Oct 15, 2013, at 7:28 PM, Vernon Schryver  wrote:
> 
>>> Folks like Comcast have large validating resolvers.  Their customers should 
>>> use them.  Folks here are surely going to do the right thing the majority 
>>> of the time.  The vast majority of others are going to set things up once 
>>> and it *will* be left to rot.  This isn't intentional, but it naturally 
>>> happens.
>> 
>> The question had nothing to do about J. Sixpack with 37 televisions,
>> phones, and other devices behind a NAT router owned by and remotely
>> maintained by Comcast.  Instead the question concerned a business with
>> 2 IT professionals.  Relying on distant DNS servers is negligent and
>> grossly incompetent for a professionally run network. 
> 
> As with many things we will have to disagree.
> 
> Not everyone has the same skill set as those on this list, and that curve 
> goes down rather quickly.

Yup, but this *has* been an interesting thread -- it was sufficiently 
open-ended that everyone got to interpret it in whatever way wanted, and wander 
off in random but fascinating ways…

W

> 
> - Jared
> ___
> 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
> 

--
Hope is not a strategy.
  --  Ben Treynor, Google


___
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: Massive increase in type A6 queries.

[Marco Davids (SIDN)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Roy,

On 10/16/13 11:43 AM, Roy Arends wrote:

> Since october the 12th, 2013, starting at approximately 16:00 UTC, 
> we see a massive increase in type A6 queries.

No, we don't see that phenomenon for .nl.

Regards,

- --
Marco

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJeXWEACgkQ0dvyGJ94G1II1gCfRpbwE5Ul9loij8+LJ10Ukuf0
bXUAnAu+JdsgfVmLdmK8naoN85iMdtXV
=TcWL
-END PGP 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] Should medium-sized companies run their own recursive resolver?

[Daniel Kalchev]

On 14.10.13 19:08, 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?



As always, it depends.

Ideally everyone should run an validating caching resolver, preferably 
on each device. Considering we are far from this reality...


- if they intend to run the resolver on any kind of Windows, forget it. 
For many reasons. But let's say we have see enough resolver modifying 
malware.


- if their ISP is competent enough, which .. sadly few are, then using 
the ISP servers is an option. Especially if the company in questions 
does not have good resources to host/maintain "servers".


- public resolvers, such as Google or OpenDNS are an option too, 
although --- do we want to encourage the entire Internet to depend on a 
single point of failure (even if we ignore all other google considerations);


- recursive resolvers do not need much resources. I am actually curious 
why there is not large market for appliances of this kind. Perhaps 
because due to the low resource requirements, these are often installed 
in shared environments. An managed on-premises DNS resolver/cache 
appliance is the best option.


By the way, these days "average IT people" are crazy about 
virtualization "in the cloud". Running "your own" DNS resolver in the 
cloud makes little to no sense.


Daniel
___
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?

[Daniel Kalchev]

On 14.10.13 21:46, Doug Barton wrote:



We of the DNS literati tend to forget just how difficult this stuff 
really is, and how hard it is for companies to prioritize spending 
money on things that usually "just work." I can't count the number of 
times I got "emergency" calls when I was consulting about how some 
enterprise needed my help right away because "the Internet is down" 
... only to get a call 30 minutes later letting me know I wasn't 
needed because someone accidentally rebooted the right thing and now 
"the Internet" is working again. They don't care, and they don't 
*want* to care. They just want it to work.





Very true.

The solution is to turn DNS resolves to appliances, with clear labels 
"DNS resolver". Then we can leave the task of restarting the appliance 
to whoever needs Internet there. Just as they will do with any other 
device which has power switch or cord.


Adding a label "no user serviceable parts inside, in case of malfunction 
call ... " will help further.


For those who do not pretend to be ignorant, setting up and 
"maintaining" recursive DNS resolver is trivial.


By the way, 10% is ok. ;-)

Daniel
___
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?

[Bob Harold]

I think the problem with a "DNS appliance" is that it  becomes an open DNS
resolver, unless it is configured to know the subnet(s) used internally,
and updated every time that changes.  I don't think the firewall could
reasonably be asked to block only recursive DNS traffic, although perhaps
it could block all inbound DNS requests, except to an internal
authoritative DNS if you had one.  I cannot think of any other simple
workaround.  Users are likely to find some way to "turn off" the recursion
limiting anyway, like setting the internal subnet to 0.0.0.0/0, which
"solves" their problem of updating it when subnets change, but leaves it
open to the world.

-- 
Bob Harold
DNS and DHCP, University of Michigan
(disclaimer: not an official spokesman)


Date: Wed, 16 Oct 2013 13:14:06 +0300
> From: Daniel Kalchev 
> To: dns-operati...@mail.dns-oarc.net
> Subject: Re: [dns-operations] Should medium-sized companies run their
> own recursive resolver?
> Message-ID: <525e66ee.9050...@digsys.bg>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
> On 14.10.13 21:46, Doug Barton wrote:
> >
> >
> > We of the DNS literati tend to forget just how difficult this stuff
> > really is, and how hard it is for companies to prioritize spending
> > money on things that usually "just work." I can't count the number of
> > times I got "emergency" calls when I was consulting about how some
> > enterprise needed my help right away because "the Internet is down"
> > ... only to get a call 30 minutes later letting me know I wasn't
> > needed because someone accidentally rebooted the right thing and now
> > "the Internet" is working again. They don't care, and they don't
> > *want* to care. They just want it to work.
> >
> >
>
> Very true.
>
> The solution is to turn DNS resolves to appliances, with clear labels
> "DNS resolver". Then we can leave the task of restarting the appliance
> to whoever needs Internet there. Just as they will do with any other
> device which has power switch or cord.
>
> Adding a label "no user serviceable parts inside, in case of malfunction
> call ... " will help further.
>
> For those who do not pretend to be ignorant, setting up and
> "maintaining" recursive DNS resolver is trivial.
>
> By the way, 10% is ok. ;-)
>
> Daniel
>
___
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: Massive increase in type A6 queries.

[David Dagon]

1;3202;0c
On Wed, Oct 16, 2013 at 09:43:56AM +0100, Roy Arends wrote:

>  Since october the 12th, 2013, starting at approximately 16:00 UTC,
> we see a massive increase in type A6 queries. This is not due to a
> single resolver, but due to several resolver exhibiting the same
> behaviour. We're investigating, but want to alert the TLD community
> while asking for help as well: If anyone has more info, it would be
> greatly appreciated.

There are several new scanning tools in the security industry, e.g.,:


https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_durumeric.pdf

https://zmap.io

There are many new research efforts and cottage industries using these
tools.  (And these tools don't consider rfc 1262, but do have some
policy considerations in their design.)

It might be that some individuals are now querying open recrusive for
assorted qtypes.  If so, you would see (a) mostly open recursives
doing A6? queries, (b) perhaps other qytpes for the same qnames, close
in time, from the same open recursives.

If there are no other likely explanations, you might start with this
theory, and look for those symptoms.

-- 
David Dagon
da...@sudo.sh
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717
___
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?

[Chris Boyd]

On Oct 16, 2013, at 2:24 AM, Warren Kumari wrote:

> Companies *seem*[1] to follow the trajectory of:
> 1: We have 1-10 employees, we'll just use whatever Netgear / Linksys someone 
> had lying around / the DSL we ordered came with. This is largely a home 
> network.
> 
> 2: We now have 10-50 employees, let's get a consultant to give us a hand. 
> Wheee, now we have a Windows  "server" and a (consumer) NAS.


As a former provider of IT outsourcing services for companies in the 1 and 2 
categories, I'd absolutely agree with your characterizations, and add that 
these types of organizations are extremely averse to IT spending. One simple 
tweak that I liked to do on the local Windows server domain name server was to 
configure the local ISP resolvers as forwarders so that lookups for CDN cached 
content would get to the "right" place.  People usually commented "the Internet 
is much faster now."

--Chris

___
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?

[Mike Hoskins (michoski)]

-Original Message-

From: Chris Boyd 
Date: Wednesday, October 16, 2013 10:06 AM
To: "dns-operati...@mail.dns-oarc.net Operations"

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

>
>On Oct 16, 2013, at 2:24 AM, Warren Kumari wrote:
>
>> Companies *seem*[1] to follow the trajectory of:
>> 1: We have 1-10 employees, we'll just use whatever Netgear / Linksys
>>someone had lying around / the DSL we ordered came with. This is largely
>>a home network.
>> 
>> 2: We now have 10-50 employees, let's get a consultant to give us a
>>hand. Wheee, now we have a Windows  "server" and a (consumer)
>>NAS.
>
>
>As a former provider of IT outsourcing services for companies in the 1
>and 2 categories, I'd absolutely agree with your characterizations, and
>add that these types of organizations are extremely averse to IT
>spending. One simple tweak that I liked to do on the local Windows server
>domain name server was to configure the local ISP resolvers as forwarders
>so that lookups for CDN cached content would get to the "right" place.
>People usually commented "the Internet is much faster now."


It's been awhile, but I've been here as well.  While large corporations
certainly have plenty of secrets, I always found it somewhat ironic that
smaller companies are often startups whose lifeblood depends on their
intellectual property...but they routinely spend the least on protecting
what's keeping them in business.

DNS is certainly a part of this, but it's really the larger trend you
raised of being averse to almost any IT spending.  At 1-10 employees this
might make sense, but at 10-50 you really can't justify not having at
least one knowledgeable IT person in house.  As a smaller company you
certainly have to be more mindful of budget impact, but anything you save
up front will be lost in productivity, security and consultant fees...and
might ultimately put you out of business.

___
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?

[Vernon Schryver]

> From: Jared Mauch 

> > phones, and other devices behind a NAT router owned by and remotely
> > maintained by Comcast.  Instead the question concerned a business with
> > 2 IT professionals.  Relying on distant DNS servers is negligent and
> > grossly incompetent for a professionally run network. 
>
> As with many things we will have to disagree.
>
> Not everyone has the same skill set as those on this list, and that curve 
> goes down rather quickly.

I can't help noticing that Jared Mauch noticed and disagreed with my
conclusion about relying on distant DNS servers but overlooked or
ignored the security reasons compelling the conclusion.  He evidently
also overlooked the contradiction or irony in his previous note:

] Everyone else should just use either their ISP (with NXDOMAIN
] rewriting turned off) ...

] Folks like Comcast have large validating resolvers.  Their customers
] should use them.  

despite https://www.google.com/search?q=COMCAST+dns+hijacking

If you check the pages found by that URL, you'll see
  - older reports that Comcast was phasing out DNS hijacking
  - more recent reports of redirection or hijacking of 58/UDP
 packets--not just falsified results from those big Comcast DNS
 servers but packet hijacking
  - far more complication, confusion, and mystification than is
 realistic to expect a two person IT department to resolve.

It's clear that a simple, securite business DNS configuration does
*not* involve a consumer grade ISP.  (I don't mean to criticise any
particular consumer grade ISP.  They are all similar.  I'm not even
sure that DNS result or packet hijacking is a bad thing for consumer
households.)

However, not just tolerating but encouraging people without basic
network and computer competence run Internet businesses is like aviation
before the FAA.  In the first years enthusiasts bought, built, or
borrowed airplanes and went into the barnstorming or airmail businesses.
Then the air industry got government licenses and regulations.  From
Kitty Hawk to the 1926 Air Commerce Act licensing pilots was 23 years.
http://www.faa.gov/about/history/brief_history/

Whether you mark the start of public interest in the Internet with the
1972 CACM articles about the ARPANET (my DOC lab employer read those
papers, got an appropriation, and linked our computers soon after),
CSNET &co in the early 1980s when many commercial outfits with got
Internet connections, or a date between, it is more than 23 years later.

I don't like the idea of government Internet licenses, but a two person
IT shop using distant DNS servers, not to mention a consumer grade
ISP, is as culpable as buying an old potato washer to clean your
cantaloupe crop for market.  I'm uncomfortable with the criminal charges
against the Jensen brothers, but if that's what it takes to get people
learn enough and do it right ...
https://www.google.com/search?q=Jensen+cantaloupe


Vernon Schryverv...@rhyolite.com
___
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?

[Mike Hoskins (michoski)]

-Original Message-

From: Jared Mauch 
Date: Wednesday, October 16, 2013 3:59 AM
To: Vernon Schryver 
Cc: "dns-operati...@mail.dns-oarc.net" 
Subject: Re: [dns-operations] Should medium-sized companies run their
own recursive resolver?

>
>On Oct 15, 2013, at 7:28 PM, Vernon Schryver  wrote:
>
>>> Folks like Comcast have large validating resolvers.  Their customers
>>>should use them.  Folks here are surely going to do the right thing the
>>>majority of the time.  The vast majority of others are going to set
>>>things up once and it *will* be left to rot.  This isn't intentional,
>>>but it naturally happens.
>> 
>> The question had nothing to do about J. Sixpack with 37 televisions,
>> phones, and other devices behind a NAT router owned by and remotely
>> maintained by Comcast.  Instead the question concerned a business with
>> 2 IT professionals.  Relying on distant DNS servers is negligent and
>> grossly incompetent for a professionally run network.
>
>As with many things we will have to disagree.
>
>Not everyone has the same skill set as those on this list, and that curve
>goes down rather quickly.


I get your point, but also disagree with the subset of folks who maintain
DNS is so hard...  Really?  You can install, configure and keep an AD
forest running -- including keeping the intranet free of the latest trojan
scum the C*O's and sales staff bring in from the local coffee shop -- but
you can't install BIND?

The first decision for a mid-sized company (the subject doesn't say small)
is to invest something in at least one IT person.  Once you have that, I
assume that person can read.  When I first started working at small ISPs,
I didn't know much...but I read and learned.  Today that is easier than
ever!  If you can run yum/apt/whatever and Google "bind template" you're
90% there.

The remaining 10% can be easily had from most any of the available DNS
books, and all of that 10% won't be needed by most of the mid-sized
businesses.  So with minimal competency (e.g. book learning lacking real
experience) you can do better than the 80/20 generally required by IT
projects.

So I guess it's more about "lazy" vs "hard" -- or interview practices more
than DNS.  Google also makes conducting a good IT interview easier than
ever.  ;-)

___
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: Massive increase in type A6 queries.

[Edward Lewis]

On Oct 16, 2013, at 11:43, Roy Arends wrote:

> Hi,
> 
> Since october the 12th, 2013, starting at approximately 16:00 UTC, we see a 
> massive increase in type A6 queries. This is not due to a single resolver, 
> but due to several resolver exhibiting the same behaviour. We're 
> investigating, but want to alert the TLD community while asking for help as 
> well: If anyone has more info, it would be greatly appreciated.


For those that don't recall what an A6 is (and why it was effectively killed in 
Aug 2001), the A6 was thought to be an enhanced  record.  The down side was 
that A6 records required intermediate name servers to search for parts of the 
IPv6 address and assemble the various fragments they'd be getting.

Perhaps someone is testing to see if A6 is a way to eat name server (cpu) 
resources.  That's just a shot in the dark.  And likely a poor one.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis 
NeuStarYou can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

___
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?

[Vernon Schryver]

> From: Bob Harold 

> I think the problem with a "DNS appliance" is that it becomes an open DNS
> resolver, unless it is configured to know the subnet(s) used internally,
> and updated every time that changes. I don't think the firewall could
> reasonably be asked to block only recursive DNS traffic, although perhaps
> it could block all inbound DNS requests, except to an internal
> authoritative DNS if you had one. I cannot think of any other simple
> workaround. Users are likely to find some way to "turn off" the recursion
> limiting anyway, like setting the internal subnet to 0.0.0.0/0, which
> "solves" their problem of updating it when subnets change, but leaves it
> open to the world.

There is a trivial and easy way to keep a recursive DNS server intended
for an organization with a 2 person IT departement from being open to
the entire Internet.  Set the IP TTL on responses both TCP and UDP to
a small number such as 3 or 5.

There are business reasons to keep a small DNS appliance intended for
a small business with a 2 person IT department from being used by a
big outfit.  You might limit the number of DNS responses per second,
hour, or day, but it might be better instead or also to limit the
number of client IP address.  It would be trivial and easy for a DNS
appliance to require ACLs permitting no more than X IPv4 addresses and
Y IPv6 /64's.  Ship it configured with 10.0.0.0/8 and have it refuse
to accept non-RFC 1918 ACLs with too big a total.

A little monitoring of requests from unexpected IP addresses and some
GUI sugar would make it easier for users to maintain their ACLs than
what I've seen in the DNS, AD, WINS, etc. settings of a Windows box.


Vernon Schryverv...@rhyolite.com
___
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?

[Keith Mitchell]

On 10/16/2013 03:24 AM, Warren Kumari wrote:

> Companies *seem*[1] to follow the trajectory of:
> 
> 1: We have 1-10 employees, we'll just use whatever Netgear /
> Linksys someone had lying around / the DSL we ordered came with.
> This is largely a home network.
> 
> 2: We now have 10-50 employees, let's get a consultant to give us
> a hand. Wheee, now we have a Windows  "server" and a 
> (consumer) NAS.
> 
> 3: Now we have 50-200 employees and 2 IT type folk.

> 4: We now have 200-400 employees.

> 5: 400- more. This is very similar to #4, but with a few
> departments and specialization and such…

Isn't there now:

0: We have no internal IT infrastructure. Everyone BYODs, 4G/LTE on
their mobile devices is faster and less hassle than running corporate
broadband, and the internal workgroup collaboration all happens in 3rd
party clouds.

?

I'm *not* saying I think this is a Good Thing ("if stuff breaks, it's
somebody else's problem, let's see if we can figure out who..."), but
I think if we're going to have this discussion it's important to
consider some bigger trends

Keith

___
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?

[Joe Abley]

On 2013-10-16, at 11:11, Keith Mitchell  wrote:

> Isn't there now:
> 
> 0: We have no internal IT infrastructure. Everyone BYODs, 4G/LTE on
> their mobile devices is faster and less hassle than running corporate
> broadband, and the internal workgroup collaboration all happens in 3rd
> party clouds.
> 
> ?

I have done no survey, but having been through the process recently of making 
choices for things like mail, web, calendar, document collaboration, storage 
for a small start-up, google apps (as an example of your more general 
description) is a compelling choice. Requiring zero infrastructure at the 
(home) office(s) beyond whatever the kids already demand in order to watch 
netflix is a big win.

If this isn't a major trend for the medium-sized companies being discussed 
here, I don't know why. $5/month/user is ridiculousy cheap compared to the cost 
of employing two full-time IT people and sufficient herds of contractors to set 
up things like exchange, sharepoint, file servers, etc.


Joe

___
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: root-servers.net and gtld-servers.net bit-flipped variants

[Kim Davies]

(Just sending to dnsops as it seems all the right people are on this list.)

I don't know if this is still something that would interest us. He would like 
us to continue to provide him packet captures if we take over the domains to 
enable ongoing research.

I am less worried about the actual resources to do this, it is probably largely 
set and forget, but I imagine there are some liability questions. Have we dealt 
with similar things with DITL captures?

Any thoughts?

kim

Begin forwarded message:

From: Nick Freeman 
mailto:nick.free...@security-assessment.com>>
Subject: Re: root-servers.net and 
gtld-servers.net bit-flipped variants
Date: October 15, 2013 5:03:14 PM PDT
To: Kim Davies mailto:kim.dav...@icann.org>>
Cc: Sebastian Castro mailto:sebast...@nzrs.net.nz>>, 
Gregory Patrick mailto:gpatr...@verisign.com>>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Kim,

I am happy to put together a research proposal. Is there a template or
any format you would prefer to receive it in? The resources required
from ICANN would be:

a) a VM to be authoritative for the 'bit-flipped' servers, running tcpdump
b) a (preferably automated) method to deliver me a the PCAP file once
a week for processing.

Hopefully this wouldn't require too much work to be accepted.
Alternatively, I am happy to hold on to the domains until they are due
to expire.

I will give you access to the reporting interface once I have tidied
it up a bit. I believe that, while the 'bit-flip' incidents happen
quite rarely, the potential impact when one does occur can be serious
- - and would be worth conducting further research on.


Best regards
Nick

On 16/10/13 11:58, Kim Davies wrote:
Hi Nick,

Thanks for your email, and also for agreeing to take over the
domains. I would like to keep the domains until I have completed
my upcoming presentation at Kiwicon (November 9th) - the week
after that would be ideal for making the transfer.

Of course, they are your domains so it is up to you how you wish to
do this.

Something I am hoping for is that, while handing over the
domains, to continue carrying out the research. If possible, I
would like to receive a data feed (pcaps, ideally) of the
requests for the bit-flipped domains, so I can continue trying to
correlate events (heat waves, increased cosmic ray activity,
radiation issues etc) with servers being victims of bit flip
attacks. I would of course be happy to share my findings from
this with you. Would this be possible please?

Based on what we have been told so far, our only intention so far
was basically to hold the domain registrations but not do anything
with them. i.e. probably hold them undelegated. Anything that would
involve standing up servers or other facilities has not been
discussed within our organisation.

Whether it makes sense for ICANN to do so will depend on what such
research is expected to result in, and whether that is in line with
our mission. If you have a specific research proposal in mind on
what you'd like us to do I can propose it internally. Likely such
activity would be sponsored by our Security department, rather than
IANA where I am based.

Secondly, do you have any plans on contacting the registrants of
the remaining 6 root-server bitflips?

I had no plans, but as with above, that is merely due to a lack of
data on what the risks are and whether they are substantial enough
to warrant significant actions by ICANN in this area. Even though
we regulate aspects of the domain name system, we have no power to
take these domains away from valid registrants under current
policy, so anything along these lines would involve appealing to
the existing registrant to come to some arrangement.

And finally - I ask only due to the number of domains - is there
any possibility of part of the cost of the domain registration
being returned to me? I used GoDaddy as a registrar as they had
what I found as the best bulk deal - but 101 domains still comes
to over NZD1000 per annum. I completely understand if this is not
possible but if it is, it would be appreciated.

Given your thoughts above about this not being a simple handover
but an ongoing commitment by ICANN, I think it makes the most sense
to put together a proposal, and if you wish to have reimbursement
as part of it, I would suggest including it.

My discussions internally have basically been on the level this is
cost neutral to us in the short term, and I received agreement it
made sense on that basis. If I need to obtain budget for this
activity, and dedicate ongoing resources to manage services such as
packet collection, I will need to have a further conversation to
determine if we are able to make more of a commitment on this
project.

I am still in the process of writing slides but would be happy
to share them with you prior to the presentation, and if you
like, am also happy to the provide access to the reporting
interface for the data I have collected so far (once 

Re: [dns-operations] root-servers.net and gtld-servers.net bit-flipped variants

[Kim Davies]

Hi folks,

I sent this to the wrong list, my apologies. Please disregard.

kim


___
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?

[James Cloos]

> "PH" == Paul Hoffman  writes:

PH> Should that company run its own recursive resolver for its
PH> employees, or should it continue to rely on its ISP?

*Every* site should run its own (preferably verifying) resolver.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6
___
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?

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/16/2013 1:44 PM, James Cloos wrote:

>> "PH" == Paul Hoffman  writes:
> PH> Should that company run its own recursive resolver for its
> PH> employees, or should it continue to rely on its ISP?
>
> *Every*  site should run its own (preferably verifying) resolver.

I have no problem with that as long as they are not open resolvers -- we
already have somewhere in the neighborhood of 28-30 million of them that
pose a direct threat to the health & wellbeing of the Internet at-large
because they can be used to facilitate DNS amplification attacks.

$.02,

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 10.2.0 (Build 2317)
Charset: utf-8

wj8DBQFSXv3jq1pz9mNUZTMRAtqnAKCP+X8u6KY7bM8tcRbE4OqR3vdFSgCfUFsP
lYcnCGhTPGDYZ2Z1atVB6/8=
=VvXW
-END PGP SIGNATURE-


--
Paul Ferguson
Vice President, Threat Intelligence
Internet Identity, Tacoma, Washington  USA
IID --> "Connect and Collaborate" --> www.internetidentity.com
___
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?

[Jared Mauch]

Comcast doesn't give me broken name servers to use, there is no cognitive 
dissonance here :-)

You are a DNS expert. Most end users when DNS fails think everything has 
failed, including the network.

I type URLs into my browser. Do you know how many people type google into the 
google search box? Or the yahoo box?

You seem disconnected from the average user and average user tech support.

Even small networks (I have a friend with a ~100 user wisp) shouldn't run their 
own caches. The economics of it don't support this.

- Jared 

> On Oct 16, 2013, at 10:37 AM, Vernon Schryver  wrote:
> 
> Folks like Comcast have large validating resolvers.  Their customers
> ] should use them.  
> 
> despite https://www.google.com/search?q=COMCAST+dns+hijacking
> 
> If you check the pages found by that URL, you'll see
>  - older reports that Comcast was phasing out DNS hijacking
>  - more recent reports of redirection or hijacking of 58/UDP
> packets--not just falsified results from those big Comcast DNS
> servers but packet hijacking
>  - far more complication, confusion, and mystification than is
> realistic to expect a two person IT department to resolve.
___
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?

[Jared Mauch]

Yes, configuring bind is harder than it seems. Same for routers. :-)

> On Oct 16, 2013, at 10:58 AM, "Mike Hoskins (michoski)"  
> wrote:
> 
> 
> I get your point, but also disagree with the subset of folks who maintain
> DNS is so hard...  Really?  You can install, configure and keep an AD
> forest running -- including keeping the intranet free of the latest trojan
> scum the C*O's and sales staff bring in from the local coffee shop -- but
> you can't install BIND?
___
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?

[Jared Mauch]

Understanding how this works is not networking or DNS 101. Limiting the scope 
with TTL isn't that easy.

Can you point someone at docs for how to do that in a point and click fashion?

> On Oct 16, 2013, at 11:03 AM, Vernon Schryver  wrote:
> 
> There is a trivial and easy way to keep a recursive DNS server intended
> for an organization with a 2 person IT departement from being open to
> the entire Internet.  Set the IP TTL on responses both TCP and UDP to
> a small number such as 3 or 5.
___
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?

[Jared Mauch]

> On Oct 16, 2013, at 4:58 PM, Paul Ferguson  wrote:
> 
> 
> 
> I have no problem with that as long as they are not open resolvers -- we
> already have somewhere in the neighborhood of 28-30 million of them that
> pose a direct threat to the health & wellbeing of the Internet at-large
> because they can be used to facilitate DNS amplification attacks.

90 percent of these are devices that folks here seem to assert the end-user are 
capable of managing or upgrading and intelligently operating. (90% is based on 
the rDNS of the devices matching typical dynamic user range regex, including 
small businesses that depend on DNS).

That's not the case, they are not well maintained. My ongoing measurements are 
proof of this. I await the trends to change and show some improvement, but I 
don't expect it.
___
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?

[James Cloos]

> "PF" == Paul Ferguson  writes:

JC>> *Every*  site should run its own (preferably verifying) resolver.

PF> I have no problem with that as long as they are not open resolvers

Of course.

Most such devices will be behind a NAT router anyway.  At least for now.

And I expect that when v6 is the norm, most sites will run decent
firewalls on the routers -- they'll be used to the idea from the
current need for NAT routing -- with incoming port 53 blocked.
Or routed to an authoritative-only dns box.

It would help if there were small, affordable boxen available which less
technical sites can plop on their lan to do a basic task like dns.

Perhaps a run-from-ram box with a line of write-locked SD cards each
with a mostly-preconfigured single-purpose distribution.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6

___
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?

[Vernon Schryver]

> From: Jared Mauch 

> Understanding how this works is not networking or DNS 101. Limiting
> the scope with TTL isn't that easy.
>
> Can you point someone at docs for how to do that in a point and click fashion?

Can you address the issues instead of dragging in irrelevancies?

The operating system on that hypothetical, as yet non-existent "DNS
appliance" that could use the TTL to keep it from being an open resolver
might need a new setsockopt or socket ioctl to set a per socket TTL.
You have my opinion as someone who has done such things professionally
that in at least the BSD stack, such a change, if necessary, would be
trivial.  I strongly suspect that would also be trivial in the Linux
code.  That assumes that your DNS server code does not use other,
existing but less application-programmer friendly mechanisms.

GUI pointing and clicking to maintain a suitable stanza into a DNS
server text configuration file would be almost as trivial.

   ...

} From: Jared Mauch 

} Comcast doesn't give me broken name servers to use, there is no cognitive 
dissonance here :-)

That statement asserts facts not in evidence.

} You are a DNS expert. Most end users when DNS fails think everything has 
failed, including the network.
}
} I type URLs into my browser. Do you know how many people type google into the 
google search box? Or the yahoo box?
}

Yes, and as I wrote, it is unrealistic, unnecessary, and wrong to
expect users such as the IT professionals in that 2-person department
to determine whether an ISP DNS servers is broken.  It should be
realistic and should be required that one of them to be able to determine
whether BIND or NSD on a whitebox is working.  The intentional breakage
of ISP DNS servers is too subtle.  It's not merely NXDOMAIN rewriting
but other craziness like  filtering for IPv4 clients.  (Again, in
the context of consumer households, that crazy breakage might be good
and even necessary.)



} You seem disconnected from the average user and average user tech support.

Why do you always descend to ad hominem?  I have some experience with
"average user tech support," thank you very much.  Your mail was to
me delayed while I wrestled with CenturyLink's Asian (he refused to
be more specific, but I heard Hindi when he got confused with his mute
button and in the background when his squelch hiccuped) "average user
tech support" that wanted me to "reboot the modem" and tell him the
version of Windows on "the" computer.  (After the third time I blew
up, he started listening and called someone who helped him, so that
we ended the call with my DSL carrier restored and the ticket closed.)

Why do you insist on talking about irrelevant scenarios involving end
users?  Neither of the people in that 2 persion IT department would
admit being average end users.  Of course they would not know as much
about DNS as they might, but they could understand that hypothetical
DNS appliance at least as well as their LDAP, AD, HTTP, and SQL servers.

More important, why do you ignore my point about required minimum
competence?  Long ago, you could buy an airplane and go into business
with it without getting permission.  Not so long ago, you could buy
or lease 5 acres and grow olives, melons, or corn with no worries about
licenses or going to jail if an animal happens to defecate upstream.
Neither is possible today.  (In at least Calif you need state health
inspections and licenses to sell your own olive oil.)  You don't need
a degree in aeronautical engineering to be a pilot or in communicable
diseases to farm, but you must demonstrate minimal competence.  It
should also not be possible to get a job in the 2 person IT department
at issue without understanding enough about DNS to install and maintain
a white box run a simple BIND, NSD, or other recursive DNS server.


} Even small networks (I have a friend with a ~100 user wisp) shouldn't run 
their own caches. The economics of it don't support this.

"Economics" in this century have nothing to do with where and when
local DNS caches are good or bad, necessary or useless.

I am offended on behalf of those hypothetical IT professionals by your
persistent infantilizing them.  Attitudes like yours in ISPs are why
there there is so little BCP38 compliance and so many open resolvers.
If ISPs would refuse to route packets to customers that can't comply
with BCP38 or that run unnecessary open resolvers or open resolvers
unprotected by rate limiting, then a lot of problems would go away.


Vernon Schryverv...@rhyolite.com
___
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