[DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

[Brian Dickson]

I think it is good to minimize disruption caused by broken DNSSEC domains,
for all the reasons listed in the document.

However, I also believe there is a second-order negative effect of
implementing NTAs as described.

Validating stub resolvers and validating forwarding resolvers, will still
break.

I do have a suggestion, which I hope is worth exploring and considering.

For anyone using an open, well-known resolver (either provided by their
ISP, or operated as a "public service"), include instructions on use of a
provider-specific DLV and provider-specific "alternative trust anchor
(DNSKEY)".

Whenever it is necessary to over-ride broken DNSSEC zones, most likely on
the Secure Entry Point, do the following:
(1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK
for all such instances, and publish the public DNSKEY used.
(2) Sign the apex DNSKEY RRset with this new KSK
(3) Add this KSK into the DLV operated by the resolver operator at the
appropriate location. For example, if example.com is broken, put the KSK at
example.com.dlv.example.net, if the operator of the public resolver is
example.net.
(4) Observe successful validation of example.com by anyone configured to
use dlv.example.net as their DLV.

I haven't tried this, and there might be some specific modifications to
what I described needed to make the configuration correct/functional. I
don't believe it introduces new insecurities to anyone who already has
placed trust in the resolver at example.net.
(Is it the case that things that use DLV validate the chain of trust to the
DLV itself, from the root, if there is not a separate trust anchor for the
DLV zone? That would be optimal, security-wise, I believe.)

Thoughts?

Brian Dickson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Mark Andrews]

As for protocol police, we need them.  Deploying anything new is
getting to be extremely difficult given the levels of non compliance
with existing RFC.  Protocols only work when both side are following
the protocol.

As Tim hasn't sent out a updated agenda I will draw your attention
to:

http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-04

http://users.isc.org/~marka/ts.html

http://users.isc.org/~marka/alexa-report.html
http://users.isc.org/~marka/au-report.html
http://users.isc.org/~marka/bottom-report.html
http://users.isc.org/~marka/gov-report.html
http://users.isc.org/~marka/tld-report.html

Which covers EDNS compliance which I will be discussing at HI.

Getting rid of broken software on authoritative servers is something
we can achieve.

Mark

In message 
, Warren 
Kumari writes:
> --===2813703441700708651==
> Content-Type: multipart/alternative; boundary=047d7ba9751882c1e50506bdb90a
> 
> --047d7ba9751882c1e50506bdb90a
> Content-Type: text/plain; charset=UTF-8
> 
> On Friday, October 31, 2014, Andrew Sullivan  wrote:
> 
> > On Fri, Oct 31, 2014 at 05:28:40PM +0100, Stephane Bortzmeyer wrote:
> > > something that is "against the rules laid out by the standard".
> >
> > "Nonconforming", then.
> 
> 
> Nonconformant or noncompliant ((as previously suggested) does not comply
> with the standard)
> 
> 
> 
> > I have to agree that "illegal" is wrong.
> > There are no DNS cops, despite what many people would like.
> >
> >
> Oh, I thought that was Mark... :-)
> 
> And I'd happily volunteer if we form a larger force - "he carries a badge,
> and a copy of Wireshark -- he's Warren, a member of the elite DNS branch of
> the Protocol Police. Sworn to uphold EDNS compliance and seek out broken
> delegations wherever they may be..."
> 
> W
> 
> 
> 
> 
> > A
> >
> > --
> > Andrew Sullivan
> > a...@anvilwalrusden.com 
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org 
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in
> the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
> 
> --047d7ba9751882c1e50506bdb90a
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> On Friday, October 31, 2014, Andrew Sullivan < a...@anvilwalrusden.com">a...@anvilwalrusden.com> wrote: e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
> id;padding-left:1ex">On Fri, Oct 31, 2014 at 05:28:40PM +0100, Stephane Bor=
> tzmeyer wrote:
> > something that is "against the rules laid out by the standard&quo=
> t;.
> 
> "Nonconforming", then.=C2=A0=C2=A0 =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
> ing-left:1ex">Nonconformant=C2=A0or noncom=
> pliant ((as previously suggested)=C2=A0does not comply with the standard)=
> =C2=A0=C2=A0 e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
> I have to agree that "illegal" is wrong.
> There are no DNS cops, despite what many people would like.
> Oh, I thought=C2=A0that was=C2=A0Mark.=
> .. :-)And I'd happily volunteer =
> if we form a larger force - "he carries a badge, and a copy of Wiresha=
> rk -- he's Warren, a member of the elite DNS branch of the Protocol Pol=
> ice. Sworn to uphold EDNS compliance and seek out broken delegations wherev=
> er they may be..."W >=C2=A0 in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> A
> 
> --
> Andrew Sullivan
>  lwalrusden.com')">a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
>  tf.org')">DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop"; target=3D"_blank">h=
> ttps://www.ietf.org/mailman/listinfo/dnsop
> -- I don't think the execution is relevant whe=
> n it was obviously a bad idea in the first place.This is like putting r=
> abid weasels in your pants, and later expressing regret at having chosen th=
> ose particular rabid weasels and that pair of pants.=C2=A0 =C2=A0---maf=
> 
> 
> --047d7ba9751882c1e50506bdb90a--
> 
> 
> --===2813703441700708651==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===2813703441700708651==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Mark Andrews]

