cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS...
Transcript of cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS...
![Page 1: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/1.jpg)
1
The DNS security mess
D. J. Bernstein
University of Illinois at Chicago;
Technische Universiteit Eindhoven
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
![Page 2: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/2.jpg)
1
The DNS security mess
D. J. Bernstein
University of Illinois at Chicago;
Technische Universiteit Eindhoven
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
![Page 3: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/3.jpg)
1
The DNS security mess
D. J. Bernstein
University of Illinois at Chicago;
Technische Universiteit Eindhoven
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
![Page 4: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/4.jpg)
1
The DNS security mess
D. J. Bernstein
University of Illinois at Chicago;
Technische Universiteit Eindhoven
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
![Page 5: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/5.jpg)
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
![Page 6: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/6.jpg)
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
![Page 7: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/7.jpg)
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
![Page 8: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/8.jpg)
2
The Domain Name System
tue.nl wants to see
http://www.ru.nl.'& %$ ! "#Browser at tue.nl
'& %$ ! "#Administrator at ru.nl
“The web server
www.ru.nl
has IP address
131.174.78.60.”
OO
Now tue.nl
retrieves web page from
IP address 131.174.78.60.
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
![Page 9: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/9.jpg)
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
![Page 10: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/10.jpg)
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
![Page 11: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/11.jpg)
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
![Page 12: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/12.jpg)
3
Same for Internet mail.
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Administrator at ru.nl
“The mail server for
ru.nl
has IP address
192.87.102.77.”
OO
Now tue.nl
delivers mail to
IP address 192.87.102.77.
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
![Page 13: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/13.jpg)
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
![Page 14: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/14.jpg)
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
![Page 15: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/15.jpg)
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
![Page 16: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/16.jpg)
4
Forging DNS packets
tue.nl has mail to deliver to
[email protected].'& %$ ! "#Mail client at tue.nl
'& %$ ! "#Attacker anywhere on network
“The mail server for
ru.nl
has IP address
204.13.202.78.”
OO
Now tue.nl
delivers mail to
IP address 204.13.202.78,
actually the attacker’s machine.
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
![Page 17: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/17.jpg)
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
![Page 18: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/18.jpg)
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
![Page 19: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/19.jpg)
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
![Page 20: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/20.jpg)
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
![Page 21: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/21.jpg)
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
![Page 22: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/22.jpg)
5
How forgery really works
Client sends query.
Attacker has to repeat
some parts of the query.
Attacker must match
• the name: ru.nl.
• the query type: mail. (“MX”.)
• ≈ the query time,
so client sees forgery
before legitimate answer.
• the query UDP port.
• the query ID.
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
![Page 23: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/23.jpg)
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
![Page 24: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/24.jpg)
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
![Page 25: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/25.jpg)
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
![Page 26: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/26.jpg)
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
![Page 27: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/27.jpg)
6
The hard way
for attackers to do this:
Control name, type, time
by triggering client.
Many ways to do this.
Guess port and ID
(or predict them if
they’re poorly randomized).
16-bit port, 16-bit ID.
If guess fails, try again.
After analysis, optimization:
this is about as much traffic
as downloading a movie.
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
![Page 28: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/28.jpg)
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
![Page 29: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/29.jpg)
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
![Page 30: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/30.jpg)
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
![Page 31: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/31.jpg)
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
![Page 32: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/32.jpg)
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
![Page 33: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/33.jpg)
7
The easy way
for attackers to do this:
1. Break into a computer
on the same network.
2. Using that computer,
sniff network to see
the client’s query.
Immediately forge answer.
Sometimes skip step 1:
the network is the attacker.
e.g. DNS forgery by hotels,
Iranian government, et al.
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
![Page 34: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/34.jpg)
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
![Page 35: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/35.jpg)
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
![Page 36: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/36.jpg)
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
![Page 37: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/37.jpg)
8
Security theater
Many DNS “defenses”
(e.g. query repetition)
stop the hard attack
but are trivially broken
by the easy attack.
Why don’t people realize this?
Answer: The hard attack
receives much more publicity
than the easy attack.
Security researchers
can’t publish easy attacks.
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
![Page 38: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/38.jpg)
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
![Page 39: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/39.jpg)
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
![Page 40: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/40.jpg)
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
![Page 41: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/41.jpg)
9
June 2009: exciting news!
“.ORG becomes the first open
TLD to sign their zone with
DNSSEC : : :Today we reached
a significant milestone in our
effort to bolster online security
for the .ORG community. We are
the first open generic Top-Level
Domain to successfully sign our
zone with Domain Name Security
Extensions (DNSSEC). To date,
the .ORG zone is the largest
domain registry to implement
this needed security measure.”
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
![Page 42: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/42.jpg)
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
![Page 43: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/43.jpg)
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
![Page 44: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/44.jpg)
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
![Page 45: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/45.jpg)
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
![Page 46: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/46.jpg)
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
![Page 47: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/47.jpg)
10
“What does it mean that the
.ORG Zone is ‘signed’?
Signing our zone is the first part
of our DNSSEC test phase.
We are now cryptographically
signing the authoritative data
within the .ORG zone file.
This process adds new records to
the zone, which allows verification
of the origin authenticity and
integrity of data.”
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
![Page 48: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/48.jpg)
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
![Page 49: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/49.jpg)
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
![Page 50: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/50.jpg)
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
![Page 51: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/51.jpg)
11
Cryptography! Authority!
Verification! Authenticity!
Integrity! Sounds great!
Now I simply configure
the new .org public key
into my DNS software.
Because the .org servers
are signing with DNSSEC,
it is no longer possible
for attackers to forge
data from those servers!
... or is it?
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
![Page 52: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/52.jpg)
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
![Page 53: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/53.jpg)
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
![Page 54: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/54.jpg)
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
![Page 55: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/55.jpg)
12
December 2016: reality
Let’s find a .org server:
$ dig +short ns org
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b2.org.afilias-nst.org.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
$ dig +short \
b0.org.afilias-nst.org
199.19.54.1
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
![Page 56: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/56.jpg)
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
![Page 57: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/57.jpg)
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
![Page 58: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/58.jpg)
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
![Page 59: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/59.jpg)
13
Look up greenpeace.org:
$ dig \
www.greenpeace.org \
@199.19.54.1
Everything looks normal:
;; AUTHORITY SECTION:
greenpeace.org.
86400 IN NS
ns-emea.greenpeace.org.
;; ADDITIONAL SECTION:
ns-emea.greenpeace.org.
86400 IN A
37.48.104.54
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
![Page 60: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/60.jpg)
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
![Page 61: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/61.jpg)
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
![Page 62: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/62.jpg)
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
![Page 63: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/63.jpg)
14
Where’s the crypto?
Have to ask for signatures:
$ dig +dnssec \
www.greenpeace.org \
@199.19.54.1
Old answer + four new lines:
h9p7u7tr2u91d0v0ljs9l1gid
np90u3h.org. 86400 IN NSE
C3 1 1 1 D399EAAB H9PARR6
69T6U8O1GSG9E1LMITK4DEM0T
NS SOA RRSIG DNSKEY NSEC
3PARAM
h9p7u7tr2u91d0v0ljs9l1gid
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
![Page 64: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/64.jpg)
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
![Page 65: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/65.jpg)
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
![Page 66: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/66.jpg)
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
![Page 67: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/67.jpg)
15
np90u3h.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
29113950 20161208103950 3
947 org. F9TxgXX1iROZnfXk
xe9GjwCmnGHPCBRHwk9kPmU+7
sW1iD0VqA4ZjNvi GEDJdWD7T
loixxOUwbx+KjWJYjZpd0LHC9
2IHWp5Phlajme4Yek/CTu0 jX
M3F4wq7Ibf23CL6Hi51qS6PbO
BbNFnX0vzSGjZwfzZL5kRGJUV
LLFk xEs=
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN NSE
C3 1 1 1 D399EAAB BGDHKIB
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
![Page 68: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/68.jpg)
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
![Page 69: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/69.jpg)
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
![Page 70: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/70.jpg)
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
![Page 71: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/71.jpg)
16
0PPOBENBFCGBMB6RGT2JDC21E
A RRSIG
bgca0g0ug0p6o7425emkt9ue4
qng3p2f.org. 86400 IN RRS
IG NSEC3 7 2 86400 201612
22153046 20161201143046 3
947 org. Q2VtusS5O0v2ykrp
JwJcg25OVwm9FMP0ioBMb1+sG
vYLn2WUrgvjBfFm Na8MxWlP2
9gKbnit47gyfeky9AwDKBJ3ph
KRc3qYMdFEGftVeGePEbdy 7w
EHNmP1bpR99/f25TMIGqs8FxM
+ArS4Jn+2Xa8KFdfjdlfwFc+y
orI8 ylc=
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
![Page 72: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/72.jpg)
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
![Page 73: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/73.jpg)
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
![Page 74: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/74.jpg)
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
![Page 75: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/75.jpg)
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
![Page 76: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/76.jpg)
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
![Page 77: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/77.jpg)
17
Wow, that’s a lot of data.
Must be strong cryptography!
$ tcpdump -n -e \
host 199.19.54.1 &
shows packet sizes:
dig sends 89-byte IP packet
to the .org DNS server,
receives 654-byte IP packet.
See more DNSSEC data:
$ dig +dnssec any \
org @199.19.54.1
Sends 74-byte IP packet,
receives two IP fragments
totalling 2653 bytes.
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
![Page 78: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/78.jpg)
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
![Page 79: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/79.jpg)
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
![Page 80: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/80.jpg)
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
![Page 81: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/81.jpg)
18
Interlude: the attacker’s view
What happens if we aim
this data at someone else?
Let’s see what DNSSEC can do
as an amplification tool for
denial-of-service attacks.
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
![Page 82: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/82.jpg)
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
![Page 83: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/83.jpg)
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
![Page 84: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/84.jpg)
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
![Page 85: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/85.jpg)
19
Download DNSSEC zone list:
wget -m -k -I / \
secspider.cs.ucla.edu
cd secspider.cs.ucla.edu
awk ’
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5]
}
’ ./*--zone.html \
| sort -u | wc -l
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
![Page 86: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/86.jpg)
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
![Page 87: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/87.jpg)
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
![Page 88: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/88.jpg)
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
![Page 89: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/89.jpg)
20
Make list of DNSSEC names:
( cd secspider.cs.ucla.edu
echo ./*--zone.html \
| xargs awk ’
/^Zone <STRONG>/ { z = $2
sub(/<STRONG>/,"",z)
sub(/<\/STRONG>/,"",z)
}
/GREEN.*GREEN.*GREEN.*Yes/ {
split($0,x,/<TD>/)
sub(/<\/TD>/,"",x[5])
print x[5],z,rand()
}’
) | sort -k3n \
| awk ’{print $1,$2}’ > SERVERS
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
![Page 90: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/90.jpg)
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
![Page 91: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/91.jpg)
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
![Page 92: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/92.jpg)
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
![Page 93: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/93.jpg)
21
For each domain: Try query,
estimate DNSSEC amplification.
while read ip z
do
dig +dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip" | \
awk -v "z=$z" -v "ip=$ip" ’{
if ($1 != ";;") next
if ($2 != "MSG") next
if ($3 != "SIZE") next
if ($4 != "rcvd:") next
est = (22+$5)/(40+length(z))
print est,ip,z
}’
done < SERVERS > AMP
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
![Page 94: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/94.jpg)
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
![Page 95: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/95.jpg)
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
![Page 96: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/96.jpg)
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
![Page 97: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/97.jpg)
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
![Page 98: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/98.jpg)
22
For each DNSSEC server,
find domain estimated to have
maximum DNSSEC amplification:
sort -nr AMP | awk ’{
if (seen[$2]) next
if ($1 < 30) next
print $1,$2,$3
seen[$2] = 1
}’ > MAXAMP
head -1 MAXAMP
wc -l MAXAMP
Output (last time I tried it):
95.6279 156.154.102.26 fi.
2326 MAXAMP
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
![Page 99: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/99.jpg)
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
![Page 100: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/100.jpg)
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
![Page 101: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/101.jpg)
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
![Page 102: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/102.jpg)
23
Can that really be true?
>2000 DNSSEC servers
around the Internet, each
providing >30× amplification
of incoming UDP packets?
Let’s verify this.
Choose quiet test machines
on two different networks
(without egress filters).
e.g. Sender: 1.2.3.4.
Receiver: 5.6.7.8.
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
![Page 103: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/103.jpg)
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
![Page 104: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/104.jpg)
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
![Page 105: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/105.jpg)
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
![Page 106: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/106.jpg)
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
![Page 107: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/107.jpg)
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
![Page 108: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/108.jpg)
24
Run network-traffic monitors
on 1.2.3.4 and 5.6.7.8.
On 1.2.3.4, set response
address to 5.6.7.8,
and send 1 query/second:
ifconfig eth0:1 \
5.6.7.8 \
netmask 255.255.255.255
while read est ip z
do
dig -b 5.6.7.8 \
+dnssec +ignore +tries=1 \
+time=1 any "$z" "@$ip"
done < MAXAMP >/dev/null 2>&1
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
![Page 109: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/109.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
![Page 110: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/110.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
![Page 111: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/111.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
![Page 112: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/112.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
![Page 113: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/113.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
![Page 114: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/114.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
![Page 115: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/115.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
![Page 116: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/116.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
![Page 117: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/117.jpg)
25
I sustained 51× amplification
of actual network traffic
in a US-to-Europe experiment
on typical university computers
at the end of 2010.
Attacker sending 10Mbps
can trigger 500Mbps flood
from the DNSSEC drone pool,
taking down typical site.
Attacker sending 200Mbps
can trigger 10Gbps flood,
taking down very large site.
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
![Page 118: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/118.jpg)
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
![Page 119: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/119.jpg)
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
![Page 120: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/120.jpg)
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
![Page 121: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/121.jpg)
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
![Page 122: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/122.jpg)
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
![Page 123: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/123.jpg)
26
Attack capacity is limited by
total DNSSEC server bandwidth.
Mid-2012 estimate: <100Gbps.
Can’t take down Google this way.
Logical attacker response:
Tell people to install DNSSEC.
2010.12.24 DNSSEC servers:
2536 IP addresses worldwide.
2011.12.14 DNSSEC servers:
3393 IP addresses worldwide.
2016: No SecSpider downloads???
Exercise: Collect+publish data.
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
![Page 124: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/124.jpg)
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
![Page 125: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/125.jpg)
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
29
All we care about is integrity:
![Page 126: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/126.jpg)
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
29
All we care about is integrity:
![Page 127: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/127.jpg)
27
RFC 4033 says
“DNSSEC provides no protection
against denial of service attacks.”
RFC 4033 doesn’t say
“DNSSEC is a pool of
remote-controlled attack drones,
the worst DDoS amplifier
on the Internet.”
Exercise: investigate
other types of DoS attacks.
e.g. DNSSEC advertising says
zero server-CPU-time cost.
How much server CPU time
can attackers actually consume?
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
29
All we care about is integrity:
![Page 128: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/128.jpg)
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
29
All we care about is integrity:
![Page 129: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/129.jpg)
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
29
All we care about is integrity:30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
![Page 130: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/130.jpg)
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
29
All we care about is integrity:30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
![Page 131: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/131.jpg)
28
Back to integrity
Let’s pretend we don’t
care about availability.
This is not an attack:
29
All we care about is integrity:30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
![Page 132: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/132.jpg)
29
All we care about is integrity:30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
![Page 133: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/133.jpg)
29
All we care about is integrity:30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
![Page 134: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/134.jpg)
29
All we care about is integrity:30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
![Page 135: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/135.jpg)
29
All we care about is integrity:30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
![Page 136: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/136.jpg)
30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
![Page 137: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/137.jpg)
30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
![Page 138: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/138.jpg)
30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
![Page 139: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/139.jpg)
30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
![Page 140: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/140.jpg)
30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
![Page 141: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/141.jpg)
30
The .org signatures
are 1024-bit RSA signatures.
2003: Shamir–Tromer et al.
concluded that 1024-bit RSA
was already breakable by
large companies and botnets.
$10 million: 1 key/year.
$120 million: 1 key/month.
2003: RSA Laboratories
recommended a transition to
2048-bit keys “over the remainder
of this decade.” 2007: NIST
made the same recommendation.
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
![Page 142: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/142.jpg)
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
![Page 143: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/143.jpg)
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
![Page 144: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/144.jpg)
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
![Page 145: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/145.jpg)
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
![Page 146: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/146.jpg)
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
![Page 147: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/147.jpg)
31
Academics in small labs
factored RSA-768 in 2009.
Still no public announcements
of breaks of 1024-bit RSA.
“RSA-1024: still secure
against honest attackers.”
What about serious attackers
using many more computers?
e.g. botnet operators?
I say:
Using RSA-1024 is irresponsible.
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
![Page 148: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/148.jpg)
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
![Page 149: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/149.jpg)
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
34
“DNSSEC: Built, not plugged in.”
![Page 150: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/150.jpg)
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
34
“DNSSEC: Built, not plugged in.”
![Page 151: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/151.jpg)
32
But that’s not the big problem
with these DNSSEC signatures
for greenpeace.org.
Suppose an attacker forges
a DNS packet from .org,
including exactly the same
DNSSEC signatures but
changing the NS+A records to
point to the attacker’s servers.
Fact: DNSSEC “verification”
won’t notice the change.
The signatures say nothing
about the NS+A records.
The forgery will be accepted.
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
34
“DNSSEC: Built, not plugged in.”
![Page 152: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/152.jpg)
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
34
“DNSSEC: Built, not plugged in.”
![Page 153: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/153.jpg)
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
![Page 154: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/154.jpg)
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
![Page 155: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/155.jpg)
33
Here’s what .org signed,
translated into English:
“.org might have data
with hashes between
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h,
h9parr669t6u8o1gsg9e1lmitk4dem0t
but has not signed any of
that data.”
Can check that greenpeace.org
has a hash in that range.
.org now has thousands
of these useless signatures.
This is .org “implementing”
a “needed security measure.”
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
![Page 156: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/156.jpg)
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
![Page 157: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/157.jpg)
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
![Page 158: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/158.jpg)
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
![Page 159: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/159.jpg)
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
![Page 160: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/160.jpg)
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
![Page 161: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/161.jpg)
34
“DNSSEC: Built, not plugged in.”35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
![Page 162: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/162.jpg)
35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
![Page 163: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/163.jpg)
35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
![Page 164: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/164.jpg)
35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
![Page 165: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/165.jpg)
35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
![Page 166: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/166.jpg)
35
What went wrong?
Rushed development process?
No: DNSSEC has been
under active development
for two decades.
1993.11 Galvin: “The DNS
Security design team of the
DNS working group met for one
morning at the Houston IETF.”
1994.02 Eastlake–Kaufman,
after months of discussions on
dns-security mailing list:
“DNSSEC” protocol specification.
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
![Page 167: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/167.jpg)
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
![Page 168: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/168.jpg)
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
![Page 169: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/169.jpg)
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
![Page 170: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/170.jpg)
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
![Page 171: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/171.jpg)
36
Millions of dollars
of U.S. government grants: e.g.,
DISA to BIND company;
NSF to UCLA; DHS to
Secure64 Software Corporation.
Continuing cycle of
DNSSEC implementations,
IETF DNSSEC discussions,
protocol updates, revised
software implementations, etc.
Compatibility trap? No.
Several DNSSEC updates
have broken compatibility
with older implementations.
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
![Page 172: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/172.jpg)
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
![Page 173: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/173.jpg)
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
![Page 174: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/174.jpg)
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
![Page 175: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/175.jpg)
37
The performance trap
Some of the Internet’s DNS
servers are extremely busy: e.g.,
the root servers, the .com servers,
the google.com servers.
Can they afford crypto?
The critical design decision
in DNSSEC: precompute
signatures of DNS records.
“Per-query crypto is bad.”
Signature is computed once;
saved; sent to many clients.
Hopefully the server can afford
to sign each DNS record once.
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
![Page 176: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/176.jpg)
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
![Page 177: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/177.jpg)
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
![Page 178: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/178.jpg)
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
![Page 179: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/179.jpg)
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
![Page 180: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/180.jpg)
38
Clients don’t share the work
of verifying a signature.
DNSSEC tries to reduce
client-side costs (and
precomputation costs) through
choice of crypto primitive.
Many DNSSEC crypto options:
640-bit RSA, original specs;
768-bit RSA, many docs;
1024-bit RSA, current RFCs
(for “leaf nodes in the DNS”);
DSA, “10 to 40 times as slow
for verification” but faster for
signatures.
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
![Page 181: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/181.jpg)
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
![Page 182: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/182.jpg)
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
![Page 183: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/183.jpg)
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
![Page 184: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/184.jpg)
39
DNSSEC made breakable choices
such as 640-bit RSA
for no reason other than
fear of overload.
DNSSEC needed more options
to survive the inevitable breaks.
More complexity ⇒ more bugs,
including security holes.
Looking beyond the crypto:
Precomputation forced DNSSEC
down a path of unreliability,
insecurity, and unusability.
Let’s see how this happened.
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
![Page 185: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/185.jpg)
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
![Page 186: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/186.jpg)
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
![Page 187: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/187.jpg)
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
![Page 188: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/188.jpg)
40
DNS architecture
Browser pulls data from
DNS cache at tue.nl:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
Administrator at ru.nl?> =<89 :;OO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
bj
Cache pulls data from
administrator if it
doesn’t already have the data.
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
![Page 189: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/189.jpg)
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
![Page 190: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/190.jpg)
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
![Page 191: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/191.jpg)
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
![Page 192: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/192.jpg)
41
Administrator pushes data
through local database into
.ru.nl DNS server:
Browser at tue.nl
DNS cache
WV UTPQ RSOO
.ru.nlDNS server
OO
.ru.nldatabase
OO
Administrator at ru.nl
WV UTPQ RSOO
“The web server
www.ru.nl
has IP address
131.174.78.60.”
^f
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
![Page 193: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/193.jpg)
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
![Page 194: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/194.jpg)
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
![Page 195: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/195.jpg)
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
![Page 196: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/196.jpg)
42
DNS cache learns location of
.ru.nl DNS server from
.nl DNS server:
at tue.nl DNS cache'& %$ ! "#
.nlDNS server
OO
.nldatabase
WV UTPQ RSOO
at ru.nl Administrator'& %$ ! "#OO
“The DNS server
for .ru.nl
is ns3
with IP address
131.174.78.16.”
5=
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
![Page 197: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/197.jpg)
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
![Page 198: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/198.jpg)
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
![Page 199: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/199.jpg)
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
![Page 200: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/200.jpg)
43
GodWV UT
PQ RS
&&NNNNN
NNNNNN Browser
RootDNSserver
// DNScache
WV UTPQ RS
OO
.nlDNSserver
::uuuuuuuuuuu.ru.nl
DNSserver
OO
.nldata
at InternetCentral HQ
base
OO
.ru.nldatabase
OO
at ru.nl
Administrator
WV UTPQ RSOOhhPPPPPPPPPP
\d
6>
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
![Page 201: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/201.jpg)
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
![Page 202: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/202.jpg)
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
![Page 203: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/203.jpg)
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
![Page 204: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/204.jpg)
44
DNS server software listed in
Wikipedia: BIND, Microsoft
DNS, djbdns, Dnsmasq, Simple
DNS Plus, NSD, Knot DNS,
PowerDNS, MaraDNS, pdnsd,
Nominum ANS, Nominum Vantio,
Posadis, Unbound, Cisco Network
Registrar, dnrd, gdnsd, YADIFA,
yaku-ns, DNS Blast.
Much wider variety of DNS
database-management tools, plus
hundreds of homegrown tools
written by DNS registrars etc.
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
![Page 205: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/205.jpg)
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
![Page 206: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/206.jpg)
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
![Page 207: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/207.jpg)
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
![Page 208: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/208.jpg)
45
DNSSEC changes everything
DNSSEC demands new code in
every DNS-management tool.
Whenever a tool adds or changes
a DNS record, also has to
precompute and store a DNSSEC
signature for the new record.
Often considerable effort
for the tool programmers.
Example: Signing 6GB database
can produce 40GB database.
Tool reading database into RAM
probably has to be reengineered.
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
![Page 209: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/209.jpg)
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
![Page 210: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/210.jpg)
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
![Page 211: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/211.jpg)
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
![Page 212: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/212.jpg)
46
Nijmegen administrator also has
to send public key to .nl.
The .nl server
and database software
and web interface
need to be updated
to accept these public keys
and to sign everything.
DNS cache needs new software
to fetch keys, fetch signatures,
and verify signatures.
Tons of pain for implementors.
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
![Page 213: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/213.jpg)
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
![Page 214: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/214.jpg)
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
![Page 215: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/215.jpg)
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
![Page 216: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/216.jpg)
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
![Page 217: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/217.jpg)
47
Original DNSSEC protocols
would have required .org
to sign its whole database:
millions of records.
Conceptually simple but
much too slow, much too big.
So the DNSSEC protocol
added complicated options
allowing .org to sign
a small number of records,
and to sign “might have data
but has not signed any of it”
covering the other records.
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
![Page 218: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/218.jpg)
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
![Page 219: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/219.jpg)
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
![Page 220: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/220.jpg)
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
![Page 221: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/221.jpg)
48
What about dynamic DNS data?
e.g. Most big sites
return random IP addresses
to spread load across servers.
Often they automatically
adjust list of addresses
in light of dead servers,
client location, etc.
DNSSEC purists say “Answers
should always be static”.
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
![Page 222: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/222.jpg)
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
![Page 223: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/223.jpg)
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
![Page 224: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/224.jpg)
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
![Page 225: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/225.jpg)
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
![Page 226: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/226.jpg)
49
Even in “static” DNS,
each response packet is
dynamically assembled
from several answers:
MX answer, NS answer, etc.
DNSSEC precomputes
a signature for each answer,
not for each packet.
⇒ One DNSSEC packet
includes several signatures.
Massive bloat on the wire.
That’s why DNSSEC allows
so much amplification.
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
![Page 227: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/227.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
![Page 228: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/228.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
![Page 229: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/229.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
![Page 230: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/230.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
![Page 231: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/231.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
![Page 232: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/232.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
![Page 233: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/233.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
![Page 234: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/234.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
![Page 235: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/235.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
![Page 236: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/236.jpg)
50
What about old DNS data?
Are the signatures still valid?
Can an attacker replay
obsolete signed data?
e.g. You move IP addresses.
Attacker grabs old address,
replays old signature.
If clocks are synchronized
then signatures can
include expiration times.
But frequent re-signing
is an administrative disaster.
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
![Page 237: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/237.jpg)
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
![Page 238: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/238.jpg)
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
![Page 239: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/239.jpg)
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
![Page 240: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/240.jpg)
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
![Page 241: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/241.jpg)
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
![Page 242: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/242.jpg)
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
![Page 243: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/243.jpg)
51
A few DNSSEC suicide examples:
2010.09.02: .us killed itself.
2012.02.28, ISC’s Evan Hunt:
“dnssec-accept-expired yes”
2012.10.28: .nl killed itself.
2015.01.25: opendnssec.org
killed itself.
2015.12.11: af.mil killed itself.
2016.10.24: dnssec-tools.org
killed itself.
Many more: see ianix.com
/pub/dnssec-outages.html.
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
![Page 244: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/244.jpg)
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
![Page 245: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/245.jpg)
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
![Page 246: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/246.jpg)
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
![Page 247: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/247.jpg)
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
![Page 248: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/248.jpg)
52
What about nonexistent data?
Does Nijmegen administrator
precompute signatures on
“aaaaa.ru.nl does not exist”,
“aaaab.ru.nl does not exist”,
etc.?
Crazy! Obvious approach:
“We sign each record that exists,
and don’t sign anything else.”
User asks for nonexistent name.
Receives unsigned answer
saying the name doesn’t exist.
Has no choice but to trust it.
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
![Page 249: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/249.jpg)
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
![Page 250: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/250.jpg)
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
![Page 251: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/251.jpg)
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
![Page 252: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/252.jpg)
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
![Page 253: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/253.jpg)
53
User asks for www.google.com.
Receives unsigned answer,
a packet forged by attacker,
saying the name doesn’t exist.
Has no choice but to trust it.
Clearly a violation of availability.
Sometimes a violation of integrity.
This is not a good approach.
Alternative: DNSSEC’s “NSEC”.
e.g. nonex.clegg.com query
returns “There are no names
between nick.clegg.com and
start.clegg.com” + signature.
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
![Page 254: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/254.jpg)
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
![Page 255: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/255.jpg)
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
![Page 256: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/256.jpg)
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
![Page 257: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/257.jpg)
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
![Page 258: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/258.jpg)
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
![Page 259: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/259.jpg)
54
Try foo.clegg.com etc.
After several queries have
complete clegg.com list:
_jabber._tcp, _xmpp-
server._tcp, alan, alvis,
andrew, brian, calendar, dlv,
googleffffffffe91126e7,
home, imogene, jennifer,
localhost, mail, wiki, www.
The clegg.com administrator
disabled DNS “zone transfers”
— but then leaked the same data
by installing DNSSEC.
(This was a real example.)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
![Page 260: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/260.jpg)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
![Page 261: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/261.jpg)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
![Page 262: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/262.jpg)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
![Page 263: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/263.jpg)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
![Page 264: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/264.jpg)
56
Summary: Attacker learns
all n names in an NSEC zone
(with signatures guaranteeing
that there are no more)
using n DNS queries.
This is not a good approach.
DNSSEC purists disagree:
“It is part of the design
philosophy of the DNS
that the data in it is public.”
But this notion is so extreme
that it became a
public-relations problem.
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
![Page 265: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/265.jpg)
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
![Page 266: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/266.jpg)
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
![Page 267: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/267.jpg)
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
![Page 268: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/268.jpg)
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
![Page 269: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/269.jpg)
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
![Page 270: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/270.jpg)
57
New DNSSEC approach:
1. “NSEC3” technology:
Use a “one-way hash function”
such as (iterated salted) SHA-1.
Reveal hashes of names
instead of revealing names.
“There are no names with
hashes between : : : and : : : ”
2. Marketing:
Pretend that NSEC3 is
less damaging than NSEC.
ISC: “NSEC3 does not allow
enumeration of the zone.”
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
![Page 271: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/271.jpg)
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
![Page 272: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/272.jpg)
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
![Page 273: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/273.jpg)
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
![Page 274: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/274.jpg)
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
![Page 275: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/275.jpg)
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
![Page 276: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/276.jpg)
58
Reality: Attacker grabs the hashes
by abusing DNSSEC’s NSEC3;
computes the same hash function
for many different name guesses;
quickly discovers almost all names
(and knows # missing names).
DNSSEC purists: “You could
have sent all the same guesses
as queries to the server.”
4Mbps flood of queries is under
500 million noisy guesses/day.
NSEC3 allows typical attackers
1000000 million to 1000000000
million silent guesses/day.
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
![Page 277: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/277.jpg)
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
![Page 278: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/278.jpg)
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
![Page 279: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/279.jpg)
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
![Page 280: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/280.jpg)
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
![Page 281: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/281.jpg)
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
![Page 282: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/282.jpg)
59
This is crazy!
Imagine an “HTTPSEC”
that works like DNSSEC.
Store a signature next to
every web page.
Recompute and store signature
for every minor wiki edit,
and again every 30 days.
Any failure: HTTPSEC suicide.
Dynamic content? Give up.
Replay attacks work for 30 days.
Filename guessing is much faster.
Nothing is encrypted.
Denial of service is trivial.
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
![Page 283: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/283.jpg)
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
![Page 284: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/284.jpg)
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
![Page 285: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/285.jpg)
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
![Page 286: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/286.jpg)
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
![Page 287: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/287.jpg)
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
![Page 288: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/288.jpg)
60
Does DNS security matter?
There are some IP addresses
signed with DNSSEC, and some
caches checking signatures.
Never mind all the problems.
Do these signatures
accomplish anything?
Occasionally these caches
are on client machines,
so attacker can’t simply
forge packets from cache : : :
so attacker intercepts and forges
all the subsequent packets:
web pages, email, etc.
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
![Page 289: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/289.jpg)
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
![Page 290: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/290.jpg)
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
![Page 291: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/291.jpg)
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
![Page 292: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/292.jpg)
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
![Page 293: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/293.jpg)
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
![Page 294: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/294.jpg)
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
![Page 295: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/295.jpg)
61
Administrator can use HTTPS
to protect web pages
: : : but then what attack
is stopped by DNSSEC?
DNSSEC purists criticize HTTPS:
“You can’t trust your servers.”
DNSSEC signers are offline
(preferably in guarded rooms).
DNSSEC precomputes signatures.
DNSSEC doesn’t trust servers.
But DNSSEC is not signing
any of the user’s data!
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
![Page 296: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/296.jpg)
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
![Page 297: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/297.jpg)
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
![Page 298: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/298.jpg)
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
![Page 299: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/299.jpg)
62
PGP signs the user’s data.
PGP-signed web pages and email
are protected against
misbehaving servers,
and against network attackers.
With PGP, what attack
is stopped by DNSSEC?
With HTTPS but not PGP, what
attack is stopped by DNSSEC?
With neither HTTPS nor PGP,
what attack is stopped by
DNSSEC?
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
![Page 300: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/300.jpg)
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
![Page 301: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/301.jpg)
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
![Page 302: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/302.jpg)
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
![Page 303: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/303.jpg)
63
Getting out of the mess
State-of-the-art ECC
is fast enough to
authenticate and encrypt
every packet.
Deployed: DNSCurve protects
DNS packets, server→cache.
Deployed: DNSCrypt protects
DNS packets, cache→client.
Work in progress: HTTPCurve
protects HTTP packets.
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
![Page 304: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/304.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
![Page 305: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/305.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
No problems with
dynamic data.
![Page 306: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/306.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
No problems with
dynamic data.
No problems with
old data: all results
are guaranteed to be fresh.
![Page 307: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/307.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
No problems with
dynamic data.
No problems with
old data: all results
are guaranteed to be fresh.
No problems with
nonexistent data,
database leaks, etc.
![Page 308: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/308.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
No problems with
dynamic data.
No problems with
old data: all results
are guaranteed to be fresh.
No problems with
nonexistent data,
database leaks, etc.
Packets are small.
Smaller amplification
than existing protocols.
![Page 309: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/309.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
No problems with
dynamic data.
No problems with
old data: all results
are guaranteed to be fresh.
No problems with
nonexistent data,
database leaks, etc.
Packets are small.
Smaller amplification
than existing protocols.
66
DNSCurve and DNSCrypt
and HTTPCurve and SMTPCurve
add real security even to
PGP-signed web pages, email.
Improved confidentiality:
e.g., is the user accessing
firstaid.webmd.com or
diabetes.webmd.com?
Improved integrity:
e.g., freshness.
Improved availability:
attacker forging a packet
doesn’t break connections.
![Page 310: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/310.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
No problems with
dynamic data.
No problems with
old data: all results
are guaranteed to be fresh.
No problems with
nonexistent data,
database leaks, etc.
Packets are small.
Smaller amplification
than existing protocols.
66
DNSCurve and DNSCrypt
and HTTPCurve and SMTPCurve
add real security even to
PGP-signed web pages, email.
Improved confidentiality:
e.g., is the user accessing
firstaid.webmd.com or
diabetes.webmd.com?
Improved integrity:
e.g., freshness.
Improved availability:
attacker forging a packet
doesn’t break connections.
![Page 311: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/311.jpg)
64
Crypto is at edge of network,
handled by simple proxy.
Administrator puts public key
into name of server.
Need new DNS cache software
but no need to change
server software,
database-management software,
web interfaces, etc.
Easy to implement,
easy to deploy.
65
No precomputation.
No problems with
dynamic data.
No problems with
old data: all results
are guaranteed to be fresh.
No problems with
nonexistent data,
database leaks, etc.
Packets are small.
Smaller amplification
than existing protocols.
66
DNSCurve and DNSCrypt
and HTTPCurve and SMTPCurve
add real security even to
PGP-signed web pages, email.
Improved confidentiality:
e.g., is the user accessing
firstaid.webmd.com or
diabetes.webmd.com?
Improved integrity:
e.g., freshness.
Improved availability:
attacker forging a packet
doesn’t break connections.
![Page 312: cr.yp.tocr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-4x3.pdf2016/12/08 · 1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit](https://reader036.fdocuments.in/reader036/viewer/2022070823/5f31dc1018798a5be9450728/html5/thumbnails/312.jpg)
65
No precomputation.
No problems with
dynamic data.
No problems with
old data: all results
are guaranteed to be fresh.
No problems with
nonexistent data,
database leaks, etc.
Packets are small.
Smaller amplification
than existing protocols.
66
DNSCurve and DNSCrypt
and HTTPCurve and SMTPCurve
add real security even to
PGP-signed web pages, email.
Improved confidentiality:
e.g., is the user accessing
firstaid.webmd.com or
diabetes.webmd.com?
Improved integrity:
e.g., freshness.
Improved availability:
attacker forging a packet
doesn’t break connections.