Sometimes the price is listed as "ex VAT", so you have to factor in an extra 17.5% on top, but that's almost exclusively done by merchants that are targeting business customers.
Prices advertised to consumers must in UK law be the VAT inclusive price. The "ex VAT" price may also be shown, but the total price has to be the headline price.
Do what works.
Don't get caught.
And that unfortunately, is partly why some people believed (albeit wrongly) that the internet is going to break this week.
The problem with only doing enough to make something "work" is that it doesn't cope with the edge cases, but sometimes those edge cases are important. Introducing DNSSEC exercises many more of those edge cases.
For more information on how not implementing the DNS RFCs properly lead to poor middlebox implementations that could break the internet for some people see RFC 5625.
If your DNS server or stub resolver doesn't request DNSSEC data (by setting the "DO" bit in the request) then the response will be exactly the same as it was before the introduction of DNSSEC. Nothing will break.
The changes will not in general DNS lookups between home PCs and their ISPs.
The people at greatest risk are those (enterprises?) that run their own full DNS servers but whose:
They add your phone number from caller id to their address book.
Yes, and if they install something like my Enumdroid app (ENUM lookups for Android) then any time you call them thereafter it can automatically find their current SIP, Skype, EMail, Jabber, Twitter IDs etc just by looking them up in ENUM keyed off that previously received Caller ID.
Yes, they're supposed to do this DHCP and DNS stuff on the LAN interface.
What they're not supposed to do is respond to DNS queries received on the WAN interface. That's what the survey and article is about.
DNS cache proxies are common on cuonsumer routers.
Actually most of them don't cache - mostly they just forward. Of the ones I've tested only Apple's Airports had a real cache in them.
Of course almost universally these are set to block all requests from outside, so can't really be accused of causing a jump of open resolvers from 50% to 80% on their own.
The increase is interesting, and unexpected. I do know of some brands that are open by default from the outside, but had hoped that the recent research and various realted RFCs might have reduced the incidence of this.
Also any network running authoritative DNS will have an open DNS.. that's unavoidable - although you normally rate limit it with iptables to stop magnification attacks.
The number of authoritative servers on the internet isn't that large, and certainly not on the scale of the problem that Wessels et al have found. It's these dumb proxies that don't have the rate limiting etc that are the problem.
If you are to build a recursive DNS server and have it do recursive queries on the internet completely bypassing your Router and ISP's DNS setup - you are still vulnerable.
Actually, only if you use NAT.
If you have a fixed IP range internally and don't use any NAT then you can use the source port randomisation introduced on most servers after Kaminsky and remain very well protected against cache poisoning.
The real problem is that if you're using NAT each outbound query will have (some of) its source header fields rewritten. So even if the internal recursive server properly picks a random source port, the NAT process in your router might de-randomise it.
It's very common for NAT processes to just pick sequential source ports. The original source port sequence might go 53271, 1095, 37451, but the router might re-write that as 1024, 1025, 1026,
This predictable source port selection algorithm leaves you back where we were pre-Kaminsky.
Umm, say what?!
This is not FUD. The routers have DNS proxies in them. Some of those routers do the equivalent of "listen" on 0.0.0.0:53 and don't block queries arriving on the external interface.
A small query sent to the router from the outside is then forwarded to the ISP's DNS server, which duly sends the answer back to the router, which the router then sends back to the original UDP source address, which was probably spoofed. That response packet can be much larger than the original request, and as far as the victim was concerned it was sent from your router!.
Very very much the same.
Actually, not the same at all. The DNS proxy servers in most home routers are very buggy.
Actually most routers don't have a fully recursive server - they have a "proxy" (or "forwarder").
See my RFC 5625 for more details, and some explanation for why the router even has this feature. The short answer is that it's so that the router can give a consistent DHCP OFFER before it knows what the upstream DNS servers are. See also slides I presented at the IETF DNSOP working group last week: http://tools.ietf.org/agenda/76/slides/dnsop-5.ppt
If the proxy is open on the WAN port then it'll forward all queries to the ISP's real recursive servers, and that's where the recursion happens. It may look as if the router's DNS proxy is recursive, but in most cases it isn't.
The DNS query results from the ISP will go back up the DSL / cable line back to the router, which will then send then back down the line to the (probably spoofed) source IP address of the original request.
Torque is cheap.