In message <16VeoWCqs8UUFA$s...@highwayman.com>, Richard Clayton writes:
> -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

If you don't look it up it doesn't cost anything to cache.

Additionally a negative response is *bigger* and is more costly to
cache especially if it is a signed negative response.  If you are
worries about cache size you *want* PTR records to be returned.

> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Warren Kumari]

On Friday, October 31, 2014, Andrew Sullivan  wrote:

> On Fri, Oct 31, 2014 at 05:28:40PM +0100, Stephane Bortzmeyer wrote:
> > something that is "against the rules laid out by the standard".
>
> "Nonconforming", then.


Nonconformant or noncompliant ((as previously suggested) does not comply
with the standard)



> I have to agree that "illegal" is wrong.
> There are no DNS cops, despite what many people would like.
>
>
Oh, I thought that was Mark... :-)

And I'd happily volunteer if we form a larger force - "he carries a badge,
and a copy of Wireshark -- he's Warren, a member of the elite DNS branch of
the Protocol Police. Sworn to uphold EDNS compliance and seek out broken
delegations wherever they may be..."

W




> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com 
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Richard Clayton]

-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] comments on draft-ietf-dnsop-qname-minimisation

[Andrew Sullivan]

On Fri, Oct 31, 2014 at 05:28:40PM +0100, Stephane Bortzmeyer wrote:
> something that is "against the rules laid out by the standard".

"Nonconforming", then.  I have to agree that "illegal" is wrong.
There are no DNS cops, despite what many people would like.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Paul Vixie]

> Paul Wouters 
> Friday, October 31, 2014 9:29 AM
> On Fri, 31 Oct 2014, Paul Vixie wrote:
>
>> if you have a business grade connection to the internet, you should be
>> able to establish a PTR for each real host.
>
> Oh, you want me to pay an additional $2000/month to use IPv6 with email.

no, sir, and that's the second time you've attributed a desire to me
that i don't possess. (putting it in the form of a question makes it no
more palatable.)
>
>> in other words i didn't relegate your address to third party status.
>> that bed was on fire when you laid down on it.
>
> So much priviledge, wow, very Postel :P

people who want their mail to get through relay it through servers that
have PTR's. that's not news. you could:

1. pay $2000 (or whatever) for business-grade connectivity;
2. get a tunnel to sixxs or some other ipv6 tunnel broker;
3. buy a cheap virtual server in some cloud somewhere;
4. send me a 1U which i can host on my comcast business connection;
5. accept a free "bhyve" VM running freebsd on my personal "cloud".

note, #4 and #5 are only available to people i have drank beer with, so,
mr. wouters certainly qualifies.

if you want an option that's not on the menu, it's your job to define
it, and probably build it. if your preferred solution is that everyone
accepting e-mail stop looking for PTR's, then The Princess Bride has
this wisdom for you:

> Inigo Montoya: Who are you?
> Man in Black: No one of consequence.
> Inigo Montoya: I must know...
> Man in Black: Get used to disappointment.
> Inigo Montoya: 'kay. 

