back to article Will DNSSEC kill your internet?

Internet users face the risk of losing their internet connections on 5 May when the domain name system switches over to a new, more secure protocol. While the vast majority of users are expected to endure the transition to DNSSEC smoothly, users behind badly designed or poorly configured firewalls, or those subscribing to dodgy …

COMMENTS

This topic is closed for new posts.
Silver badge
Thumb Up

With any luck it'll block ISP redirects

"Mitchell said he's also concerned about ISPs that rewrite DNS answers as they pass across their networks. Some ISPs do this to redirect their customers to cash-making search pages "

Quite , and hopefully this shameful hijacking of peoples lookups will now stop as its bloody annoying and since the virgin media redirect system doesnt care what sort of service you're connecting to - it assume in the typical braindead virgin fashion that people are only ever connecting to TCP port 80 - you can get very odd results. For exampling telneting or ftp'ing to an address which then instead of getting host not found you just get a hung connection or a disconnect since you unwittingly attempting to connect to a web server at virgin HQ.

0
0
Headmaster

@boltar

if your PC is still setup to use the ISP's DNS servers, then you will still be facing the same problem.

you might wish to read more about DNS's, the way they work is simple and short.

P.S. the result returned by your ISP DNS servers will be *signed*, wither it is redirecting your traffic or not is irrelevant.

0
1

if you don't like it...

... why haven't you opted out?

https://my.virginmedia.com/advancederrorsearch/settings

1
1
Paris Hilton

Opt out my buttocks

I have to jump on this and say that we should not have to opt-out from non-standard workings, just the same as I feel we should not have to opt-out (or at least not pay for the opt-out) not receiving marketing phone calls.

Along those lines, does Virgin offer a discount for your service if you do not opt-out of their advertising hijacking?

Paris, hi, Jack!

1
0
Anonymous Coward

Windows?

Any chance of some links for the 95% of us who use Windows, please?

4
7
Silver badge

Sir

If you aren't a troll, perhaps you might want to elaborate on your request. What does running Windows have to do with it?

4
0
Bronze badge

to test the DNS

the link is for linux servers

0
2
Stop

use the Java applet linked to in the article.

title.

0
0
Thumb Down

@Sir R Spoon

"You can test whether your current DNS resolver is capable of handling DNSSEC, by following the instructions at DNS-OARC or running a Java app that can be downloaded from RIPE."

Did you look at those links? If so, you wouldn't have questioned my request to have something that Windows users could use...

0
5
Anonymous Coward

Not limited to linux

'dig' is available for Windows too. Search for 'installing dig windows' and you should find plenty of instructions.

1
0

Alternatively, read the nslookup manual

nslookup -timeout=60 -q=txt -debug rs.dns-oarc.net

1
0
Silver badge

Sir

@AC

My bad, I thought you could download the app and run it, even on Windows.

Hmm, let me try that..

"Test results

for resolver: 192.168.1.1

Announced buffer size:

4096 bytes

Measured buffer size:

1399 bytes

EDNS enabled:

yes

DNSSEC enabled:

yes"

Yep, that works ok. Now, what were you saying again?

4
0
Bronze badge
Troll

trolling, trolling...

1 It's not correct that 95% of the world uses Windows. Closer to 85%. Given that 85% is a _massive_ majority, exaggerating it merely makes you look silly.

2 one of the links is for a Java applet. It works in Linux, UNIX, Mac OS X... and Windows. At least it works in Windows 7 Pro, as on my work laptop... (Apparently my work wireless router is DNSSEC ready...)

3 you're not real bright, are you?

4
0
Silver badge

Fail

Sir, you fail. Utterly.

The Java app referenced above runs (or should run) on any up to date Java Virtual Machine, or JVM for short. There are JVMs available for any flavor of Windows, and lots of applications use and/or install a JVM. You should also consider reading the links yourself before accusing Mr.Spoon of not having read them before.

1
0
Boffin

@Lionel Baden

"the link is for linus servers"

No it isn't. The link tells you how to use dig, which has been available for windows for more than 7 years, to test your DNS.

