squirting spray foam into the crack at the bottom of the BAW

[David Nicol]

server. Like I said before, an IDS should detect a 26 million packet
attack before it succeeds.  DJB has said something similar.
[...]
There is no way that the "birthday attack window" can be closed,

Safety currently appears to require an Intrusion Detection System, so building
an IDS into a resolver (as has been done, see
http://marc.info/?l=djbdns&m=124356186626355
) might be considered the equivalent of squirting some expanding foam
into the crack at the bottom of the window in question.

What additional measures? second, third, fourth opinions from other
servers presumably not under the same attack, reached over VPN links.
Build that into something, a network of resilient dns servers that
create a mesh of secure tcp links between each other and start
chatting over them when something appears amiss?

[Christopher Chan]

Post by David Nicol

server. Like I said before, an IDS should detect a 26 million packet
attack before it succeeds. DJB has said something similar.
[...]
There is no way that the "birthday attack window" can be closed,

Safety currently appears to require an Intrusion Detection System, so building
an IDS into a resolver (as has been done, see
http://marc.info/?l=djbdns&m=124356186626355
) might be considered the equivalent of squirting some expanding foam
into the crack at the bottom of the window in question.
What additional measures? second, third, fourth opinions from other
servers presumably not under the same attack, reached over VPN links.
Build that into something, a network of resilient dns servers that
create a mesh of secure tcp links between each other and start
chatting over them when something appears amiss?

You know that is why dnssec and dnscurve have surfaced right? That there
is NO WAY that you can secure the DNS protocol as it is right now. The
question is, what measures shall we take. Modify the DNS protocol or
take other measures. That is all that is left on the table.

[Maciej Żenczykowski]

There is no way that the "birthday attack window" can be closed,

Strictl speaking you could use raw sockets to simulate listening on
all udp ports at once,
monitor these ports for repetive answers which don't match any
currently in flight query,
and go into a defensive mode when we trigger on more than 100 (or
whatever) bad responses in a particular period of time, at which point
we start double or triple issuing queries, not considering the answers
valid until we receive two or three identical answers. I don't feel
like doing the math, but at a rough estimate this would make the
attack infeasible in practice.

As the number of bad (bad meaning unrequested, no match between
src/dst udp port and whatever other fields we can match on inside the
packet) packets per second increases, we can switch from single query
mode to progressively higher amount of repetitive queries.

[Joe Baptista]

That would be nice - a DNS with IDS - especially if IDS was specialized for
DNS. Good idea.

regards
joe baptista

Post by David Nicol

server. Like I said before, an IDS should detect a 26 million packet
attack before it succeeds. DJB has said something similar.
[...]
There is no way that the "birthday attack window" can be closed,

Safety currently appears to require an Intrusion Detection System, so building
an IDS into a resolver (as has been done, see
http://marc.info/?l=djbdns&m=124356186626355
) might be considered the equivalent of squirting some expanding foam
into the crack at the bottom of the window in question.
What additional measures? second, third, fourth opinions from other
servers presumably not under the same attack, reached over VPN links.
Build that into something, a network of resilient dns servers that
create a mesh of secure tcp links between each other and start
chatting over them when something appears amiss?

--
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: [phone] (extension 052)
Fax: [phone]

Personal: http://baptista.cynikal.net/

[Dean Anderson]

One only needs to fall back to TCP in that case. An attacker in the
path would be able to spoof in one packet, most of the time. So if we
detect a birthday attack, then we know the attacker isn't in the path.
And TCP is more than sufficient to prevent attacks from attackers who
are not in the path.

--Dean

Post by David Nicol

server. Like I said before, an IDS should detect a 26 million packet
attack before it succeeds.  DJB has said something similar.
[...]
There is no way that the "birthday attack window" can be closed,

Safety currently appears to require an Intrusion Detection System, so building
an IDS into a resolver (as has been done, see
http://marc.info/?l=djbdns&m=124356186626355
) might be considered the equivalent of squirting some expanding foam
into the crack at the bottom of the window in question.
What additional measures? second, third, fourth opinions from other
servers presumably not under the same attack, reached over VPN links.
Build that into something, a network of resilient dns servers that
create a mesh of secure tcp links between each other and start
chatting over them when something appears amiss?

[Maciej Żenczykowski]