-- 
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Paul Wouters]

On Fri, 31 Oct 2014, Paul Vixie wrote:


if you have a business grade connection to the internet, you should be
able to establish a PTR for each real host.


Oh, you want me to pay an additional $2000/month to use IPv6 with email.


in other words i didn't relegate your address to third party status.
that bed was on fire when you laid down on it.


So much priviledge, wow, very Postel :P

John Levin wrote:


If your v6 setup isn't ready for prime time, it really isn't
anyone else's job to help you experiment


Attitudes like this at least guarantees we keep drinking scotch. But
universal deployment of ipv6, not so much.

In the fight between being forcibly NAT'ed behind IPv4, or having IPv6
without a reverse, it would be really nice to try and make everyone
a full peer on the internet again using IPv6 :P

I guess soon only criminals with have IPv6 reverse, since they have more
budget to spend on this than I do :P

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Stephane Bortzmeyer]

On Fri, Oct 31, 2014 at 12:17:31PM -0400,
 Edward Lewis  wrote 
 a message of 16 lines which said:

> I’d support non-standard.

Not me. I may be wrong in logic or in english but to me, "non
standard" means "there is no existing standard about this behaviour -
either pro or con - so I can do what I want". Here, we talk about
something that is "against the rules laid out by the standard".

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Dave Lawrence]

Stephane Bortzmeyer writes:
>  Paul Hoffman  wrote 
> > Nonstandard or noncompliant.
> 
> OK, we just have to fix RFC 6274, 6120, 5646, 5246 and dozens of other
> RFC which all use "illegal" like the draft.

No, we don't.  They are not normative, and do not proscribe the use of
language that is less potentially ambiguous.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Paul Hoffman]

On Oct 31, 2014, at 9:03 AM, Stephane Bortzmeyer  wrote:
> 
> On Fri, Oct 31, 2014 at 08:55:03AM -0700,
> Paul Hoffman  wrote 
> a message of 11 lines which said:
> 
>> Nonstandard or noncompliant.
> 
> OK, we just have to fix RFC 6274, 6120, 5646, 5246 and dozens of other
> RFC which all use "illegal" like the draft.

Or, you can just choose to use a better term than they did.

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Edward Lewis]

On Oct 31, 2014, at 12:03, Stephane Bortzmeyer  wrote:

> On Fri, Oct 31, 2014 at 08:55:03AM -0700,
> Paul Hoffman  wrote 
> a message of 11 lines which said:
> 
>> Nonstandard or noncompliant.
> 
> OK, we just have to fix RFC 6274, 6120, 5646, 5246 and dozens of other
> RFC which all use "illegal" like the draft.

I’d support non-standard.

(As far as the other RFCs: "If all the other kids are jumping from the bridge, 
would you too?")

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Stephane Bortzmeyer]

On Fri, Oct 31, 2014 at 08:55:03AM -0700,
 Paul Hoffman  wrote 
 a message of 11 lines which said:

> Nonstandard or noncompliant.

OK, we just have to fix RFC 6274, 6120, 5646, 5246 and dozens of other
RFC which all use "illegal" like the draft.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Paul Hoffman]

On Oct 31, 2014, at 4:30 AM, Stephane Bortzmeyer  wrote:
>> 4th paragraph: I'd suggest dropping the word "illegal"  It's a
>> loaded term and may not be true depending on the jurisdiction. 
> 
> Ed Lewis did a similar remark. The idea is to have one short word for
> "something which is a violation of the RFC". Any idea for a better
> word, less legally loaded?

Nonstandard or noncompliant.

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

[Warren Kumari]