0
0
Paris Hilton

this story is bollocks

It is simply not true that "from 5 May all the DNS root servers will only respond with signed DNSSEC answers". They will only return signed DNSSEC answers to queries that have explicitly asked for them. Because that is how DNSSEC works. So if your DNS servers don't set the DO bit on their outbound queries, the root servers will continue replying with the unsigned root zone data, just as they've always done.

Queries with the DO bit set are only supposed to come from servers that support DNSSEC and are prepared to validate signed answers. Sadly one of the most common DNS implementation (BIND9), sets this bit by default. Even if the server has no DNSSEC support compiled in or it hasn't been configured. There's no config file optoon to switch off this broken default. The only way to fix this is to patch the source code and recompile. Or complain to ISC and get them to release a patch.

Paris icon 'cos she's done some stupid things too.

1
0
Heart

@ disabling DNSSEC in BIND 9?

I don't get it. What's wrong with "dnssec-enable no" in your named.conf? I haven't tested it myself (no handicapped network connections here) but I can't see why it wouldn't work.

(If you're referring to the mess with a certain python script mangling named.conf, that's hardly a BIND problem.)

0
0
FAIL

Perhaps you should read the RFC's before you post.

DO *only* indicates that you UNDERSTAND DNSSEC records.

DO does NOT, and never has, indicated that you intend to validate the response.

B.T.W. it is not DO but EDNS that permits larger than 512 byte responses and the root servers have been sending them for years now, look at almost every referral from the root servers for COM and NET lookups. Even with DO *not* set they exceed 512 bytes.

% dig +edns=0 example.com @j.root-servers.net

; <<>> DiG 9.7.0 <<>> +edns=0 example.com @j.root-servers.net

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27983

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 16

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;example.com. IN A

;; AUTHORITY SECTION:

com. 172800 IN NS B.GTLD-SERVERS.NET.

com. 172800 IN NS H.GTLD-SERVERS.NET.

com. 172800 IN NS G.GTLD-SERVERS.NET.

com. 172800 IN NS C.GTLD-SERVERS.NET.

com. 172800 IN NS E.GTLD-SERVERS.NET.

com. 172800 IN NS L.GTLD-SERVERS.NET.

com. 172800 IN NS F.GTLD-SERVERS.NET.

com. 172800 IN NS K.GTLD-SERVERS.NET.

com. 172800 IN NS A.GTLD-SERVERS.NET.

com. 172800 IN NS J.GTLD-SERVERS.NET.

com. 172800 IN NS D.GTLD-SERVERS.NET.

com. 172800 IN NS I.GTLD-SERVERS.NET.

com. 172800 IN NS M.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:

A.GTLD-SERVERS.NET. 172800 IN A 192.5.6.30

A.GTLD-SERVERS.NET. 172800 IN AAAA 2001:503:a83e::2:30

B.GTLD-SERVERS.NET. 172800 IN A 192.33.14.30

B.GTLD-SERVERS.NET. 172800 IN AAAA 2001:503:231d::2:30

C.GTLD-SERVERS.NET. 172800 IN A 192.26.92.30

D.GTLD-SERVERS.NET. 172800 IN A 192.31.80.30

E.GTLD-SERVERS.NET. 172800 IN A 192.12.94.30

F.GTLD-SERVERS.NET. 172800 IN A 192.35.51.30

G.GTLD-SERVERS.NET. 172800 IN A 192.42.93.30

H.GTLD-SERVERS.NET. 172800 IN A 192.54.112.30

I.GTLD-SERVERS.NET. 172800 IN A 192.43.172.30

J.GTLD-SERVERS.NET. 172800 IN A 192.48.79.30

K.GTLD-SERVERS.NET. 172800 IN A 192.52.178.30

L.GTLD-SERVERS.NET. 172800 IN A 192.41.162.30

M.GTLD-SERVERS.NET. 172800 IN A 192.55.83.30

;; Query time: 178 msec

;; SERVER: 2001:503:c27::2:30#53(2001:503:c27::2:30)

