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.
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:
network equipment blocks or otherwise filters long DNS responses, and.
whose DNS servers send upstream queries with the DO bit set.
Yes, DNSSEC can detect false IP information and prevent spoofed NXDOMAIN responses, but only if the domain you're querying and all of its parent domains are DNSSEC signed.
No, you've missed the point. You can (and should) still have all those IDs. But they can be found by looking them up in the ENUM database with your telephone number as the key.
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.
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.
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!.
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.
Actually Comcast's DNS re-writer only works if the domain name being looked up starts 'www.'.
I was told this directly by Comcast's top DNS man, and the Comcast doc linked above says so too.
What would be really interesting would be to see how many more generations it takes to get from the current polygon set into a picture of someone else !
Firstly, please let me clarify a few points about the article and the way stuff is run at Oxford:
the University provides the inter-building network infrastructure, but each College and Department is responsible for running its own internal network
there is no indication in the article that any University-maintained network infrastructure was penetrated.
My understanding of what has probably happened is that one or more colleges have skimped on network hardware and not installed the recommended switched network equipment with MAC address protection.
Alternatively the students may have found a way to defeat the security on the switch they're connected to that allowed them to mirror other ports' traffic down their port.
Although they did sniff passwords for a University provided e-mail service, it seems that everything they did was within a college network.
To say that the University network was hacked, as both the/. article and the student rag suggests is not accurate and vastly inflates the scale of what these students "achieved".
The boot process is just DHCP/TFTP, although the window's DHCP server uses a non-standard port. However the boot-loader in the MediaMVP supports both that port and the standard DHCP port, anyway.
Mine boot just fine from ISC dhcpd off my Linux box, you just need to set the TFTP filename to the "dongle.bin" file extracted from the software installer on the HCW site.
AFAIK, Hauppauge are now complying correctly,
they've got the relevant Busybox sources, and also the kernel sources online.
What's not available are the sources to the IBM proprietary kernel modules for the STB25xx processor's hardware features, nor the client program that runs on the MVP once it's booted.
However some enterprising individuals have managed to figure out most all of the ioctl(2) interfaces to those modules, and also developed native player software that doesn't depend on the HCW supplied windows server software.
Personally, I've got a couple of these now, using the mediamvp plugin for VDR (the Linux DVB PVR system) to get both live and recorded digital TV distributed around the house.
The best link I know of for discussions on using Linux on the MediaMVP are the forums at http://www.shspvr.com/forum/
And what if some bastard nicks that 400 disc changer with your 400 discs still in it?
The media server method might well be more expensive in initial hardware costs, but at least if someone walks off with it you might still have the $8000 worth of original discs left behind!
Slashdot Mirror
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:
Yes, DNSSEC can detect false IP information and prevent spoofed NXDOMAIN responses, but only if the domain you're querying and all of its parent domains are DNSSEC signed.
He would, if that was actually his name. The Comcast guy as actually Chris Griffiths.
No, you've missed the point. You can (and should) still have all those IDs. But they can be found by looking them up in the ENUM database with your telephone number as the key.
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.
Actually Comcast's DNS re-writer only works if the domain name being looked up starts 'www.'. I was told this directly by Comcast's top DNS man, and the Comcast doc linked above says so too.
Yeah, but will it be an upgrade or a full version? I don't have a copy of Vista to upgrade from.
Yup, at my last job I wrote a RADIUS server just from the RFCs. It's still in full production use now.
What would be really interesting would be to see how many more generations it takes to get from the current polygon set into a picture of someone else !
Perhaps someone could point D-Link at http://tools.ietf.org/id/draft-bellis-dnsext-dnsproxy-00.txt ?
Firstly, please let me clarify a few points about the article and the way stuff is run at Oxford:
My understanding of what has probably happened is that one or more colleges have skimped on network hardware and not installed the recommended switched network equipment with MAC address protection.
Alternatively the students may have found a way to defeat the security on the switch they're connected to that allowed them to mirror other ports' traffic down their port.
Although they did sniff passwords for a University provided e-mail service, it seems that everything they did was within a college network.
To say that the University network was hacked, as both the /. article and the student rag suggests is not accurate and vastly inflates the scale of what these students "achieved".
Alnitak - Oxford graduate and ex-staffer.
There's nothing that obsucated about it!
The boot process is just DHCP/TFTP, although the window's DHCP server uses a non-standard port. However the boot-loader in the MediaMVP supports both that port and the standard DHCP port, anyway.
Mine boot just fine from ISC dhcpd off my Linux box, you just need to set the TFTP filename to the "dongle.bin" file extracted from the software installer on the HCW site.
AFAIK, Hauppauge are now complying correctly, they've got the relevant Busybox sources, and also the kernel sources online.
What's not available are the sources to the IBM proprietary kernel modules for the STB25xx processor's hardware features, nor the client program that runs on the MVP once it's booted.
However some enterprising individuals have managed to figure out most all of the ioctl(2) interfaces to those modules, and also developed native player software that doesn't depend on the HCW supplied windows server software.
Personally, I've got a couple of these now, using the mediamvp plugin for VDR (the Linux DVB PVR system) to get both live and recorded digital TV distributed around the house.
The best link I know of for discussions on using Linux on the MediaMVP are the forums at http://www.shspvr.com/forum/
And what if some bastard nicks that 400 disc changer with your 400 discs still in it?
The media server method might well be more expensive in initial hardware costs, but at least if someone walks off with it you might still have the $8000 worth of original discs left behind!