On Fri, Oct 31, 2014 at 10:26 AM, Paul Ebersman  wrote:
>
> srose> Should there be text describing auto-adding of NTA's based on
> srose> important domains (for the ISP/resolver's definition of
> srose> important)?  So that domains that are used by low level services
> srose> don't fail that also aren't normally visible to end users?  One
> srose> example is nist.gov. When nist.gov messed up and went DNSSEC
> srose> BOGUS, time.nist.gov was unreachable by validating resolvers.
>
> warren> Sorry, but to me this sounds like a bad idea -- you should find
> warren> out that you "not normally visible to end users" failures are
> warren> happening because your network monitoring system goes "Beep Beep
> warren> Beep" when low level important services die.  The NOC then goes
> warren> off and investigates and discovers that e.g the NTP monitor it
> warren> sad because time.nist.gov is unresolvable.
>
> warren> At this point there really needs to be a *human* in the loop to
> warren> decide what to do, if the failure really *is* a DNSSEC failure
> warren> and, more importantly, if installing an NTA is the right answer.
>
> I'd hope it would be good operational sense for folks to have automated
> checks of critical things and checks of DNS logs for DNSSEC validation
> failures and that we shouldn't have to spell that out.
>
> But do we want to at least have a mention of doing such kinds of checks
> as a better way of noticing DNSSEC failures than pissed off customers or
> puzzled NOC folks?

Nope -- because now you have the problem of where to draw the line. Do
we also suggest the folk monitor error rates on WAN circuits? Failing
RAID arrays? Excessive BIND memory usage?

I think that would be document creep, creep!

>
> I do agree that we should not be inserting NTAs automatically for
> anything.

Yah.
W

>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Paul Vixie]

> Paul 
> Friday, October 31, 2014 6:50 AM
> Not sure why Paul Vixie wants to relegate my IPv6 address to third
> class citizen that's not good enough to be a peer on the Internet for
> port 25.

your question is a nonsequitur. i have no such desire.

> I'd ask him, but his mail server refuses my email due to my ISPs lack
> of reverse IPv6 :p

if you have a business grade connection to the internet, you should be
able to establish a PTR for each real host.

if you have a consumer grade connection, and your ISP is manufacturing
PTR's at large scale, then your ISP's pattern for such manufacture is
likely to be listed at  along with all the
other manufactured PTR patterns, and as such, my mailer would have
rejected your e-mail by the extra step of ignoring your manufactured PTR.

in other words i didn't relegate your address to third party status.
that bed was on fire when you laid down on it.
>
> I'm all for anti-spam heuristics, but checking the reverse is simply a
> method that's causing too many false positives, on top of punishing
> "early" adopters of IPv6

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.

-- 
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Paul Vixie]

> Bob Harold 
> Friday, October 31, 2014 6:02 AM
>
> ...
>
> I recall running into applications that refused to accept connections
> (or took a very long time) if the reverse DNS lookup was not found. 
> If memory serves, telnet and ssh on some hosts.  Do we know if there
> are still applications like that?   If so, then we (home users) need
> the reverse PTR.
i do not know one way or the other.

but if there are such apps, they are wrongheaded, and, the only way to
get them fixed is, stop placating them.

-- 
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Definition of terms in Re: Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Edward Lewis]

On Oct 31, 2014, at 7:20, Stephane Bortzmeyer  wrote:

> "Minimisation" did not came out of the blue. It is a very common term
> in privacy work and it is used in RFC 6973 (normative reference for
> draft-ietf-dnsop-qname-minimisation-00), section 6.1. Let's not
> reinvent terminology.

But it’s not a common term in DNS.  A few people have independently commented 
on it.

Perhaps you should set aside some text to define it and say that it comes from 
that RFC and the work behind it.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Edward Lewis]

Yes, but…

On Oct 31, 2014, at 10:20, Dave Lawrence  wrote:
> 
> On a barely related note, qname min helps with the logical progression
> of the DNSSEC chain when a signed subdomain of a signed domain is
> hosted on the same machine.  With longest match rules a full qname
> means the resolver has to infer that there's a missing link it needs
> to go back and ask about.

WIth long-lived keys (TTL wise) the recipient may already have a copy of the 
keys validating the signature that arrives.