;; WHEN: Thu Apr 15 14:11:43 2010

;; MSG SIZE rcvd: 528

%

DO does increase the size further still but not by much (713 vs 528 bytes for this example query).

% dig +dnssec example.com @a.root-servers.net

; <<>> DiG 9.7.0 <<>> +dnssec example.com @a.root-servers.net

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40553

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 16

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;example.com. IN A

;; AUTHORITY SECTION:

com. 172800 IN NS d.gtld-servers.net.

com. 172800 IN NS e.gtld-servers.net.

com. 172800 IN NS g.gtld-servers.net.

com. 172800 IN NS h.gtld-servers.net.

com. 172800 IN NS i.gtld-servers.net.

com. 172800 IN NS m.gtld-servers.net.

com. 172800 IN NS a.gtld-servers.net.

com. 172800 IN NS j.gtld-servers.net.

com. 172800 IN NS b.gtld-servers.net.

com. 172800 IN NS l.gtld-servers.net.

com. 172800 IN NS k.gtld-servers.net.

com. 172800 IN NS f.gtld-servers.net.

com. 172800 IN NS c.gtld-servers.net.

com. 86400 IN NSEC coop. NS RRSIG NSEC

com. 86400 IN RRSIG NSEC 8 1 86400 20100422000000 20100414230000 55138 . s1ldDSeyP6mrfQCiDqy+cRpQMQOgohAmvycezbHIAgsgu61Z/O4qMEQJ m5HxFEtWrGU1b9C/Y26y3kJslMOzvP1jtvBt78bJnBEz+sN9eFYxeKG7 KQ+Daq56+M3kpH2pldqI1nn5QpNl0fzMUOdkq8xOnmABDpdM+aAcdB2f nGg=

;; ADDITIONAL SECTION:

a.gtld-servers.net. 172800 IN A 192.5.6.30

a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30

b.gtld-servers.net. 172800 IN A 192.33.14.30

b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30

c.gtld-servers.net. 172800 IN A 192.26.92.30

d.gtld-servers.net. 172800 IN A 192.31.80.30

e.gtld-servers.net. 172800 IN A 192.12.94.30

f.gtld-servers.net. 172800 IN A 192.35.51.30

g.gtld-servers.net. 172800 IN A 192.42.93.30

h.gtld-servers.net. 172800 IN A 192.54.112.30

i.gtld-servers.net. 172800 IN A 192.43.172.30

j.gtld-servers.net. 172800 IN A 192.48.79.30

k.gtld-servers.net. 172800 IN A 192.52.178.30

l.gtld-servers.net. 172800 IN A 192.41.162.30

m.gtld-servers.net. 172800 IN A 192.55.83.30

;; Query time: 179 msec

;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)

;; WHEN: Thu Apr 15 14:15:04 2010

;; MSG SIZE rcvd: 713

%

Even NXDOMAIN responses are not that large. However if you have a firewall that blocks

UDP responses bigger than 512 bytes but permits EDNS and DO and also blocks out bound

TCP lookups then the NXDOMAIN response won't get through.

% dig +dnssec example.wy @a.root-servers.net

; <<>> DiG 9.7.0 <<>> +dnssec example.wy @a.root-servers.net

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20276

;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;example.wy. IN A

;; AUTHORITY SECTION:

. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010041401 1800 900 604800 86400

. 86400 IN RRSIG SOA 8 0 86400 20100422000000 20100414230000 55138 . FfgJf7vv3i4f63s0B+joYLeCf0/HyMfJrPx2Z0ziwe5N5Wec6AJ2EQ6Q tzvbNYq+bAVsl+vABooW6f+JiXDiLh9EO3uOIieyYXX7UFW8liDKcCXx fyaQkXXjcRmBo89AZxeBjW8FIKg5BEqLafugrvihl1uBhyD7o0lk/Fbw G8A=

. 86400 IN NSEC ac. NS SOA RRSIG NSEC DNSKEY