One only needs to fall back to TCP in that case.  An attacker in the
path would be able to spoof in one packet, most of the time.  So if we
detect a birthday attack, then we know the attacker isn't in the path.
And TCP is more than sufficient to prevent attacks from attackers who
are not in the path.

True, although DNS servers which know their responses will not exceed
512 bytes (or whatever that number is) are not required to actually
support TCP (or at least in practice often don't).

[Hugo Monteiro]

Post by Maciej Żenczykowski

Post by Dean Anderson
One only needs to fall back to TCP in that case. An attacker in the
path would be able to spoof in one packet, most of the time. So if we
detect a birthday attack, then we know the attacker isn't in the path.
And TCP is more than sufficient to prevent attacks from attackers who
are not in the path.

True, although DNS servers which know their responses will not exceed
512 bytes (or whatever that number is) are not required to actually
support TCP (or at least in practice often don't).

From what i understood, that's exactly Dean point. DNS servers would
fallback to TCP if:

1 - Responses were larger than 512 bytes (as described in the current RFC).
2 - When they felt threatened by a birthday attack.

R's,

Hugo Monteiro.
--
fct.unl.pt:~# cat .signature

Hugo Monteiro
Email : ***@fct.unl.pt
Telefone : [phone] Ext.15307
Web : http://hmonteiro.net

Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: [phone] Fax: [phone]
www.fct.unl.pt ***@fct.unl.pt

fct.unl.pt:~# _

[Maciej Żenczykowski]

Post by Hugo Monteiro
From what i understood, that's exactly Dean point. DNS servers would

not dns servers, dns caches / recursive resolvers

Post by Hugo Monteiro
1 - Responses were larger than 512 bytes (as described in the current RFC).
2 - When they felt threatened by a birthday attack.

Agreed, I was just pointing out this wouldn't actually work. Many dns
servers simply don't listen for TCP requests or have them firewalled
(I know, I run one such server, never needed TCP, never bothered to
set it up...). You are not actually required to support tcp if you
know all your answers will be small enough.

[Hugo Monteiro]

Post by Maciej Żenczykowski

Post by Hugo Monteiro
From what i understood, that's exactly Dean point. DNS servers would

not dns servers, dns caches / recursive resolvers

They ARE dns servers. The records they serve may or not be local.

Post by Maciej Żenczykowski

Post by Hugo Monteiro
1 - Responses were larger than 512 bytes (as described in the current RFC).
2 - When they felt threatened by a birthday attack.

Agreed, I was just pointing out this wouldn't actually work. Many dns
servers simply don't listen for TCP requests or have them firewalled
(I know, I run one such server, never needed TCP, never bothered to
set it up...). You are not actually required to support tcp if you
know all your answers will be small enough.

And how can you know that every query to your resolver will produce a <
512 bytes answer? Do you by any chance control all the queried
authoritative servers? If not, i would say that you are your
implementation is not RFC compliant.

R's,

Hugo Monteiro.
--
fct.unl.pt:~# cat .signature

Hugo Monteiro
Email : ***@fct.unl.pt
Telefone : [phone] Ext.15307
Web : http://hmonteiro.net

Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: [phone] Fax: [phone]
www.fct.unl.pt ***@fct.unl.pt

fct.unl.pt:~# _

[Maciej Żenczykowski]

Post by Hugo Monteiro

Post by Maciej Żenczykowski
not dns servers, dns caches / recursive resolvers

They ARE dns servers. The records they serve may or not be local.

No, they are not, dns servers serve authoritative data (ie. tinydns),
dns caches/resolvers perform queries for users (ie. dnscache). Bind
often mixes the two up (serving both roles out of one binary on one
ip:port), but they are very different beasts.

Post by Hugo Monteiro
And how can you know that every query to your resolver will produce a < 512
bytes answer? Do you by any chance control all the queried authoritative
servers? If not, i would say that you are your implementation is not RFC
compliant.

Who said it was a resolver? It's not a resolver it's a dns server,
not a cache, not a resolver, not a proxy. It serves exactly the
authoritative data that I gave it in it's configuration file (which I
control, I know exactly what is in it, and I know there's nothing in
there that could cause a big reply) and not a iota of information
more. There are no queried authoritative servers because it issues no
queries - it's an authoritative server, not a resolver...

To quote ftp://ftp.rfc-editor.org/in-notes/rfc1123.txt

6.1.3.2 Transport Protocols

DNS resolvers and recursive servers MUST support UDP, and
SHOULD support TCP, for sending (non-zone-transfer) queries.
Specifically, a DNS resolver or server that is sending a
non-zone-transfer query MUST send a UDP query first. If the
Answer section of the response is truncated and if the
requester supports TCP, it SHOULD try the query again using
TCP.

DNS servers MUST be able to service UDP queries and SHOULD
be able to service TCP queries. A name server MAY limit the
resources it devotes to TCP queries, but it SHOULD NOT
refuse to service a TCP query just because it would have
succeeded with UDP.

...etc...

Hence, while it is RECOMMENDED, it is not REQUIRED for you to support
TCP queries.

Remember:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

[George Barwood]

----- Original Message -----
From: "Maciej Żenczykowski" <***@gmail.com>
To: "Hugo Monteiro" <***@fct.unl.pt>
Cc: <***@list.cr.yp.to>
Sent: Tuesday, March 16, 2010 10:20 AM
Subject: Re: squirting spray foam into the crack at the bottom of the BAW

Post by Maciej Żenczykowski

Post by Hugo Monteiro
From what i understood, that's exactly Dean point. DNS servers would

not dns servers, dns caches / recursive resolvers

Post by Hugo Monteiro
1 - Responses were larger than 512 bytes (as described in the current RFC).
2 - When they felt threatened by a birthday attack.

Agreed, I was just pointing out this wouldn't actually work.

Depends what you mean by "not working".

It may be that allowing a denial of service attack is better than allowing
a cache to be poisoned.

A solution that works, but is quite a lot of work to implement, is to send multiple queries and check they agree.

See http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/

-- George

Post by Maciej Żenczykowski
Many dns
servers simply don't listen for TCP requests or have them firewalled
(I know, I run one such server, never needed TCP, never bothered to
set it up...). You are not actually required to support tcp if you
know all your answers will be small en

[Hugo Monteiro]

Post by George Barwood
----- Original Message -----
Sent: Tuesday, March 16, 2010 10:20 AM
Subject: Re: squirting spray foam into the crack at the bottom of the BAW

Post by Maciej Żenczykowski

Post by Hugo Monteiro
From what i understood, that's exactly Dean point. DNS servers would

not dns servers, dns caches / recursive resolvers

Post by Hugo Monteiro
1 - Responses were larger than 512 bytes (as described in the current RFC).
2 - When they felt threatened by a birthday attack.

Agreed, I was just pointing out this wouldn't actually work.

Depends what you mean by "not working".
It may be that allowing a denial of service attack is better than allowing
a cache to be poisoned.
A solution that works, but is quite a lot of work to implement, is to send multiple queries and check they agree.
See http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/
-- George

Hello George,

I was wondering how it would deal with situations like round-robin.

R's,

Hugo Monteiro.
--
fct.unl.pt:~# cat .signature

Hugo Monteiro
Email : ***@fct.unl.pt
Telefone : [phone] Ext.15307
Web : http://hmonteiro.net

Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: [phone] Fax: [phone]
www.fct.unl.pt ***@fct.unl.pt

fct.unl.pt:~# _

[Daryl Tester]

Post by Maciej Żenczykowski
(I know, I run one such server, never needed TCP, never bothered to
set it up...).

There are some registrars that used to check that your content servers
are serving out queries correctly (which included tcp queries), and veto
delegation if you aren't. This tripped me up in my very first public
deployment of tinydns.

[Dean Anderson]

Name some that don't support TCP.

You are aware the the IETF is now moving to make TCP required, when it
used to be optional for non-public service operators.

--Dean

*Public service dns operators are: root, TLD and ccTLD operators.

Post by Maciej Żenczykowski

One only needs to fall back to TCP in that case.  An attacker in the
path would be able to spoof in one packet, most of the time.  So if we
detect a birthday attack, then we know the attacker isn't in the path.
And TCP is more than sufficient to prevent attacks from attackers who
are not in the path.

True, although DNS servers which know their responses will not exceed
512 bytes (or whatever that number is) are not required to actually
support TCP (or at least in practice often don't).

[Matthew Dempsky]

Post by Dean Anderson
Name some that don't support TCP.

Off the top of my head: b.ns.yp.to, ns1.msft.net, a.ns.spamhaus.org,
m.root-servers.net

Post by Dean Anderson
You are aware the the IETF is now moving to make TCP required,

They're moving to require *software support* for TCP. They're not
requiring operators to support TCP.

Post by Dean Anderson
*Public service dns operators are:  root, TLD and ccTLD operators.

Not all root or TLD servers support TCP. Here's a list of TLD zones
and their name servers (from the root zone file) that respond to a SOA
request over UDP but fail over TCP:

AD. DINIS.AD. DNS2.AD. DNS3.AD. DNS4.AD.
AW. NS1.SETARNET.AW. NS2.SETARNET.AW.
CAT. DNS4.AD.
CN. A.DNS.CN. B.DNS.CN. NS.CERNET.NET.
ET. NS1.TELECOM.NET.ET. NS2.TELECOM.NET.ET.
IR. NS1.NIC.IR.
KW. DNS1.KW. DNS2.KW. DNS3.KW.
LK. NS-C.NIC.LK. NS-L.NIC.LK. NS-T.NIC.LK.
MA. NS1.IAM.NET.MA. NS2.IAM.NET.MA. NS3.IAM.NET.MA.
MN. NS1.MAGIC.MN.
MO. UMACSN1.UMAC.MO. UMACSN2.UMAC.MO. UMACSS1.UMAC.MO.
UMACSS2.UMAC.MO. UMACSS3.UMAC.MO.
MV. NS.DHIVEHINET.NET.MV. NS2.DHIVEHINET.NET.MV.
NC. PYTHON.OPT.NC. TRITON.OPT.NC.
NP. SHIKHAR.MOS.COM.NP.
OM. OM14.OMANTEL.NET.OM.
PA. NS.NIC.PA. NS.PA.
PK. M-2.PKNIC.NET.PK.
TK. ROOT-A.TALOHA.TK. ROOT-C.TALOHA.TK. ROOT-D.TALOHA.TK.
ROOT-E.TALOHA.TK. ROOT-G.TALOHA.TK.
VN. B.DNS-SERVERS.VN.
VU. SANTO.VANUATU.COM.VU.
ZW. NS1.TELONE.CO.ZW. NS2.TELONE.CO.ZW.

I don't think there are any public zones that have *no* TCP access,
but that's hardly to say that every public zone name server supports
TCP.

[Dean Anderson]

No, nameservers.

That some individuals block TCP DNS is of no consequence. They are
accountable for their own decisions. We don't have any control over
their decision-making.

--Dean

Post by Matthew Dempsky

Post by Dean Anderson
Name some that don't support TCP.

Off the top of my head: b.ns.yp.to, ns1.msft.net, a.ns.spamhaus.org,
m.root-servers.net
I don't think there are any public zones that have *no* TCP access,
but that's hardly to say that every public zone name server supports
TCP.

There had better not be any public zones without TCP. They are obligated
to provide TCP service to resolvers that are TCP only. If you know of
any public-service zones that don't support TCP, please let me know. I
keep track of TCP problems, and I will notify the appropriate
authorities

--Dean

[Maciej Żenczykowski]

They are obligated to provide TCP service to resolvers that are TCP only.

Please quote relevant published RFC or other relevant spec.

[Dean Anderson]

RFC 1034, 1035, 2870, and the ICANN memoranda of understanding
establishing essentially RFC 2870.

RFC 1034 Section 3.7:

"In the Internet, queries are carried in UDP datagrams or over
TCP connections."

RFC 1035 Section 4.2.2. TCP usage

RFC 2870 SEction 2.2:

Each server MUST run software which correctly implements the IETF
standards for the DNS, currently [RFC1035] [RFC2181]. While
there are no formal test suites for standards compliance, the
maintainers of software used on root servers are expected to take
all reasonable actions to conform to the IETF's then current
documented expectations.

Root server operators have to support all clients, including TCP-only
resolvers. I've been looking for the contracts for TLD and CCtld
operations, but I understand that they have requirements similar to
2870.

There is a notion that TCP is not required which derives from text in
RFC1123 (which doesn't pertain to root operations in RFC2870). RFC1123
includes text that says that servers SHOULD support TCP for
non-public-service servers. The current DNSEXT proposal I mentioned
makes it explicit that TCP is required for everyone.
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

There are no valid reasons or circumstances in which root operators
would ignore TCP DNS support, as doing so would unnecessarilly break TCP
fallback and TCP only resolvers which the root operators are obligated
to service.


--Dean

Post by Maciej Żenczykowski

They are obligated to provide TCP service to resolvers that are TCP only.

Please quote relevant published RFC or other relevant spec.