(In the dark ages we included the KEY set in each answer before we realized 
that it was overkill to do so.  Yes, the “KEY” set - I said it was in the dark 
ages.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[John Levine]

>Not sure why Paul Vixie wants to relegate my IPv6 address to third class 
>citizen that's
>not good enough to be a peer on the Internet for port 25. I'd ask him, but his 
>mail server
>refuses my email due to my ISPs lack of reverse IPv6 :p
>
>I'm all for anti-spam heuristics, but checking the reverse is simply a method 
>that's
>causing too many false positives, on top of punishing "early" adopters of IPv6

I'd suggest that "mild inconvenience for you" is not a synonym for
"too many false positives."  I've been running IPv6 on my server for
quite a while via a tunnel from HE, which includes the ability to
manage my own reverse DNS.  (Thanks!)  When I look at the logs, I see
precious few inbound connections with no rDNS that plausibly could be
anything other than a spambot or yet another compromised web host.

Every mail system in the world is reachable via IPv4 and will be for a
long time.  If your v6 setup isn't ready for prime time, it really isn't
anyone else's job to help you experiment.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Edward Lewis]

To clear up a few points.

On Oct 31, 2014, at 7:08, Stephane Bortzmeyer  wrote:

> On Thu, Oct 30, 2014 at 03:29:21PM -0400,
> Edward Lewis  wrote 
> a message of 526 lines which said:
> 
>> This sounds like something related to work attempted in the DBound
>> mail list,
> 
> Doug Barton suggested here to use Dbound-like techniques to optimize
> the work of a qname-minimising resolver. I personally don't think this
> small improvment would be worth the added complication and risks of
> staleness.

I had in mind what Doug suggested.

> You say that not sending a SOA (when requested) is legal? 

A server may, at any time, return REFUSED.  If you want to argue based on the 
RFCs:

See RFC 1035, section 4.1.1. (Header section format), under RCODE, value 5

As far as not returning at all, that isn’t considered an option by the RFCs and 
protocol designers but is justified in my eyes under the reality of operations.

>>   292##Appendix A.  An algorithm to find the zone cut
>> 
>> It's not the zone cut that matters, it's what zones the server
>> answers that matters.
> 
> I disagree. When you want to resolve www.example.com with Qname m12n,
> knowing that example.com and com are on different sides of a zone cut
> is necessary. Knowing that the .com name servers also serve .net is
> useless.

In this case the point was not made well.  What I mean is for a name like this:

www.localschool.K-12.city.county.province.ccTLD. : one name server might serve 
these zones:

localschool.K-12.city.county.province.ccTLD.
K-12.city.county.province.ccTLD.
county.province.ccTLD.

It’s not the zones that matter, but the set of zones on the server because if 
you ask this server the full name you will get to the result much faster than 
targeting the NS records of the zones.

The DNS does not convey the zones on a server - it does report the servers a 
zone is to be found on (although we know that it might be inaccurate).

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

[Paul Ebersman]

srose> Should there be text describing auto-adding of NTA's based on
srose> important domains (for the ISP/resolver's definition of
srose> important)?  So that domains that are used by low level services
srose> don't fail that also aren't normally visible to end users?  One
srose> example is nist.gov. When nist.gov messed up and went DNSSEC
srose> BOGUS, time.nist.gov was unreachable by validating resolvers.

warren> Sorry, but to me this sounds like a bad idea -- you should find
warren> out that you "not normally visible to end users" failures are
warren> happening because your network monitoring system goes "Beep Beep
warren> Beep" when low level important services die.  The NOC then goes
warren> off and investigates and discovers that e.g the NTP monitor it
warren> sad because time.nist.gov is unresolvable.

warren> At this point there really needs to be a *human* in the loop to
warren> decide what to do, if the failure really *is* a DNSSEC failure
warren> and, more importantly, if installing an NTA is the right answer.

I'd hope it would be good operational sense for folks to have automated
checks of critical things and checks of DNS logs for DNSSEC validation
failures and that we shouldn't have to spell that out.

But do we want to at least have a mention of doing such kinds of checks
as a better way of noticing DNSSEC failures than pissed off customers or
puzzled NOC folks?

I do agree that we should not be inserting NTAs automatically for
anything.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Dave Lawrence]

Scott Rose:
> > 4th paragraph: I'd suggest dropping the word "illegal"  It's a
> > loaded term and may not be true depending on the jurisdiction. 

Stephane Bortzmeyer writes:
> Ed Lewis did a similar remark. The idea is to have one short word for
> "something which is a violation of the RFC". Any idea for a better
> word, less legally loaded?