. 86400 IN RRSIG NSEC 8 0 86400 20100422000000 20100414230000 55138 . Xq36MvWZCGpC1tv2IX/PdoJrGe4Kn2W2g3mVyG1+D1UTWHU0wPf0BKIH 68dHAS5QbcQ/27PoVPG9L7RzVf2aTasxl9B7OTy3mWbph8Qv0nIPXsvf jvdps0m/GHxlDnVEn+k3KD6thX4dc6D8pIN7t7lBQXq1BDnGJMavUfPf OPI=

ws. 86400 IN NSEC xn--0zwm56d. NS RRSIG NSEC

ws. 86400 IN RRSIG NSEC 8 1 86400 20100422000000 20100414230000 55138 . iXxgGMRrrOl19l5Mftm3MwtatCdvYgqcKy5JNRerYVLe4A/gsI+y2xSk Zj7cS7up9TT1ltoC5EfRKPF3nxFWXMZ/bXkQzzwWVU0JR9NuFI+q76pE JatWYlbQsbyKBxLO+KYsXEwn09pAOyPHwMZhqFfe0FX31Ni7J1leMoiA e+o=

;; Query time: 183 msec

;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)

;; WHEN: Thu Apr 15 14:18:51 2010

;; MSG SIZE rcvd: 648

%

0
0
Stop

Not just config issues

I've seen a router have problems with large UDP packets that wasn't just down to configuration. The packets were being fragmented and when they were reconstituted in the router they didn't fit in one of the internal buffers, leading to dropped packets. Small packets were fine. I can't remember exactly, but it was related to a bug in how the router performed NAT on the packet. The answer was a firmware patch to do things in the correct order.

0
0

Non-issue

.org has had its root signed for a while *and nobody has even noticed*. Scaremongering helps nobody.

Of course it's precisely this transparency (that you can MITM DNSSEC simply by zeroing a bit) that makes the whole exercise a bit pointless...

1
0
FAIL

eh?

WTF?

.org doesn't have its own root. or is a top-level domain. the root's the thing that sits above the top-level domains.

your comments about a man-in-the-middle attack on dnssec make no sense. the whole idea of dnssec is to detect attempts to tamper with dns responses. so zeroing a bit will stop the signatures from validating.

2
0
Black Helicopters

Yes / No

True, .org has run with DNSSEC signatures, if requested, for quite some time. As have .gov, .se, .cz, .br and many others. As does the root zone *already* on several servers. The internet didn't go down then. A few networks had trouble with their packet filters being too restrictive but probably most of them have been fixed by now. Those who will be affected on May 5th, when *all* root zone servers provide signed content, should have clued up their network administrators two years ago.

As for your other comment, that's not exactly true. If your resolver has a trust anchor for .org, either configured manually or discovered and validated in the root zone, it will insist on signed responses and discard unsigned answers. You cannot MITM DNSSEC "simply by zeroing a bit" (what bit, btw?)

0
0
Thumb Down

@Windows?

FYI (anonymous coward and all those upvoting the post):

Much of the infrastructure behind the internet is UNIX based. As a result the links given are very relevant. As mentioned in the article home users need not bother too much with this.

If you don't know how to (or cannot) use the dig tool then I suspect you aren't the target audience for this article. Not only that, but a quick visit to google for "dig tool" will give you a fairly relevant result set.

Of course, I have no idea if the software works or if it's dodgy. It is, however, the fourth result down the line. How much do we need to be spoon fed, really?

9
0
Anonymous Coward

@How much do we need to be spoon fed, really?

Surely it would have been ever so simple for the author of the article to have done just a little more work, thus obviating the requirement for almost all the El Reg readers to each do her/his own Googling, installing random software, and so on, reinventing the wheel many, many times? I mean, we all have nothing better to do, have we...

3
4

In fairness...

From the comments, and as has been said, considering the target audience for the article, "almost all the El Reg readers" knew what to do already.

2
0
Silver badge

The Java Application advice

Test results for resolver: 123.456.7. 890

Announced buffer size: 512 bytes

Measured buffer size: 486 bytes

EDNS enabled: no

DNSSEC enabled: no

