You still have to pay your contracted plan regardless of if you're using it or not, so whether the phone is unlocked is entirely irrelevant.
Except that people have started just giving bogus information and walking off with phones.
That may not be legally 'theft', but it is morally theft. (And not like 'pretend morally theft', like copyright violation. Someone actually took some physical thing of theirs.)
It's fraud, obtaining goods by deception, and is illegal independent of whether the phone is locked or not.
Anyone trying to make any form of unlocking illegal ever should jump off a bridge, and those who build their business models on locked phones without contracts are setting themselves up to get fucked when an unlock method is eventually discovered.
It really depends on the client you are running and what type of answers it expects.
If the client is expecting answers with DNSSEC records (by setting DO in the query) then any modification of a answer like changing NXDOMAIN to a 1.2.3.4 can be detected if the client has a trust anchor that covers that zone (directly or indirectly though a parent zone).
If the client is not expecting answers with DNSSEC records then the recursive server can still ask for the DNSSEC records and validate the answers it receives but send on modified answers to the clients.
That being said it would just be a bad PR exercise to validate then do NXDOMAIN redirection.
This is also not to say that Comcast won't do some re-writting of responses in the future. If they decide to deploy NAT64 then they will need to also deploy DNS64 which work by re-writting answer to AAAA queries if there are no AAAA records but there are A records. How to do DNS64 with validating DNSSEC clients is still being worked out but will almost certainly require the client to do the DNS64 synthesis itself.
Once you have a secure DNS, you can then use if to provide secure linkage to other things. While still a while off yet. it is coming. SSH can already take advantage of this. Look at the "keyassure" work starting in the IETF. I'm pretty sure there will be a formal BoF in Beijing in a couple of weeks. There was a informal BoF at the last IETF in Maastricht.
Comcast almost certainly already supports NSEC3 in their validators as that is required to validate the root zone. Yes the root zone is using NSEC but the algorithm in use requires that the validator support NSEC3. All the DNS vendors that support DNSSEC validation ship products that validate responses from zones using NSEC3.
You can see if Comcast recursive servers are validating the root zone by running "dig +dnssec DNSKEY." and looking for the "ad" flag.
As to whether Comcast decide to use NSEC or NSEC3 when signing their zones, well that is up to them. I'm sure Comcast can do their own risk analysis about their zones. I can tell you that it is a waste of time to use NSEC3 in a reverse zone as it is too highly structured.
Uh, you do realize that the Catholic Bishops were talking about legalizing child pornography and homosexual statutory rape(altar boys), rather than marijuana, right?
You do realise that child pornography is illegal and hence can't be classified R18+. There is lots of content that is and will be refused classification, be it print, video or games. R18+ is not a free for all. It is still limited.
You can still have version control and automatic re-signing. You just don't version control the master file that the name server uses. It's relatively straight forward to make a tool that will take a unsigned master file and generate a delta against the current signed zone contents and use that as the post commit action. The only thing that won't be consistent is the SOA serial.
I didn't see anyone paying for namespace in p2p networks or on I2P/FreeNet/etc., maybe we don't need to have parent domains?
While cryptographic hash will identify things they leave a lot in terms of usability. <whatever>@<short>.freenet does not scale.
And you do realize that domains like.biz,.info,.jobs, and all those new weird domain were only created because they knew every company wouldn't risk not registering their name everywhere they could and that would give them a huge revenue source? Centralized political corruption indeed...
I once said to Jon, over lunch, we should get rid of GTLD's. There are very few GLTD's that are useful. That said GTLDs != DNS.
Automatic zone signing only work on dynamic zones in 9.6 AFAIK. Might be different in 9.7.
How else to expect named to know it has change control on the zone? Remember all zones are dynamic. Just that there are different change mechanisms involved. Also just because it is dynamic that doesn't mean that anyone can change the contents. By using UPDATE named can update all the relevant records that are involved in a change. Yes, this is a change in how one does things but one that is for the better I believe.
The fact that you can't get a domain for 0$ implies that this is hierarchical and not free in any sense of the word which worries me and implies struggle about who controls the distribution... I'm no expert on BGB / DNS though.
Firstly, you can get domains for $0. I have one. I also have ones I pay for.
Secondly, there are real ongoing costs to be covered and the small costs associated with most parent domains are reasonable or do you expect to everyone to give you a free lunch?
Signing yourdomain.com requires you and.com to perform a transaction (registrar will perform on behalf of.com) that must recur at some interval for KSK and ZSK updates.
Really? Splitting keys into KSK and ZSK keys was done so that you DON'T need need to contact the parent zone administrator to roll the keys that sign the zone content. You do need to contact the parent when you update the KSK's but that should be much less often than the ZSK's are changed.
You do realise that you don't need to run dnssec-signzone anymore to sign a zone?
All vendors DNSSEC tools are improving. Perhaps you should do some research before complaining? Remember DNSSEC really is still in the very early stages of deployment and usability will continue to increase.
And I suspect that it puts Apple, Blackberry etc. in contravention of the Australian Spam Act 2003. Adding this make the email commercial advertising and it is being sent without the explicit consent of the recipient and has no unsubscribe method.
This is a question you need to ask browser vendors. Putting a self-signed CERT in the DNS is relatively easy. There is even a specific record type, CERT, to store it in. Signing the records it the same as signing any other record in the DNS. The hard part is convincing browser vendors to look in the DNS for the CERT record and to establish the chain of trust back to a DNS trust anchor.
To do this the browser needs secure path (by using TSIG, SIG(0) or TKEY) to a validating resolver it trusts and look at the AD bit in the response or it needs to use DNS trust anchors itself and do the necessary validation of the DNS trust chain.
All the bits of technology the browser vendors need are they to do this. It's just a matter of putting them together.
A web (not http) browser could be talking ftp, http, https, gopher and half a dozen other protocols. It assumes you mean http if you don't specify anything else and the name doesn't start with ftp in which case it assumes you want to talk ftp.
No they default to doing it. See browser.fixup.alternate.enable in Firefox which defaults to true. Set it to false and 3.se will just try 3.se and nothing else.
The search is also the default but can be turned off with keyword.enabled false.
Bell Canada's engineers should read draft-livingood-dns-redirect-00 which if nothing else explains how bad their implementation is.
While there isn't consensus on where to go with this draft. The is consensus that cookies don't work and that NXDOMAIN rewrites are different in nature to the other forms of redirect in draft-livingood-dns-redirect-00 and should be treated as a separate issue to the other forms of redirect.
I challenge any ISP that does this to point their SMTP servers to these name servers then decide that it is a "good thing" that provides a "enhanced service".
Why should the end user put up with crap that the ISP wouldn't put up with itself?
Actually it will get you off provided you identify the actual driver. There are even standard forms to fill out to provide this information which are sent with the infringement notice.
Validation is designed to be in the application. Most sites validate in the resolver as that is the easiest place to update and protect non-DNSSEC aware applications.
However, even if you run your own local DNS resolver, DNSSEC wouldn't come into play -- Comcast can simply strip the KEY/RRSIG records entirely before sending them to you -- leaving your resolver thinking that the zone has no DNSSEC records at all (at which point, they are blindly accepted as valid).
DNSSEC is designed to detect when DNSKEYs/RRSIGs are stripped from responses and will treat those as bogus presuming you have a appropriate trust anchor configured. For the record I'm a BIND developer and have many years of DNSSEC experience.
Slashdot Mirror
You still have to pay your contracted plan regardless of if you're using it or not, so whether the phone is unlocked is entirely irrelevant.
Except that people have started just giving bogus information and walking off with phones.
That may not be legally 'theft', but it is morally theft. (And not like 'pretend morally theft', like copyright violation. Someone actually took some physical thing of theirs.)
It's fraud, obtaining goods by deception, and is illegal independent of whether the phone is locked or not.
Anyone trying to make any form of unlocking illegal ever should jump off a bridge, and those who build their business models on locked phones without contracts are setting themselves up to get fucked when an unlock method is eventually discovered.
I agree completely.
It really depends on the client you are running and what type of answers it expects.
If the client is expecting answers with DNSSEC records (by setting DO in the query) then any modification of a answer like changing NXDOMAIN to a 1.2.3.4 can be detected if the client has a trust anchor that covers that zone (directly or indirectly though a parent zone).
If the client is not expecting answers with DNSSEC records then the recursive server can still ask for the DNSSEC records and validate the answers it receives but send on modified answers to the clients.
That being said it would just be a bad PR exercise to validate then do NXDOMAIN redirection.
This is also not to say that Comcast won't do some re-writting of responses in the future. If they decide to deploy NAT64 then they will need to also deploy DNS64 which work by re-writting answer to AAAA queries if there are no AAAA records but there are A records. How to do DNS64 with validating DNSSEC clients is still being worked out but will almost certainly require the client to do the DNS64 synthesis itself.
Once you have a secure DNS, you can then use if to provide secure linkage to other things. While still a while off yet. it is coming. SSH can already take advantage of this. Look at the "keyassure" work starting in the IETF. I'm pretty sure there will be a formal BoF in Beijing in a couple of weeks. There was a informal BoF at the last IETF in Maastricht.
COM isn't currently signed. Slated for next year if I remember properly.
Comcast almost certainly already supports NSEC3 in their validators as that is required to validate the root zone. Yes the root zone is using NSEC but the algorithm in use requires that the validator support NSEC3. All the DNS vendors that support DNSSEC validation ship products that validate responses from zones using NSEC3.
You can see if Comcast recursive servers are validating the root zone by running "dig +dnssec DNSKEY ." and looking for the "ad" flag.
As to whether Comcast decide to use NSEC or NSEC3 when signing their zones, well that is up to them. I'm sure Comcast can do their own risk analysis about their zones. I can tell you that it is a waste of time to use NSEC3 in a reverse zone as it is too highly structured.
Uh, you do realize that the Catholic Bishops were talking about legalizing child pornography and homosexual statutory rape(altar boys), rather than marijuana, right?
You do realise that child pornography is illegal and hence can't be classified R18+. There is lots of content that is and will be refused classification, be it print, video or games. R18+ is not a free for all. It is still limited.
You can still have version control and automatic re-signing. You just don't version control the master file that the name server uses. It's relatively
straight forward to make a tool that will take a unsigned master file and
generate a delta against the current signed zone contents and use that as the post commit action. The only thing that won't be consistent is the SOA serial.
I didn't see anyone paying for namespace in p2p networks or on I2P/FreeNet/etc., maybe we don't need to have parent domains?
While cryptographic hash will identify things they leave a lot in terms of usability. <whatever>@<short>.freenet does not scale.
And you do realize that domains like .biz, .info, .jobs, and all those new weird domain were only created because they knew every company wouldn't risk not registering their name everywhere they could and that would give them a huge revenue source? Centralized political corruption indeed...
I once said to Jon, over lunch, we should get rid of GTLD's. There are very few GLTD's that are useful. That said GTLDs != DNS.
I wasn't complaining. Parent was complaining.
Fair enough, though it wasn't clear.
Automatic zone signing only work on dynamic zones in 9.6 AFAIK. Might be different in 9.7.
How else to expect named to know it has change control on the zone? Remember all zones are dynamic. Just that there are different change mechanisms involved. Also just because it is dynamic that doesn't mean that anyone can change the contents. By using UPDATE named can update all the relevant records that are involved in a change. Yes, this is a change in how one does things but one that is for the better I believe.
The fact that you can't get a domain for 0$ implies that this is hierarchical and not free in any sense of the word which worries me and implies struggle about who controls the distribution... I'm no expert on BGB / DNS though.
Firstly, you can get domains for $0. I have one. I also have ones I pay for.
Secondly, there are real ongoing costs to be covered and the small costs associated with most parent domains are reasonable or do you expect to everyone to give you a free lunch?
Signing yourdomain.com requires you and .com to perform a transaction (registrar will perform on behalf of .com) that must recur at some interval for KSK and ZSK updates.
Really? Splitting keys into KSK and ZSK keys was done so that you DON'T need need to contact the parent zone administrator to roll the keys that sign the zone content. You do need to contact the parent when you update the KSK's but that should be much less often than the ZSK's are changed.
You do realise that you don't need to run dnssec-signzone anymore to sign a zone?
All vendors DNSSEC tools are improving. Perhaps you should do some research before complaining? Remember DNSSEC really is still in the very early stages of deployment and usability will continue to increase.
And I suspect that it puts Apple, Blackberry etc. in contravention of the Australian Spam Act 2003. Adding this make the email commercial advertising and it is being sent without the explicit consent of the recipient and has no unsubscribe method.
As a HE user you can just use their DNS servers for google.com and
you will get AAAA's returned.
zone "google.com" IN {
type forward;
forward first;
forwarders {
2001:470:20::2;
74.82.42.42;
};
This is a question you need to ask browser vendors. Putting a self-signed CERT in the DNS is relatively easy. There is even a specific record type, CERT, to store it in. Signing the records it the same as signing any other record in the DNS. The hard part is convincing browser vendors to look in the DNS for the CERT record and to establish the chain of trust back to a DNS trust anchor.
To do this the browser needs secure path (by using TSIG, SIG(0) or TKEY) to a validating resolver it trusts and look at the AD bit in the response or it needs to use DNS trust anchors itself and do the necessary validation of the DNS trust chain.
All the bits of technology the browser vendors need are they to do this. It's just a matter of putting them together.
A ftp client knows that it needs to talk ftp.
A web (not http) browser could be talking ftp, http, https, gopher and half a dozen other protocols. It assumes you mean http if you don't specify anything else and the name doesn't start with ftp in which case it assumes you want to talk ftp.
No they default to doing it. See browser.fixup.alternate.enable in Firefox which defaults to true. Set it to false and 3.se will just try 3.se and nothing else.
The search is also the default but can be turned off with keyword.enabled false.
How did you test?
Type a non www name into the browser's address bar which does automatic www prepending on NXDOMAIN?
Use dig or some other tool to query the DNS directly?
REFUSED is the correct answer for queries you refuse to answer. Re-writing to NXDOMAIN is as bad as re-writing from NXDOMAIN.
Bell Canada's engineers should read draft-livingood-dns-redirect-00 which if nothing else explains how bad their implementation is.
While there isn't consensus on where to go with this draft. The is consensus that cookies don't work and that NXDOMAIN rewrites are different in nature to the other forms of redirect in draft-livingood-dns-redirect-00 and should be treated as a separate issue to the other forms of redirect.
This is being discussed in the dnsop working group.
I challenge any ISP that does this to point their SMTP servers to these name servers then decide that it is a "good thing" that provides a "enhanced service".
Why should the end user put up with crap that the ISP wouldn't put up with itself?
Except underscore is not a legal character in a host name.
Hyphen however is.
Actually it will get you off provided you identify the actual driver. There are even standard forms to fill out to provide this information which are sent with the infringement notice.
DNSSEC is validated at the resolver level.
Validation is designed to be in the application. Most sites validate in the resolver as that is the easiest place to update and protect non-DNSSEC aware applications.
However, even if you run your own local DNS resolver, DNSSEC wouldn't come into play -- Comcast can simply strip the KEY/RRSIG records entirely before sending them to you -- leaving your resolver thinking that the zone has no DNSSEC records at all (at which point, they are blindly accepted as valid).
DNSSEC is designed to detect when DNSKEYs/RRSIGs are stripped from responses and will treat those as bogus presuming you have a appropriate trust anchor configured. For the record I'm a BIND developer and have many years of DNSSEC experience.
DNSSEC doesn't have to start at the top. It's just easier if you do so as
you reduce the number of trust anchors you need to manage.
For those of you waiting for the root to be signed, this will happen this year (2009).