Non-conformant.

> That being said, not doing minimisation for some qtypes seem to be
> an overoptimisation, not worth the complexity. Also, OPENPGPKEY is a
> bad example because it is a case where there is PII even after the
> second label so Qname m12n is *more* important for this type.

On a barely related note, qname min helps with the logical progression
of the DNSSEC chain when a signed subdomain of a signed domain is
hosted on the same machine.  With longest match rules a full qname
means the resolver has to infer that there's a missing link it needs
to go back and ask about.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: [sunset4] New Version Notification for draft-song-sunset4-ipv6only-dns-00.txt

[Marc Blanchet]

Hello,
 this draft has been posted to sunset4, but has some DNS operational 
perspective, which is why I’m forwarding to this mailing list. 

Marc (co-chair sunset4)

> Début du message réexpédié :
> 
> Date: 27 octobre 2014 22:00:52 UTC−4
> De: Davey Song 
> À: "suns...@ietf.org" 
> Objet: [sunset4] Fwd: New Version Notification for 
> draft-song-sunset4-ipv6only-dns-00.txt
> 
> Hi folks, I have just post a new draft on IPv6-only DNS development. Comments 
> are welcome!! 
> 
> A new version of I-D, draft-song-sunset4-ipv6only-dns-00.txt
> has been successfully submitted by Linjian Song and posted to the
> IETF repository.
> 
> Name:   draft-song-sunset4-ipv6only-dns
> Revision:   00
> Title:  Considerations on IPv6-only DNS Development
> Document date:  2014-10-27
> Group:  Individual Submission
> Pages:  8
> URL:
> http://www.ietf.org/internet-drafts/draft-song-sunset4-ipv6only-dns-00.txt 
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-song-sunset4-ipv6only-dns/ 
> 
> Htmlized:   http://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns-00 
> 
> 
> 
> Abstract:
>Deployment of IPv6-only networks are impacted by assumptions of
>IPv4-only or dual-stack transition scenarios.  For example, these
>assumptions are in the operations of DNS.  This memo is problem
>statement and hopes to eventually propose a mitigation technique.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org 
> .
> 
> The IETF Secretariat
> 
> 
> ___
> sunset4 mailing list
> suns...@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Paul]

Not sure why Paul Vixie wants to relegate my IPv6 address to third class 
citizen that's not good enough to be a peer on the Internet for port 25. I'd 
ask him, but his mail server refuses my email due to my ISPs lack of reverse 
IPv6 :p

I'm all for anti-spam heuristics, but checking the reverse is simply a method 
that's causing too many false positives, on top of punishing "early" adopters 
of IPv6

Sent from my iPhone

> On Oct 31, 2014, at 01:28, Paul Vixie  wrote:
> 
> 
> 
>> Doug Barton Thursday, October 30, 
>> 2014 9:00 PM
>> 
>> 
>> Of course not, but it is one that the ISP makes, and that distinction is 
>> useful to the anti-spam folks.
> IETF should not be making judgements as to what an ISP will value, because 
> not all ISP's behave as you described.
> 
> also, it's useless to the anti-spam folks. right now the massively faked and 
> manufactured PTR RR's coming from almost all last-mile providers for about 
> half of all the IPv4 address space that's reachable, has to be laboriously 
> cataloged so that it can be ignored.
> 
> that is, the lack of a PTR suggests that a device ought not be initiating 
> TCP/25 outside its local network. (this is an observation of how the 
> anti-spam folks, including myself, behave; it is not a recommendation.) 
> knowing this, last-mile providers foolishly and bizarrely create hundreds of 
> millions of PTR RR's that have no value whatsoever since they simply encode 
> the IP address in ASCII and add the ISP's ".foo.net" suffix. knowing this, 
> the anti-spam folks make lists of these manufactured patterns so that (and 
> ONLY so that) they can pretend they do not exist.
> 
> i suggest an efficiency improvement: don't manufacture these PTR's in the 
> first place. let last-mile devices be PTR-free. signal to anti-spam folks, 
> such as myself, by this method, that these are not real "hosts" and should 
> not be participating in what were once considered end-to-end protocols, such 
> as off-network SMTP.
> 
> internet service != internet access. can we make that taxonomy explicit, and 
> stop equivocating?
> 
> Oct 31 00:59:29 ss postfix/postscreen[3912]: NOQUEUE: reject: RCPT from 
> [59.55.248.215]:2294: 550 5.7.1 Service unavailable; client [59.55.248.215] 
> blocked using b.barracudacentral.org; from=, 
> to=, proto=ESMTP, helo=
> 
> 215.248.55.59.in-addr.arpa. 69668 INPTR 
> 215.248.55.59.broad.ja.jx.dynamic.163data.com.cn.
> ;; Received 106 bytes from 202.101.226.68#53(ns.jxjjptt.net.cn) in 162 ms
> 
> -- 
> Paul Vixie
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Andreas Gustafsson]