Your resolver does not have DNSSEC enabled.

Your resolver was only able to get packets SMALLER than 512 bytes.

This usually implies that a packet filter or firewall is blocking UDP packets bigger than 512 bytes from reaching your resolver. Your resolver works now, although it is probably not able to resolve some names. However, when the root zone is signed your resolver will not be able to receive most responses, and it is possible that you will lose DNS service. You should reconfigure your firewall or packet filter to allow large UDP packets through.

So far so good?

3
0
Gold badge
Coat

WTF?

Were those, as it is said some times much and most Over UDP in the root Zone, NuKLEAR packets from the Lizards Of DNSSEC Resolution amanfromMars 1?

2
0
Badgers

amanfromBackwater ?

dunno marsman .. I'm in USA .. WinXP .. AT&T DSL .. 6 year old DSL Modem with a cheap MSI WiFi router

-------------------------------------------------------------------------------------------

Test results

for resolver: 192.168.0.1

Announced buffer size:

4096 bytes

Measured buffer size:

3839 bytes

EDNS enabled: yes

DNSSEC enabled: yes

Your resolver announced a buffer size bigger than the largest packet that it can receive.

Note: There will always be a difference between the announced and measured buffer size because of the algorithm used. However this difference should not exceed 300 bytes.

---------------------------------------------------------------------------------------------

so far so good for me ...

0
0
Silver badge

@anon

"if your PC is still setup to use the ISP's DNS servers, then you will still be facing the same problem.

you might wish to read more about DNS's, the way they work is simple and short."

Thanks , I know how DNS works , but using other DNS servers sometimes causes major lag when doing look ups.

1
0
Badgers

Handbags at dawn?

oooh, it's getting bitchy in here isn't it?

3
1
Grenade

DNSCurve pillowfight?

The DNS opera has more politics, trolls and fanboi camps than one could imagine. Have you ever been to a IETF workgroup meeting?

Funny, nobody said "DNSCurve" yet.

0
0
Happy

@pillowfight

> Funny, nobody said "********" yet.

You just did. :-) But let's keep this discussion humane and civilized please.

0
0
Troll

method in link is broken

I typed "$ dig +short rs.dns-oarc.net txt " and it didn't do nothing. Maybe I need to save it as .docx instead of .doc? Or is it specific to OpenOffice in Linux as the other comments suggest? The linked page doesn't give much details.

... I'll be going now

2
3
Happy

Why the downvotes?

This is actually the funniest post so far. Some people have no humour it seems...

1
0
Pint

AC @ 15:46

"oooh, it's getting bitchy in here isn't it?"

But. But. That's precisely why most of us come to the comments pages. Isn't it now? :-)

PS Anyone tested Google's (8.8.8.8) with the tools mentioned, I would but it's now past beer o'clock.

0
0
FAIL

8.8.8.8

dig @8.8.8.8 +short rs.dns-oarc.net txt

rst.x476.rs.dns-oarc.net.

rst.x485.x476.rs.dns-oarc.net.

rst.x490.x485.x476.rs.dns-oarc.net.

"209.85.228.94 DNS reply size limit is at least 490"

"209.85.228.94 lacks EDNS, defaults to 512"

"Tested at 2010-04-13 20:09:33 UTC"

Woops!

1
0

same here

i got the same result for openDNS!

0
0
Gates Halo

@problems using 8.8.8.8

Are you guys sure it's not something between you and 8.8.8.8?

[20:45:36 prathlev@euler ~]$ dig @8.8.8.8 +short rs.dns-oarc.net txt

rst.x1247.rs.dns-oarc.net.

rst.x1257.x1247.rs.dns-oarc.net.

rst.x1228.x1257.x1247.rs.dns-oarc.net.

"74.125.42.94 DNS reply size limit is at least 1257"

"74.125.42.94 sent EDNS buffer size 1280"

"Tested at 2010-04-14 18:45:23 UTC"

[20:45:36 prathlev@euler ~]$

(Yes, my timezone is GMT+2)

0
0
Gold badge

