Re: [DNSOP] I-D An Extension to DNS64 for Sender Policy Framework SPF Awareness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <2c626a82-de5c-364b-d5d4-2d321d56d...@posteo.de>, Klaus Frank writes >And to the 15 years argument. SPF hasn't been widely used the whole >time. It wasn't really necessary before 2016. the first statement is untrue, the second should say "It has never been necessary at all." - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBYgsE6d2nQQHFxEViEQLbCgCgizVWcrLdRQhI+ql2CSs35OI3KAAAnjiV IyVIEKfO873fEU4fCBS2q5Tx =hu57 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <20161229054559.31443.qm...@ary.lan>, John Levine writes >>I'm seeing how it really helps governments cheaply create and enforce >>the creation of national internets -- especially with the walled garden >>features. Are those the good guys to you, or are there other benefits? > >Please see the previous gazillion messages from people who are using >RPZ in production to keep malware away from their users. > >Also see the previous gazillion messages noting that governments do >all sorts of DNS censorship now and don't need RPZ. Much DNS censorship in the UK (regimes vary) is only implemented by the largest ISPs because only they have been able to find the necessary engineering time (when you operate at scale it's not just about setting a config option...) The UK Government (who pressurise the ISPs to block child sexual abuse images, some file sharing sites and who have grandiose plans to have a centralised list of malware URLs) tends to be happy because 5 ISPs covers about 95% of the population... Everyone involved understands that there isn't at present a turnkey application that the other 5% (and indeed all the in-house corporate systems) could deploy so this also makes the people who don't want the Government messing with their DNS results happy as well because anyone who rolls their own system pretty much opts out. >Could you explain in more detail why you don't believe operators will >continue to use RPZ to protect their users, and why you think hostile >actors will do things with RPZ that they couldn't do now? I can foresee Governments taking IETF standardisation of RPZ (that will be their words) as a way of pressurising those who have not yet deployed it to do so -- using lists supplied by them. So although deploying RPZ does a reasonable job of papering over the cracks in our response to cybercrime I think that on balance it's too dangerous a tool for the IETF to wish to bless in any way -- it's poor social hygiene to standardise these types of tools. I also note from reading the draft that this blessing will freeze in some rather ugly design (with the authors arguing that the installed base cannot adjust to something cleaner). If the IETF must do anything in this space then documenting an interchange standard for DNS related badness (with annotations to hint at how this badness might affect a resolver) would seem better engineering and rather less dangerous. - -- Dr Richard Clayton Director, Cambridge Cybercrime Centremobile: +44 (0)7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD tel: +44 (0)1223 763570 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBWGUE4zu8z1Kouez7EQJolQCePA1xB5kCbsbYHxWR5x/yBgRyT8kAn2EW JhXwn3xxerk+TDrhV3PftL/P =NInm -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Ted Lemon writes >NEW: > RFC 1912 recommended that "every internet-reachable host should >have a name" and says "Failure to have matching PTR and A records >can cause loss of Internet services similar to not being registered >in the DNS at all." Although the second of these two >recommendations is no longer considered to be a "best practice," >some network services still do perform a PTR lookip on the source >address of incoming connections and verify that the PTR and A >records match before providing service. "some network services still do" is rather vague (and thus unnecessarily encourages those of a conservative viewpoint to continue a practice that I still think is beyond its sell-by date). ... is it not possible to indicate that the only services ever believed to have acted upon this type of check are email and (in the last century) FTP ? Or is that an incorrect statement ? It is, I suppose, relatively common for logging systems to do a reverse lookup with a view to improving log readability. However, logging systems don't generally attempt to check that forward and reverse match, and so there is significant risk of being misled by the wicked. Asking the bad guy to tell you their name and not checking their answer is never the most solid of approaches. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBVySl6Tu8z1Kouez7EQIAHgCfV97gW5LN3DNQIUcj33v+n5o3uHoAoIun NfFxFBKaAMzZZ9L+f1OO5e9W =uUpi -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Philip Homburg writes >In your letter dated Fri, 29 Apr 2016 13:54:44 +0200 you wrote: > >>Having said all of that, I don't see any strong requirement that this >>document provide motivation for reverse DNS solutions for IPv6. People >>ask about the problem, and want solutions, and it would be good to have >>a document to point them to with some help. > >The problem I have with the current line of thinking (Section 2.4 in this >draft) is that there is a big disconnect between where reverse DNS is >needed and what ISPs are trying to do. "needed" is rather a strong word historically reverse DNS was a de facto requirement for access to some anonymous FTP servers (a use case that is now rather long in the tooth) and it was seized on by mail systems that were trying to deal with spam because a) checking for consistency between forward and reverse DNS and any associated HELO command gave them a (totally unjustified) warm feeling about the identity (and bona fides) of the machine sending them email b) some reckoned to parse the name (in an entirely ad hoc and error prone manner) and thereby identify mass-market ADSL/cable connected machines that they did not think should be sending email directly. I am not aware of ANY other protocols that have ever relied on the presence of reverse DNS -- but experts here may recall some ?? Latterly, the existence of reverse DNS has been used as a "clue test" for IPv6 email delivery (server to server, not email submission by end user machines) and this is documented in the M3AAWG document on IPv6 email: <https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6 _Policy_Issues-2014-09.pdf> which says In the absence of a more appropriate mechanism for identifying hosts intended to act as outbound MTAs by their owners, M3AAWG recommends rejecting email from host IPv6 addresses without reverse DNS records. This technique should be deprecated once a more suitable standard mechanism is developed. So in fact "reverse IPv6 DNS everywhere" risks being counterproductive for email (or at best we'll be back in the ad hoc parsing world). >Whether we like it or not, mail admins are adding reverse DNS checks. >In fact, some really big mail providers require reverse DNS. Yes, that's what M3AAWG is documenting... but if you roll out reverse DNS everywhere I confidently predict they will rapidly cease to bother ! >So, ISPs not doing reverse DNS for IPv6, like my current ISP, are making it >impossible to use your own mail server to deliver mail over IPv6. I think >they are doing a serious disservice to the open internet. Mayhap -- but reputation services for IPv6 are still in their infancy and so there needs to be some way to distinguish "legitimate" mail servers from malware infected end-user devices. In my view the effort should all be devoted to addressing reputation services for IPv6. In particular there is no standard for documenting the "cut point" (what the allocation unit was to a particular customer) and that is essential information for linking delivery events to an entity and thereby forming a view as to their legitimacy (or otherwise) If lots of work is to be done on reverse lookups in IPv6 (which I would argue is entirely self-defeating) then being able to do a reverse lookup which returns "/48" or "/56" or whatever is, in my view, significantly more useful. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBVyNUmTu8z1Kouez7EQL3QgCg+bONYXsKXzFP+8BGsyF1B7sezBgAnRgu zardRJpsJ6yicNFSijnV2EbB =25R6 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] PTR usage cases for networking Re: Using PTRs for security validation is stupid
;That to me indicates that people use log post processing all the time and >Intrusion Detection Systems are doing PTR lookups >by policy >For IDS are their expectations any different than log processors? >and if IDS’s are taking decisions based on the content of PTR records what >granularity do they need? If they're making significant decisions based on PTR records then they probably need to be ground down into granules :( - -- Dr Richard Clayton tel: 01223 763570, mobile: 07887 794090 Computer Laboratory, University of Cambridge, CB3 0FD -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBVGOmxuINNVchEYfiEQKcVACfeJYHzaRc+kB8lhGY495IqRL4c+UAoOuz aquwDeWYxf7pUYPIc8vA4M0E =IDG8 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <5453adcd.7090...@redbarn.org>, Paul Vixie writes >and yet, every proposal i've seen concerning IPv6 PTR screams silently, >"PTR is an old-internet concept which no longer applies." it's as if we >were trying to placate a bunch of apps that didn't understand classless >inter-domain routing (CIDR) with its variable length prefixes, and >rather than fix the apps, we're synthesizing acceptable metadata for >them, at great complexity cost, and zero information benefit. I entirely agree ... the fact that reverse DNS works as a heuristic (and not an especially key heuristic) for IPv4 is not a reason for the considerable effort required to try and make it work as a an equally flawed heuristic on IPv6. Beside the cost of creating the data and fetching it, there's the cost of caching it when people change the IP for every email sending attempt What recipients really wish to know when they receive a connection is how much address space is controlled by the connecting entity so that a consistent reputation can be applied to all connections from that space. Whether they construct that reputation themselves or acquire it from a broker is not relevant -- they want to apply it to all addresses that a sender controls. We approximate this in IPv4 by using /32s (since few people control more than a /24 -- so we get within a factor of 250 -- and there are not all that many /18s and above ... so we can manually inspect the traffic from each one on its merits, and yes there's a gap there). We just can't use the same approximations for IPv6, but the reverse DNS system is one place where we could store attestations about delegation of address space ... ... if we don't build such a system where this information can be stored for anyone to access for free then we're all going to end up paying another set of brokers for the data needed to provide the granularity measures our reputation systems must use - -- Dr Richard Clayton tel: 01223 763570, mobile: 07887 794090 Computer Laboratory, University of Cambridge, CB3 0FD -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBVFPLKuINNVchEYfiEQIjbgCbBQSyfmInlRaW8X497OyNAKytMGIAn1Js 63oOrwA48IfcFtAuTBpwupMV =awU9 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <4cf0289c.7080...@dougbarton.us>, Doug Barton
writes
>On 11/25/2010 09:52, Andrew Sullivan wrote:
>> It seems to me that those who don't like the document
>> aren't actually offering text that they'd like to see in the document.
>
>You may recall that my first post on the topic did actually offer a
>diff. My intention was to be minimalistic to avoid changing the text too
>much at this stage, but as I just posted I like the direction Tony is
>going much better.
as did I ... but I wish he'd carried on, because I'd like to see a
chatty explanation of what the explicit rules meant before suddenly
diving into the excruciating detail of { Ll, Lo, Lm, Mn } etc
ie: I would like to be able to read this RFC and understand in general
terms what it meant without ever bothering to look at 5890 (or it seems,
since that isn't the right place, at several other RFCs as well)
ie: the only people who'd need to follow the references would be those
who were proposing something challenging like .666, .3d or .4men (and
especially the cyrillic equivalents of these) and who wanted to know if
this was likely to lead to tears before bedtime.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1
iQA/AwUBTPArB5oAxkTY1oPiEQL98gCfS/qmOpFAe7ayxe+I1eFTTDRYLC0AnA5H
53MsjYbtMqTG9NLA6Ff7lGtP
=a44I
-END PGP SIGNATURE-
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <4ce1b830.5040...@necom830.hpcl.titech.ac.jp>, Masataka Ohta
writes
>I already gave an example of capital form of 'c' with cedille is
>often plain 'C' without cedille
That, as I understand it, is the convention in mainland France.
>and seldom 'C' with cedille,
That, as it has been explained to me by the natives, is the convention
in Canadian French.
> even
>though tools of ISO 8859/1 and Unicode support 'C' with cedille.
These conventions (which I first came across when building multilingual
word processors in the early 1980s) very much predate these standards...
... I've no doubt that you can find erudite people in both France and
Canada to discuss how formally specified these rules are. My
understanding of these rules comes solely from ensuring that the locals
didn't get overexcited when we shipped product :-)
What it means is that if you're writing a word processor and forcing
material into upper case you need to understand if your text is written
in "French" or "Canadian French". If you're not sure -- or your text is
labelled "British English" then you have to take an arbitrary view as to
what the right thing to do might be, which is probably to make yourself
look good in Paris... the people in Montreal will be annoyed, but will
understand your dilemma.
>It's a fact, not an assumption.
>
>Moreover, it is a fact that ISO 8859/1 includes 'y' with
>diaeresis but not 'Y' with diaeresis, which means people
>accept plain 'Y' without diaeresis as capital form of 'y'
>with diaeresis whenISO 8859/1 was defined.
As a practical matter, if you're trying to avoid most (not all) of the
gotchas in case insensitive coding, you don't upper case strings, but
you force anything which is in upper case to a lower case form :)
- -=-=-=-
Anyway... since we're meant to be discussing the document, I admit to
being entirely puzzled by this section:
A Restricted-A-Label is a DNS-Label which satisfies all the following
conditions:
1. the DNS-Label is a valid A-Label according to [RFC5890];
2. the derived property value of all code points, as defined by
[RFC5890], is PVALID;
3. the general category of all code points, is one of { Ll, Lo, Lm,
Mn }.
The reason I'm puzzled is that RFC5890 doesn't discuss what "property"
is and PVALID seems to be in a table in a different document (and so
doesn't appear in RFC5890 at all). ie: I think the reference to RFC5890
in #2 may be a typo.
I would also like to know where I'd go to look up what a category is ...
... I think what this is intending to say is that you can have a TLD of
".2go" but only if there's an xn-- at the front of the whole thing :)
- --
richard.clay...@cl.cam.ac.uk "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1
iQA/AwUBTOHXmpoAxkTY1oPiEQIpKwCdGtudUojdMUOEQN1IIjbSkuiP77YAoIeu
GNyjC9rxEyeM5/vtQwKFqCsU
=BTkU
-END PGP SIGNATURE-
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