Bob Harold wrote:
> I recall running into applications that refused to accept connections (or
> took a very long time) if the reverse DNS lookup was not found.  If memory
> serves, telnet and ssh on some hosts.  Do we know if there are still
> applications like that?

Ubuntu has a long-standing bug that causes a 5-second delay in any
reverse lookup that yields NXDOMAIN:

  https://bugs.launchpad.net/ubuntu/+source/nss-mdns/+bug/94940

> If so, then we (home users) need the reverse PTR.

Personally, I would prefer to see Ubuntu, and any other software
broken in similar ways, fixed.
-- 
Andreas Gustafsson, g...@araneus.fi

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[Bob Harold]

On Fri, Oct 31, 2014 at 1:28 AM, Paul Vixie  wrote:

> ...
>
> i suggest an efficiency improvement: don't manufacture these PTR's in the
> first place. let last-mile devices be PTR-free. signal to anti-spam folks,
> such as myself, by this method, that these are not real "hosts" and should
> not be participating in what were once considered end-to-end protocols,
> such as off-network SMTP.
>
> ...
> --
> Paul Vixie
>
>
I recall running into applications that refused to accept connections (or
took a very long time) if the reverse DNS lookup was not found.  If memory
serves, telnet and ssh on some hosts.  Do we know if there are still
applications like that?   If so, then we (home users) need the reverse PTR.

-- 
Bob Harold
(Speaking personally, not for my employer)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-qname-minimisation

[Stephane Bortzmeyer]

On Thu, Oct 30, 2014 at 03:46:01PM +,
 Rose, Scott  wrote 
 a message of 27 lines which said:

> I am not a lawyer, but have had to deal with them on occasion.
> qname minimization may or may not reduce legal responsibilities.  

Right. IANAL too, so text changed for something milder ("it may
decrease their legal responsability" which is true in Europe).

> 4th paragraph: I'd suggest dropping the word "illegal"  It's a
> loaded term and may not be true depending on the jurisdiction. 

Ed Lewis did a similar remark. The idea is to have one short word for
"something which is a violation of the RFC". Any idea for a better
word, less legally loaded?

> Their is also a (small) performance hit for DANE aware applications
> where the owner name often has multiple labels.  Might want to
> mention it as well.  One way to reduce the time would be to not do
> minimization for certain qtypes (like TLSA, OPENPGPKEY, etc.). 

First, we should remember (it is not crystal-clear in the current
draft) that qname m12n is an unilateral change (it does not change the
protocol) so resolver implementers may do it in slightly different
ways. That being said, not doing minimisation for some qtypes seem to
be an overoptimisation, not worth the complexity. Also, OPENPGPKEY is
a bad example because it is a case where there is PII even after the
second label so Qname m12n is *more* important for this type.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Stephane Bortzmeyer]

On Thu, Oct 30, 2014 at 05:02:21PM -0400,
 Andrew Sullivan  wrote 
 a message of 21 lines which said:

> Ed's point is not wrong, however -- in one fairly natural meaning, the
> technique is actually "query maximization".  If one called it "query
> disclosure minimization" or something like that it'd be closer to
> describing what happens.

As I said to Paul Vixie, the Internet-Draft says "qname minimisation",
not "query minimisation".