512 bytes?

Since UDP is pretty much intended to give you a layer 4 equivalent to to frames on the wire, and since ethernet frames have been larger than 512 bytes for several decades, I have to conclude that the problem is probably being exaggerated here.

That said, even one such device is one too many. Anyone who drops UDP packets on the basis of length really needs to be fragmented, pushed down a narrow pipe, and probably not re-assembled at the far end.

2
0
FAIL

UDP and 512 byte DNS replies

Your conclusions are wrong because your assumptions are wrong. There is a real problem and it's not being exaggerated. (Though it would be less serious if those stupid fuckers at ISC hadn't made BIND always set the DO bit and failed to provide a configuration file option to control this idiot behaviour.) There is a lot of crippleware that believes DNS traffic only goes in UDP datagrams of under 512 bytes. This crap needs to be fixed and that's the issue.

When DNS started, it used a 512 byte UDP limit with TCP retries as a fallback for truncated responses. This was because 576 byte was the minimum frame size on the ARPAnet. So 512 bytes of UDP was guaranteed to cross the network without fragmentation. The other 64 bytes go on IP and UDP packet headers BTW.

Many firewall and middleware vendors have worked from the bogus assumption that DNS always goes over UDP and never exceeds 512 bytes. DNSSEC kills that. And now that DNSSEC is happening for real, the suplliers and users of these broken products are fucked. They *have* to fix them. There are many vendors in this hall of shame, some who should have known better. Cisco's PIX firewall didn't let EDNS0 traffic through until fairly recently.

0
0
FAIL

No Fragmentation Myth at 512 Bytes.

The 512 byte limit was so that reassembly would work. 512 byte UDP/IPv4 packets can be fragmented.

0
0

god I hope so

I can use a little time away from 95% of my email coming from third world countries financed by liberal internet steering groups.

I know these crackpot setups that don't even recognize mx records let alone anything else will be a few years behind unless some organizations funded in part by the US and other governments hand out some more money to make sure third-world networks can continue to grow and be hijacked for spam.

0
1
Go

Reports of Internet Death Exaggerated..

Despite the scary headline above, no-one is going to completely lose Internet service as a result of the signed root, or indeed any DNSSEC deployment efforts, and I certainly didn't say that. The worst that is going to happen is that a tiny minority of users behind mis-configured firewall or middleware boxes *may* experience some performance degradation when their clients have to attempt alternative paths for resolving names.

Data gathered by DNS-OARC on the root signing transition [see http://www.root-dnssec.org/wp-content/uploads/2010/03/rootsign-ietf77-qa.pdf] to date indicates that this will at worst be a very small proportion of Internet users.

0
0

wrong place

I know this is the wrong place to ask technical questions, but WTF here goes...

Does anyone know how to configure ISA 2006 firewall to allow EDNS packets through?

Yes, I have googled and searched Technet, but no joy.

0
0
Joke

Making MS ISA 2006 do EDNS0

Simple: Press the "Start"-button, choose to shut down the machine. Insert a CentOS 5 DVD and install from there. In about 30 minutes you will have a server that can do EDNS0. Name it "msisa" or something for nostalgic reasons.

1
0
Happy

OpenDNS...

Anyone...?

I have used it for years in favour of any home ISP DNS cludgefuck.

0
0
Thumb Up

Re:OpenDNS

I use it at work and I think itsF##''ing brilliant, but what do I know.

0
0
Thumb Up

works here...and IPv6 too

$ dig +short rs.dns-oarc.net txt

rst.x4091.rs.dns-oarc.net.

rst.x4049.x4091.rs.dns-oarc.net.

rst.x4055.x4049.x4091.rs.dns-oarc.net.

"2001:6xx:xxxx:xxxx:211:43ff:fee7:a2b sent EDNS buffer size 4096"

"Tested at 2010-04-14 19:19:16 UTC"

"2001:6xx:xxx:xxxx:211:43ff:fee7:a2b DNS reply size limit is at least 4091"

0
0

This post has been deleted by its author

This topic is closed for new posts.

Forums