FW: maybe a dumb idea on how to fix the dns problems i don't know....

Mailman List Mirror (Read Only)
1

know....

Actually, the RFCs (RFC-1034 3.7RFC-1035 4.2, ref RFC-793;
Implementation spec in RFC-1035 4.2.2; RFC-2136 2.1 says TCP is "at the
discretion of the requestor":wink: say TCP "Should" be supported. It's
optional, but recommended.

The source of the guidance to block TCP is misguided "security" folks
who confuse self-denial of service with policy enforcement.

When security breaks functionality, it usually fails to secure, as users
circumvent it, in my not so humble experience.

BTW: In RFC 1034 5.3.1 PVM tipped to some of the issues that we are now
dealing with, under the title of "Stub Resolvers".

2

Tomas L. Byrnes wrote:

From: Tomas L. Byrnes Sent: Saturday, August 09, 2008 9:01 PM
To: 'Chris Paul'
Subject: RE: maybe a dumb idea on how to fix the dns problems i don't
know....

Actually, the RFCs (RFC-1034 3.7RFC-1035 4.2, ref RFC-793;
Implementation spec in RFC-1035 4.2.2; RFC-2136 2.1 says TCP is "at the
discretion of the requestor":wink: say TCP "Should" be supported. It's
optional, but recommended.

The source of the guidance to block TCP is misguided "security" folks
who confuse self-denial of service with policy enforcement.
  

Thanks Tomas for doing the research I wasn't about to do on a a weekend....

Dear North American Network Operators,

See it isn't a dumb idea after all? Y'all get coding, patching and firewall rule-set changing now! Let's please stop using UDP for DNS resolution. THAT was the dumb idea really...

(I know; you old folks that created this wonderful thing didn't think of that back then.... blah blah blah).

And SYN flooding? That happens to port 80 and port 25 too right? Most web and mail servers listen to the WORLD, whereas most DNS servers doing recursion do so only for the local network where SYN flooding is less of a risk

The experts don't seem to be able to post any rebuttals to my idea in decent enough English to answer why we should not do this. Perhaps I'm just too dumb to understand all you zen masters out there with your desire to use bad grammar, lack of punctuation and capitalization and the most complicated language to obfuscate solutions....

Oh and, ha ha, even though I'm just the ldap dude, I'll take all the fame and money (paypal or send to address below) for coming up with the simple solution to this dns problem. If you really want, my Mom will send some cookies to the next blackhat. (My Grandma taught her how very well but she is dead.)

There's really nothing more complicated about this problem than baking cookies, I don't think, but you have to go through many generations iteration and experiment ion to get it right. And sometimes the answers are simple once they are found (hey look what I found out: see what this bicarbonate of soda does!).

Oh hey yesterday was Saturday! Duh! Bonus for me!!! . Why on earth did I check my email? I usually don't on weekends at all. I'm sorry......

This change would not even be hard to implement globally, would it? Just SIMPLE code changes, patches, and firewall changes. (OK maybe the last part is not so easy but that to me is just lack of competence out there.)

Best,

CP

3

Good point.

But we only care about TCP connection setup time in *interactive* sessions (a human using something like the web). If you have a persistent connection to your dns server from your dns resolver on your browser machine, you just send the request.... no TCP setup there at all. You can even pool connections. We do this stuff in LDAP all the time.

How does TCP resolution work in most resolver libraries? A TCP connection for each lookup? That is kind of dumb isn't it, speaking of dumb.... I actually don't know. Not much of a coder, so I'll let you coders check your code and get back to me on that...

well.. maybe i'll fire up snort or wireshark and check it out later with some different dns libs....

CP

4

But we only care about TCP connection setup time in *interactive*
sessions (a human using something like the web). If you have a
persistent connection to your dns server from your dns resolver on your
browser machine, you just send the request.... no TCP setup there at
all. You can even pool connections. We do this stuff in LDAP all the time.

Again, if we can change the DNS protocol, then it's easy to solve.

Securing host->recursive name server is, at the moment, not an issue - each host is a small target, and often has little bandwidth available. Furthermore, stopping IP spoofing of one's own hosts within one's networks is, well, not trivial, but not hugely difficult either.

5

Wait a min... This isn't changing the DNS protocol to have or allow
persistent dns/tcp connections is it? or is it?

Yikes, yes the DNS protocol should be changed then, right now, to allow persistent connections, at least from the interactive client (websurfing machine) resolver to caching name server.

CP