large organization nameservers sending icmp packets to dns servers.

Mailman List Mirror (Read Only)
1

From: Joe Abley <jabley@ca.afilias.info>
Date: Tue, 7 Aug 2007 15:19:30 -0400
Sender: owner-nanog@merit.edu

>
>>> All things being equal (which they're usually not) you could use
>>> the ACK
>>> response time of the TCP handshake if they've got TCP DNS resolution
>>> available. Though again most don't for security reasons...
>>
>> Then most are incredibly stupid.
>
> Those are impressively harsh words.

But they are hard to argue with.

>> In addition, any UDP truncated response needs to be retried via
>> TCP- blocking it would cause a variety of problems.
>
> Since we are talking about authorities here, one can control the
> size of ones responses.

"Never reply with anything big and hence never set TC" seems like a
reasonable, expedient way to circumvent the problem of wholesale 53/
tcp-blocking stupidity. It doesn't make the behaviour any less
stupid, though.

The "security" argument looks even more bizarre when you consider
what the DO bit in a request will do in general to the size of a
response, in the case of an authority server which has signed zone data.

This has been a pain for me for years. I have tried to reason with
security people about this and, while they don't dispute my reasoning,
they always end up saying that it is the "standard" practice and that,
lacking any evidence of what it might be breaking, it will continue to
be blocked. And I don't mean small companies, either. One of the biggest
issues I have is with one of the countries largest government funded
research labs.

Wonder how often DNSSEC might make non-transfer queries tickle this and
really break things? (Assuming we ever get wide use of DNSSEC.)

2

This has been a pain for me for years. I have tried to reason with
security people about this and, while they don't dispute my reasoning,
they always end up saying that it is the "standard" practice and that,
lacking any evidence of what it might be breaking, it will continue to
be blocked. And I don't mean small companies, either. One of the biggest
issues I have is with one of the countries largest government funded
research labs.

Can someone, anyone, please explain to me why blocking TCP 53 is considered such a security enhancement? It's a token gesture and does nothing to really help improve security. It does, however, cause problems.

You have no way of knowing why a client might want or need to contact you via TCP 53 for DNS- so why would you block them?

The fact is most people, to this day, still believe that TCP 53 is only used for axfr's.

Someone was only too happy to point out to me that he would never create a record larger than 512 bytes so why should they allow TCP queries? The answer is simple- because they are supposed to be allowed. By disallowing them you are breaking the agreed upon rules for the protocol. Before long it becomes impossible to implement new features because you can't be sure if someone else hasn't broken something intentionally.

If you don't like the rules- then change the damned protocol. Stop just doing whatever you want and then complaining when other people disagree with you.

-Don

3

Hi,

Can someone, anyone, please explain to me why blocking TCP 53 is considered such a security enhancement? It's a token gesture and does nothing to really help improve security. It does, however, cause problems.

It has been argued that it is a bit harder to download/bootstrap shell code/arbitrary root kit through the latest BIND vulnerability (or whatever) via a 512 UDP packet than it is through TCP.

Someone was only too happy to point out to me that he would never create a record larger than 512 bytes so why should they allow TCP queries? The answer is simple- because they are supposed to be allowed.

Yep. However, as the always amusing Dr. Bernstein points out, if you don't care about zone transfer, DNS-over-TCP is an optional part of the standard (per RFC 1123).

Before long it becomes impossible to implement new features because you can't be sure if someone else hasn't broken something intentionally.

Yep. And then they scream at you when you tickle their brokenness. It sucks.

Rgds,
-drc

P.S. Note that I think blocking TCP/53 is really stupid.

4

[...]

If you don't like the rules- then change the damned protocol. Stop just doing whatever you want and then complaining when other people disagree with you.

I think this last part is the key.

Remember the old adage: "My network, My rules"? Have we forgotten that?

Should I not block ports for MS protocols when a new worm spreads because it would break the E-2-E principal? What about spam filtering? Or a myriad of other things. Everyone here is breaking some RFC somehow. And most of us don't give a rats ass. Which is the way it should be.

But when you decide that YOUR violation is MY problem to fix, then you are just being silly. And worse, annoying.

Let's all just agree to run our own networks the way we damned well please, as long as we are not hurting anyone else. We just have to define "omplaining to you about things I b0rk'ed by myself" as "hurting you". Which isn't a stretch, support costs money, and costing me money because you screwed up is definitely hurtful.

5

The answer is simple- because they are supposed to be allowed. By

disallowing

them you are breaking the agreed upon rules for the protocol. Before
long it becomes impossible to implement new features because you can't

be

sure if someone else hasn't broken something intentionally.

I don't really have a dog in this fight about TCP 53. It does seem to me
that it's a bit black and white to treat the RFCs as religious texts.
It's important to follow them wherever possible, but frankly they don't
foresee the bulk of the future security issues that usually materialize.
So if a feature of the RFC isn't working for you security-wise, I
believe it's your call to break with it there. As someone else said,
don't complain when it breaks other things as well however.

If you don't like the rules- then change the damned protocol. Stop

just

doing whatever you want and then complaining when other people

disagree

with you.

I think its possible to disagree without calling other folks stupid...

Best Regards,
Jason

6

> If you don't like the rules- then change the damned protocol. Stop
> just doing whatever you want and then complaining when other people
> disagree with you.

I think this last part is the key.

Remember the old adage: "My network, My rules"? Have we forgotten that?

No, that's the point. The Internet is based on cooperation. You can run your
network however you want, but if you fail to cooperate, other people will
exercise their right to run their network how they want by blacklisting you.

Should I not block ports for MS protocols when a new worm spreads
because it would break the E-2-E principal? What about spam
filtering? Or a myriad of other things. Everyone here is breaking
some RFC somehow. And most of us don't give a rats ass. Which is
the way it should be.

Fine, so long as you don't break the promises you make to other networks. If
you do that, you wreck the cooperation fabric the Internet is based on.

But when you decide that YOUR violation is MY problem to fix, then
you are just being silly. And worse, annoying.

Let's all just agree to run our own networks the way we damned well
please, as long as we are not hurting anyone else. We just have to
define "omplaining to you about things I b0rk'ed by myself" as
"hurting you". Which isn't a stretch, support costs money, and
costing me money because you screwed up is definitely hurtful.

When you promise to provide a service to anyone who asks for it and then
fail to, you impose costs on other people. Failing to resolve names that you
claim you will resolve is just such a failure. It forces other people's
resolvers to do extra work to get the information they need or they just
can't get it.

This is, IMO, the type of cooperation failure that justifies blacklisting.

DS

7

If you don't like the rules- then change the damned protocol. Stop
just doing whatever you want and then complaining when other people
disagree with you.

I think this last part is the key.

Remember the old adage: "My network, My rules"? Have we forgotten that?

No, that's the point. The Internet is based on cooperation. You can run your
network however you want, but if you fail to cooperate, other people will
exercise their right to run their network how they want by blacklisting you.

So we are in violent agreement.

IOW: Your first word is incorrect. It _IS_ my network, and you agree it is my network, and you agree I am allowed to run it as I please. In return, I agree you can run your network as you please, even if that includes blacklisting me.

Should I not block ports for MS protocols when a new worm spreads
because it would break the E-2-E principal? What about spam
filtering? Or a myriad of other things. Everyone here is breaking
some RFC somehow. And most of us don't give a rats ass. Which is
the way it should be.

Fine, so long as you don't break the promises you make to other networks. If
you do that, you wreck the cooperation fabric the Internet is based on.

Paying $10 and registering a domain IN NOW WAY means I promised a bazillion people anything.

What happened to: "You can run your network however you want"?

But when you decide that YOUR violation is MY problem to fix, then
you are just being silly. And worse, annoying.

Let's all just agree to run our own networks the way we damned well
please, as long as we are not hurting anyone else. We just have to
define "omplaining to you about things I b0rk'ed by myself" as
"hurting you". Which isn't a stretch, support costs money, and
costing me money because you screwed up is definitely hurtful.

When you promise to provide a service to anyone who asks for it and then
fail to, you impose costs on other people. Failing to resolve names that you
claim you will resolve is just such a failure. It forces other people's
resolvers to do extra work to get the information they need or they just
can't get it.

This is, IMO, the type of cooperation failure that justifies blacklisting.

You are very, very confused. When you ask me to resolve a name, _I_ did not cost _you_ anything - just the opposite. This is true whether I send you an A record or not.

The idea that you can force me to provide service for you without payment, contract, service in trade, etc., has not been true for a couple decades. The idea that I might, out of the goodness of my heart, provide services for others is still alive and well. But to expect it is only going to cause you all kinds of problems, even from the people who have goodness in their hearts.

But hey, feel free to disagree and blacklist away. Your network, your decision. :slight_smile:

8

You're totally welcome to run your own network backbone as IPv6-only
or X.25/CLNP. However, if you actually want to talk to the outside
world, a higher level of cooperation is required.

The hard-to-answer question is where the "best" tradeoff of "however you want"
and "industry standards and best practices" lies for a given provider, because
the answer is of course different for each site.

9

Having worked on both sides of the fence, i.e. I was a card-carrying member of both ASIS and NFPA, I used grumbled about the kooky things sysadmins and programmers did in the name of "security" as much as I grumbled about the kooky things security folks did in the name of "security." Heck, if programmers only produced bug-free software and sysadmins kept only well configured systems, security people would have a lot less work to do.

What are the industry best practices for keeping DNS servers secure?

CERT publishes a document on securing DNS:
<http://www.cert.org/archive/pdf/dns.pdf>

NIST publishes a document on securing DNS:
<http://csrc.nist.gov/fasp/FASPDocs/network-security/NISTSecuringDNS.htm>

CMYRU publishes a document on securing DNS:
<http://www.cymru.com/Documents/secure-bind-template.html>

Microsoft publishes a document on securing DNS:
<http://technet2.microsoft.com/WindowsServer/en/Library/0fe406eb-6ca2-4d95-9a18-aede7e931ca21033.mspx>

IETF publishes a document on operational (including security) requirements for root DNS servers:
<http://www.rfc-editor.org/rfc/rfc2870.txt>

While there is a lot in common, they each also have variations and omissions. Especially when it comes to some possibly obscure interactions
with many different protocols and applications. The relationships between IP, ICMP, TCP, UDP and DNS seems to be tough for many people to get right. When you add undocumented "common knowledge" and other applications
leveraging DNS for all sorts of stuff besides name/address resolution, its the typical programmer generated pile of spaghetti.

Its often simplier to wait for something to break before you fix it. I know many sysadmins, programmers and even security people, that use that
philosphy to decide which things to work on today.

The good thing about security folks (and their cousins, the auditors) is most are compliance driven. So if you get a new Industry Best Practice, often they will become your friend enforcing whatever that says.

So what should the Industry Best Practice(s) for DNS servers (root, authoritative and recursive) be? And what should it say about the
interaction between IP/ICMP and TCP/UDP? And maybe we'll even get
G-Root to follow it.

10

I can add one more voice to the chorus, not that it will necessarily change anyone's mind. :slight_smile:

When I was at Yahoo! the question of whether to keep TCP open or not had already been settled, since they had found that if they didn't have it open there was some small percentage of users who could not reach them. Given the large total number of {users|dns requests}/day even a small percentage was too much to sacrifice.

In addition to that, it was already well established policy that all RR sets should be kept under the 512 byte limit.

I took this a step further and worked (together with others) on a patch to restrict the size of DNS answers to < 512 by returning a random selection of any RR set larger than that.

Even with all of those precautions, I still measured a non-trivial amount of TCP traffic to our name servers, most of which was for valid requests. BTW, one of the things that a lot of people don't take into account in this little equation is the fact that the size of the QUERY will affect the size of the response.

So, given this experience, my conclusions (for whatever they are worth) are:

1. You can restrict 53/TCP on an authoritative name server if you want to, but you will lose traffic because of it.
2. Whether this is an acceptable loss or not is a local policy decision, but you should understand the consequences before you act.
3. No matter what your policy is, you cannot guarantee that employees will never make a mistake and create an RR set larger than 512 bytes.
4. You cannot control the behavior of client software out in the world, no matter how much you rant about it.

Others have already brought up the issues of DNSSEC, IPv6, etc. so I won't belabor how important having working TCP _and_ EDNS0 is going to be down the road.

And last but not least, the yang of "My network, my rules" has a yin to balance it out, "Be liberal in what you accept ...."

hth,

Doug

11

dougb@dougbarton.us (Doug Barton) writes:

... I took this a step further and worked (together with others) on a
patch to restrict the size of DNS answers to < 512 by returning a random
selection of any RR set larger than that.

note that this sounds like a DNS protocol violation, and usually is. every
time someone sent me a BIND patch adding this kind of deliberate instability
(see RFC 1794 for an example) i said "no".

12

Followups probably should go to the dnsops mailing list.

I got tired of things and went back to the original question, and put together my list of what the "minimum" packets needed for full DNS performance on the modern Internet.

It is the minimum, based on the security principle deny everything, allow
only what is needed. But "needed" is performance based. So it means not relying on fallbacks, timeouts or hoping no one complains. It does not include packets needed for diagnostic or troubleshooting information.
It is based on the "modern" Internet so does not included very deprecated packets like Source Quench or unimplemented functions like broadcast DNS
queries.

It does include current Internet practices for EDNS, Notify, global DNS load balancers and error handling I've seen in recent, i.e. less than 10 years old, DNS, Router and OS software.

I didn't included TOS/DSCP and some military options, mainly because I'm not sure what "modern" military networks are currently using. If you are
using TOS/DSCP or military options, there are some things you will need to add.

<http://www.donelan.com/dnsacl.html>
<http://www.donelan.com/dnsacl-min-cisco.html>