(There is one - just one - unfortunate occurrence of "query
minimisation" in section 4, which will disappear in the next version.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Stephane Bortzmeyer]

On Thu, Oct 30, 2014 at 08:46:37PM +,
 Darcy Kevin (FCA)  wrote 
 a message of 19 lines which said:

> Isn't "doing the minimum necessary to get the job done" pretty much
> the definition of "optimization" (or, for that matter,
> "efficiency")? "Minimize" means, basically, only "to make small";
> whereas "optimization" or "efficiency" means to reduce something,
> relative to something else, for a particular purpose or to achieve a
> particular end.

"Minimisation" did not came out of the blue. It is a very common term
in privacy work and it is used in RFC 6973 (normative reference for
draft-ietf-dnsop-qname-minimisation-00), section 6.1. Let's not
reinvent terminology.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Stephane Bortzmeyer]

On Thu, Oct 30, 2014 at 01:35:28PM -0700,
 Paul Vixie  wrote 
 a message of 7 lines which said:

> the term "query minimization" appeals to me since each server,
> during iteration, sees the minimum substring of the qname needed.

That's why it is "qname minimisation", not "query minimisation" :-)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Stephane Bortzmeyer]

On Thu, Oct 30, 2014 at 07:42:02PM +,
 Darcy Kevin (FCA)  wrote 
 a message of 1087 lines which said:

> I too have been tempted to comment on the fact that there is no
> QNAME that is being "minimized" here (which would imply making it
> shorter; not the gist of the proposal at all).

I really do not understand you. With Qname minimisation, the Qname
*will* be shorter.

> If we're stuck on the term "minimization", make it clear that it's
> not the QNAME itself that's being "minimized",

-1

> but the actual number of query transactions being minimized.

-1

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt

[Stephane Bortzmeyer]

On Thu, Oct 30, 2014 at 03:29:21PM -0400,
 Edward Lewis  wrote 
 a message of 526 lines which said:

> Should be DNSOP WG

Boilerplate from XML2RFC. I have to read the documentation.

> Because, as described this proposal would increase the number of
> queries sent in search of a name.

It's minimisation of the data sent. And, in most cases, there would be
no increase of the query numbers.

> I don't know that the amount of "privacy problems" is something
> DNSOP is suited to address.

There have been a lot of hesitation after Vancouver on where to put
this work (DNSOP, Perpass, a new WG). In the end, it is DNSOP (there
have been a call for adoption by dnsop, with only one opposition
expressed) so, in my opinion, the case is closed (I'm not really
interested in IETF's internal endless process debates).

> This sounds like something related to work attempted in the DBound
> mail list,

Not at all. Dbound (or Mozilla's public suffix list) rely on a priori
knowledge (which can be stale) while Qname m12n relies on dynamically
learning. But, more important, Dbound is for finding out the
_administrative_ boundaries while Qname m12n depend on _technical_
boundaries. For Dbound, the fact that www.ratp.fr is below a zone cut
and not in the same zone than ratp.fr is irrelevant (it's the same
organisation). For Qname m12n, it is crucial.

Doug Barton suggested here to use Dbound-like techniques to optimize
the work of a qname-minimising resolver. I personally don't think this
small improvment would be worth the added complication and risks of
staleness.

> Effectively, yes, not a requirement, but more than a tradition.

May be it's my low level in english but, for me, "tradition" did not
mean that it was irrational or without basis. You say that there were
very good practical reasons for sending the full Qname and I agree. If
we continue to do so while these reasons are no longer there (root
name servers don't serve .com anymore...), it is tradition.

> The SOA is "just a convention" too (in negative answers) and if the
> zone does not make use of NOTIFY/AXFR/IXFR, the SOA serial number
> doesn't matter either.

You say that not sending a SOA (when requested) is legal? 

> (Once again - illegal practice?)

Do you prefer a term less legalese? "Violation of the RFC"?

>292##Appendix A.  An algorithm to find the zone cut
> 
> It's not the zone cut that matters, it's what zones the server
> answers that matters.

I disagree. When you want to resolve www.example.com with Qname m12n,
knowing that example.com and com are on different sides of a zone cut
is necessary. Knowing that the .com name servers also serve .net is
useless.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop