[dns-operations] Why allow-query-cache (for BIND) is important
allow-recursion is not enough: http://304geeks.blogspot.co.uk/2013/01/dns-scraping-for-corporate-av-detection.html ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] getting .CW recognised in the Google ccTLD tables/databases ...
Agree, but anyways checking suffixes is a bizarre and broken way of validating an email. Just because a suffix exists it doesn't mean that the domain exists, and if a domain doesn't exist because the TLD is wrong or the 2nd level, or the 3rd level labels are wrong, the net effect on the application is the same. Validating suffixes is less than worthless. Either validate the whole label chain or learn to deal with bounces. I registered the cagnazzo.name domain name some three years ago and decided not to renew it because my email c...@cagnazzo.name was almost unusable due be perceived as 'not valid' by many web applications. And .name has been out for several years. rant It's going to be fun watching what happens with the new round of gTLDs. I certainly hope that lousy web programmers start feeling the hot breath of pissed off people who have just spent a gazillion dollars on their new TLD just to have their shiny new .whatever emails be considered 'invalid' by some idiotic PHP form validation code. /rant cheers! ~C. On 1/20/13 11:07 PM, Rick Wesson wrote: +1 getting on the mozilla list effects lots of applications. -rick On Sun, Jan 20, 2013 at 4:55 PM, RijilV rij...@riji.lv wrote: My experience is many people use Mozilla's public suffix list for allowing folks to create resources on their app services. This is because a large number of TLDs don't support creating records directly off of them, and the 3rd parties don't want to accidentally grant ownership to a higher namespace to an individual. For example, .uk is a TLD, but you shouldn't let people regirester apps under that because someone could cleverly take co.uk and create sub apps within that that they didn't own. http://publicsuffix.org/list/ Incidentally, I don't see .cw in that list. It is open to submissions... http://publicsuffix.org/submit/ .r' On 20 January 2013 16:28, Joe Abley jab...@hopcount.ca wrote: On 2013-01-21, at 11:55, .CW Registry Curacao regis...@una.net wrote: I am not sure this is an issue that you can do anything about, however we have been advised by our colleagues from the ccNSO (ICANN) to send you this email message. We need some help with getting our ccTLD registered worldwide. Several Internet services sites cannot be used by our customers, because the .CW is not recognized. In our case it prevents us as university to make use of (for instance) Google Apps. There are google people on this list who (if they haven't already contacted you about it) will no doubt be happy to help you out with that specific problem, in their normal efficient way. More generally, there are many people who make assumptions about what a valid domain name is. A common example (I find) can be found in web forms which validate e-mail addresses. I can't even remember the number of times I was told that jab...@ca.afilias.info was invalid when I was working for Afilias, which always struck me as pleasantly ironic, especially when the web forms in question were provided by people trying to sell us stuff. There's no central registry for broken human expectations of how the DNS works. You pretty much need to just get used to complaining to the people who provide individual broken services when you find them. Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] validating TLD labels for fun and profit
On 21 Jan 2013, at 13:56, Carlos M. Martinez carlosm3...@gmail.com wrote: I certainly hope that lousy web programmers start feeling the hot breath of pissed off people who have just spent a gazillion dollars on their new TLD just to have their shiny new .whatever emails be considered 'invalid' by some idiotic PHP form validation code. Sadly, the lousy programmers and designers responsible for this idiocy will have moved on to bigger and better things long before .whatever's angry mob(s) come looking for them with pitchforks and flaming torches. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] getting .CW recognised in the Google ccTLD tables/databases ...
Hi, On Jan 21, 2013, at 1:07 AM, Jaap Akkerhuis j...@nlnetlabs.nl wrote: ISO-3166-1 table which shows valid ccTLDs in green: http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_table.htm Yellow (exceptionally reserved) code elements used for ccTLDs are also considered 'valid'. Just some of them. I was speaking from IANA/ICANN's perspective in the sense that for a 2-letter TLD to be delegated, the first condition that must be met is that the 2-letter ISO-3166 code point must be allocated by ISO-3166/MA. At this point in time, IANA/ICANN considers code points marked in green and in yellow in the decoding table as 'allocated'. This, of course, is not the only condition for a 2-letter TLD to be delegated out of a 2-letter ISO-3166 code point. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Monday rant againt the uses of the Public Suffix List
Stephane Bortzmeyer wrote: On Mon, Jan 21, 2013 at 03:45:36AM -0800, Jothan Frakes jot...@gmail.com wrote a message of 171 lines which said: ... used by numerous software developers, programming languages, browsers (cookies), search engines, security software, and many other places. And 95 % of these uses are bad ideas: it creates false positives (.CW...) and false negatives (it's not because .COM exists that anything.com has a meaning). passionate +1. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's a suffix?
On Jan 21, 2013, at 1:00 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Jan 21, 2013 at 09:25:03AM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 21 lines which said: A suffix is any string ending a domain name. A reader even more nazi than I am suggested a definition closer to the DNS semantics: A suffix is any sequence of labels ending a domain name. The term 'suffix' isn't really the issue -- it is the subset of 'suffixes' deemed 'public'. Quoting RFC 6265: NOTE: A public suffix is a domain that is controlled by a public registry, such as com, co.uk, and pvt.k12.wy.us. This step is essential for preventing attacker.com from disrupting the integrity of example.com by setting a cookie with a Domain attribute of com. Unfortunately, the set of public suffixes (also known as registry controlled domains) changes over time. If feasible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at http://publicsuffix.org/. I have to admit this definition has confused me for some time (e.g., what does public registry mean in this context?), but ignoring this, I find it odd that a registry as important to Internet operations as the public suffix list is not maintained by IANA. The fact that .CW was not automatically added to the list increases the oddness factor for me. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's a suffix?
On Jan 21, 2013, at 6:45 AM, Jothan Frakes jot...@gmail.com wrote: Hi- Perhaps my suggestion was better for off-list, and I certainly don't know if it would be the magic solution for .cw, but it certainly could not hurt them to submit their entry to the PSL. I do hope it contributes to the solution for them. The PSL is something that the application development community uses to enhance the IANA list for a variety of uses, typically for understanding what might be valid on the rightmost side of addresses. Yup, the PSL is used by a number of browser manufacturers to scope cookies... Many app developers don't closely watch the IANA root list, and want to know how to have a more elegant understanding and handling of the right hand side of addresses that are parsed, going deeper than just the TLD itself. Yes -- the IANA root list (unfortunately) simply doesn't contain the information needed to correctly determine where a cookie can be set. The PSL helps prevent a cookie being set at e.g: .co.uk. W I don't have an opinion on if it is right or wrong, but it has been around for some time, and a few years back I saw it was out of synch with the TLD community and have put a lot of volunteer time into trying to correct that. I am on temporary hiatus, but when not on exclusive projects, I volunteer time and experience to the initiative as it needs tighter nexus with the DNS community. Many of you have perhaps seen me presenting it at ICANN meetings within the CCNSO tech day or other forums to help elevate awareness in the past few years. The hope and purpose is to bridge the application development world so as to increase better sophistication for developers about TLDs and reduce legacy problems like simple TLD tests (ie 3 chars = invalid which broke forms or other functionality for info, museum, aero, mobi, travel etc. as they launched) . It is a central system managed by the community, kept up to date by volunteers, and used by numerous software developers, programming languages, browsers (cookies), search engines, security software, and many other places. Hopefully it helps .cw as they launch, which was my initial purpose in response. Definitely worth folks on this list being aware of it. Being able to positively impact how your zone operates within the application development community is a valuable resource. -J Jothan Frakes On Mon, Jan 21, 2013 at 1:00 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Jan 21, 2013 at 09:25:03AM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 21 lines which said: A suffix is any string ending a domain name. A reader even more nazi than I am suggested a definition closer to the DNS semantics: A suffix is any sequence of labels ending a domain name. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo. -- (Terry Pratchett, Wyrd Sisters) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] 10% was Re: .mm ....
On Jan 21, 2013, at 5:26 AM, Jaroslav Benkovský jaroslav.benkov...@nic.cz wrote: On 01/19/2013 09:28 PM, Matthäus Wander wrote: I think it's more like I'll tolerate an expired signature for 10% of the original validity period and use that extra time to let other people notice and fix it. Assuming that 1) the majority of validators do *not* tolerate expired signatures and 2) most DNSSEC failures are fixed within that 10%, it is a way to trade off reliability vs. security. That's rather reminiscent of parents who don't get their children vaccinated for fear of side-effects and instead rely on *other* children being vaccinated. Being tolerant to garbled input is what caused the sorry mess of HTML, with its quirk parsing modes and incompatibilities. Hmmm… So, the issue is folk not resigning before the expiration. Some resolvers are loose -- they stretch the expirations. Other, more strict implementations mark the domain as bad when it expires -- this causes fallout / press / messages on dns-ops, and the domain admin notices and resigns. This makes the loose implementations look better -- folk running the loose implementations avoided having thier customers get grumpy, saved the cost of support calls, etc. So, basically the loose implementations are relying on the strict implementations to signal the domain admin (out of band) to resign. This negatively affects the reputation of the strict implementations and, eventually, we may run into an issue where the loose implementations all increase the slop factor to look better than their competitors… So, basically what is needed is a strong, out of band signal to the operators to resign… It seems that the only reliable way to do this is for the domain to go dark for some (non-insignificant) portion of users -- this triggers Where the hell did my traffic go? questions from the web server operators, news articles and eventually the pointy-haired boss types waking down the stairs and shouting…. So, obviously what is needed is a way to trigger these sorts of responses, but without creating as much of an incentive for loose implementations and slop factors… So, here is my proposal: 1: Everyone does strict implementations. 2: When the signature expires everyone does the following: A: You calculate by how much the zone has expired, normalize it, then multiply by 255 and call this EXPIRED-AMNT. B: You take the primary IP of your recursive server, hash it, take the last octet of the hash and call it REF-HASH. C: You hash the label of the zone apex, take the last octet and call it ZA-HASH. Now, if REF-HASH - ZA-HASH EXPIRED-AMNT you can still answer the query. This means that initially only 1/255 resolvers will view the zone as bogus, but as time goes by (up to double the validity interval) more and more resolvers will mark it bad. This allows for increasingly strong signals to the operator, but doesn't favor any one implementation…. You're welcome… W (Mumbles something about job security, then runs off, giggling madly…) It's not cool to be one of the few resolvers suffering from DNSSEC configuration errors that other people caused, while all the non-validating resolvers seem to work fine. The security benefit is hardly noticed by users outside of the DNS community as long as applications are not showing green DNSSEC icons or other gizmos. I used to work for the first major ISP here that switched DNSSEC validation on, so I can only commiserate with you :). Jarda Benkovsky ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] getting .CW recognised in the Google ccTLD tables/databases ...
On Sun, 20 Jan 2013, RijilV wrote: My experience is many people use Mozilla's public suffix list for allowing folks to create resources on their app services. I was going to suggest that. However bear in mind that this isn't really a TLD list. What it is is a list of domains that Mozilla won't allow cookies to be set for. -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Monday rant againt the uses of the Public Suffix List
From: Warren Kumari war...@kumari.net Continuing the sarcasm is too much effort, so I'll simply ask why not do DNS MX and A requests? (both because of the fall-back-to-A-if-no-MX Please sir, if I run www.images.example.co.uk, can I set a cookie at images.example.co.uk? How about example.co.uk? Fine Now .co.uk? If you are running www.images.example.co.uk, then you should know all there is to know about cookies at www.images.example.co.uk any other domains at which you might legitimate want to set a cookie. If you are an HTTP client implementor, then I think you should implement disable third party cookies with the single obvious, fast, simple, and--if you like--simplistic comparision without needing to check any PSL lists. You should also make disable third party cookies on by default. Yes, I am among the many who consider third party cookies at best undesirable and generally willful and knowing attempts to sell or otherwise violate our privacy. Yes, I've occassionally encountered web pages that apparently legitimately use third party cookies (i.e. without obviously trying to violate my privacy). I cannot recall any cases where those web pages could not and should not have used other tactics. Yes, I know all HTTP server operators values my privacy. However, the values that spammers, advertisers, governments, and other snoops place on my privacy differ from mine. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Monday rant againt the uses of the Public Suffix List
On Mon, Jan 21, 2013 at 03:29:28PM -0500, Warren Kumari wrote: Please sir, if I run www.images.example.co.uk, can I set a cookie at images.example.co.uk? How about example.co.uk? Fine… Now .co.uk? Hmm… There is no DNS query that will (or should) tell me that... I strongly disagree, and have written a draft that would provide, among other things, what I believe to be such a mechanism (though some people on the W3C websec list seem to disagree, because they want assurances that are not currently provided by the public suffix list). The draft has heard some support from various reviewers, but I'm still not sure where next to go with it, so I haven't been flogging it. Review is welcome, however. http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02 Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Monday rant againt the uses of the Public Suffix List
On Jan 21, 2013, at 5:32 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Mon, Jan 21, 2013 at 03:29:28PM -0500, Warren Kumari wrote: Please sir, if I run www.images.example.co.uk, can I set a cookie at images.example.co.uk? How about example.co.uk? Fine… Now .co.uk? Hmm… There is no DNS query that will (or should) tell me that... I strongly disagree, and have written a draft that would provide, among other things, what I believe to be such a mechanism Oh…. Huh. Well, there's a thing… (Obviously) I haven't had a chance to actually read this properly yet, but from a quick skim it looks like a grand idea… I guess I'll modify my earlier to There is no DNS query that will (or should) currently tell me that, but maybe in the not too distant future there will be… Go read: blah :-) W (though some people on the W3C websec list seem to disagree, because they want assurances that are not currently provided by the public suffix list). The draft has heard some support from various reviewers, but I'm still not sure where next to go with it, so I haven't been flogging it. Review is welcome, however. http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02 Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Life is a concentration camp. You're stuck here and there's no way out and you can only rage impotently against your persecutors. -- Woody Allen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
