Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

Because without such a signal, humans using ANY for legitimate diagnostic
purposes have no means of differentiating section 4.1/4.3 "subset"
responses from conventional responses where there just happen to be only a
small number of RRSets at the queried name, encouraging (or at least doing
nothing to dissuade) a conclusion that the response is in fact conventional
and complete.

On Fri, Feb 10, 2017 at 1:44 PM, Ólafur Guðmundsson 
wrote:

> Thank you for your comments
>
> Q: why do you think it is useful to complicate things with a EDNS0 flag ?
>
> Olafur
>
>
>
> On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson  wrote:
>
>> With full realization that this is coming very late in the game, we had a
>> great deal of internal conversation within Dyn about implementing
>> refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
>> approaches—the latter because of reasons that have already been covered,
>> and the former for lacking in-band signaling of non-"conventional"
>> incompleteness to aid legitimate use.
>>
>> I believe there is sufficient cause to reserve a new OPT record EDNS
>> header flag bit
>> 
>> for indicating "partial response" (as distinct from "truncation"). It will
>> be safely ignored by current clients, but convey the desired information to
>> those in the know.
>>
>> P.S. Our discussion also raised some more minor points:
>>
>>- Insisting that the HINFO OS field SHOULD be empty ("set to the null
>>string") seems a little too strong; there's room in it for (and value
>>from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please
>>stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer
>>text like "The OS field of the HINFO RDATA SHOULD be short to
>>minimize the size of the response, and MAY be empty or MAY include a
>>summarized description of local policy."
>>- "Conventional [ANY] response" is used but not defined.
>>- "ANY does not mean ALL" is misleading—RFC 1035
>> is clear about
>>QTYPE=255 being "a request for *all* records" (emphasis mine). That
>>said, the proposed *response* behavior is consistent with that RFC.
>>
>>
>> On Thu, Feb 9, 2017 at 12:56 AM,  wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Domain Name System Operations of the
>>> IETF.
>>>
>>> Title   : Providing Minimal-Sized Responses to DNS
>>> Queries that have QTYPE=ANY
>>> Authors : Joe Abley
>>>   Olafur Gudmundsson
>>>   Marek Majkowski
>>> Filename: draft-ietf-dnsop-refuse-any-04.txt
>>> Pages   : 10
>>> Date: 2017-02-08
>>>
>>> Abstract:
>>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>>The operator of an authoritative DNS server might choose not to
>>>respond to such queries for reasons of local policy, motivated by
>>>security, performance or other reasons.
>>>
>>>The DNS specification does not include specific guidance for the
>>>behaviour of DNS servers or clients in this situation.  This document
>>>aims to provide such guidance.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>>>
>>>
>>> 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.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> ___
>>> 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
>>
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Ólafur Guðmundsson]

Thank you for your comments

Q: why do you think it is useful to complicate things with a EDNS0 flag ?

Olafur



On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson  wrote:

> With full realization that this is coming very late in the game, we had a
> great deal of internal conversation within Dyn about implementing
> refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
> approaches—the latter because of reasons that have already been covered,
> and the former for lacking in-band signaling of non-"conventional"
> incompleteness to aid legitimate use.
>
> I believe there is sufficient cause to reserve a new OPT record EDNS
> header flag bit
> 
> for indicating "partial response" (as distinct from "truncation"). It will
> be safely ignored by current clients, but convey the desired information to
> those in the know.
>
> P.S. Our discussion also raised some more minor points:
>
>- Insisting that the HINFO OS field SHOULD be empty ("set to the null
>string") seems a little too strong; there's room in it for (and value
>from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please
>stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer
>text like "The OS field of the HINFO RDATA SHOULD be short to minimize
>the size of the response, and MAY be empty or MAY include a summarized
>description of local policy."
>- "Conventional [ANY] response" is used but not defined.
>- "ANY does not mean ALL" is misleading—RFC 1035
> is clear about
>QTYPE=255 being "a request for *all* records" (emphasis mine). That
>said, the proposed *response* behavior is consistent with that RFC.
>
>
> On Thu, Feb 9, 2017 at 12:56 AM,  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations of the
>> IETF.
>>
>> Title   : Providing Minimal-Sized Responses to DNS
>> Queries that have QTYPE=ANY
>> Authors : Joe Abley
>>   Olafur Gudmundsson
>>   Marek Majkowski
>> Filename: draft-ietf-dnsop-refuse-any-04.txt
>> Pages   : 10
>> Date: 2017-02-08
>>
>> Abstract:
>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>The operator of an authoritative DNS server might choose not to
>>respond to such queries for reasons of local policy, motivated by
>>security, performance or other reasons.
>>
>>The DNS specification does not include specific guidance for the
>>behaviour of DNS servers or clients in this situation.  This document
>>aims to provide such guidance.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>>
>>
>> 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.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> 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
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] solving a problem by creating a worse problem, ALT-TLD and (insecure) delgations.

[Suzanne Woolf]

Hi,

The editors hold the token on text for this, but it seems to me that the 
discussion has started going in circles.

A number of arguments have been made, and in some cases repeated. Let’s assume 
the editors have heard them and try to restrict followups to new observations, 
questions, or arguments.

> On Feb 10, 2017, at 1:25 PM, John Levine  wrote:
> 
>> This is part of why I don't want to extend alt this way, and the more
>> I think about it the less desirable it seems to me.  We have a
>> particular problem: non-DNS-protocol switching for applications that
>> want to use a DNS-compatible domain name slot (see RFC 5890).
> 
> Agreed.  Say that you can do anything you want with .ALT (duh) but you
> SHOULD NOT resolve .ALT names via the DNS protocol because of the
> DNSSEC problems.  To minimize leakage, we can use the tools we already
> have: qname minimization, local mirrors of the root, and special
> casing in DNS caches as many now do for .onion.

This sounds reasonable to me.


Suzanne

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

Re: [DNSOP] solving a problem by creating a worse problem, ALT-TLD and (insecure) delgations.

[John Levine]

>> What I envision for the future is an insecure delegation of .alt, and an
>> option in future cable modems to enable a local "homenet.alt" domain, which
>> would just work, even if some stub resolvers in the house are validating.
>> The cable modem is already a recursive resolver or forwarder, and dhcp
>> server, so it seems a logical place for the local domain.
>
>No, it won't just work if a stub is validating, because the validating
>stub will want to validate the delegation from the parent, and that
>will be a proof of non-existence. ...

Yeah.  It seems to me that if we want DNSSEC to work for locally
served DNS subtrees, we need some way to distribute trust anchors for
the subtrees to those cable modems.  While that is probably not an
insoluble problem, it is not one that I would plan to solve any time
soon, so it's one I would prefer to address separately.

>This is part of why I don't want to extend alt this way, and the more
>I think about it the less desirable it seems to me.  We have a
>particular problem: non-DNS-protocol switching for applications that
>want to use a DNS-compatible domain name slot (see RFC 5890).

Agreed.  Say that you can do anything you want with .ALT (duh) but you
SHOULD NOT resolve .ALT names via the DNS protocol because of the
DNSSEC problems.  To minimize leakage, we can use the tools we already
have: qname minimization, local mirrors of the root, and special
casing in DNS caches as many now do for .onion.

R's,
John

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Andrew Sullivan]

On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote:
> What I envision for the future is an insecure delegation of .alt, and an
> option in future cable modems to enable a local "homenet.alt" domain, which
> would just work, even if some stub resolvers in the house are validating.
> The cable modem is already a recursive resolver or forwarder, and dhcp
> server, so it seems a logical place for the local domain.

No, it won't just work if a stub is validating, because the validating
stub will want to validate the delegation from the parent, and that
will be a proof of non-existence.  Provable non-existence prevents you
from being poisoned through typosquatting, but it means you can't
inject things in the tree without co-operation from the parent.

This is part of why I don't want to extend alt this way, and the more
I think about it the less desirable it seems to me.  We have a
particular problem: non-DNS-protocol switching for applications that
want to use a DNS-compatible domain name slot (see RFC 5890).  This is
problems like onion, local, and so on.  We propose a solution in which
we steal four of the available 255 octets to create a "safe" space
from DNS delegation.  Now anyone can use that space for their non-DNS
protocol, and every resolver library in the world knows that if it
runs into a name in the alt tree it shouldn't need to look it up in
DNS.  If the query leaks to the root and gets a proof of
non-existence, it doesn't matter because it was supposed to be a
different protocol.  Non-existence in the DNS is analytically true.
If a validating resolver gets an answer back from another resolver
that provides NXDOMAIN without the proof of non-existence and treats
the result as bogus instead, who cares?  It was never supposed to
resolve in the DNS anyway.

The homenet case is different, because it _is_ supposed to work with
DNS.  In that case, the missing proofs are a problem for validating
end points.

Best regards,

A

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

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Andrew Sullivan]

On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote:

> So, while technically the instruction (SHOULD NOT) applies to full .onion
> names,
> it is a SHOULD NOT, not a MUST NOT.

Note also that the original request was that it be a MUST NOT, and
some of us tried to explain that RFCs do not actually determine what
people may do and it's the Internet, and so you couldn't make a
requirement in one RFC that would be guaranteed to be implemented by
those who don't implement that RFC.  Which means that the restricton
is a stupid one.  The result was a compromise in which it says "SHOULD
NOT".  In this case, the pretty good reason not to implement the
restriction is that the Internet doesn't work the way the people who
wanted onion to work thought it did.

Any name under alt -- which is, rememeber, _supposed_ to be the
protocol switch in the way Warren and I originally were thinking --
should never get looked up in the global DNS.  If it does, that's
because someone is trying to use a name that contains right in itself
an indication that it needs an alternative resolution context, and not
having that resolution context available.  It might be that such a
computer will erroneously fall back on the global DNS.  That's not a
reason for us to do contortions in the specification.

Best regards,

A

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

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

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt

[Peter van Dijk]

Hello Ray,

On 10 Feb 2017, at 14:12, Ray Bellis wrote:


On 10/02/2017 12:52, Peter van Dijk wrote:


Can you please consider adding a port number field?


I see where you're coming from, but I'm not inclined to add it (yet) 
for

a couple of reasons:

1.  CGNAT is evil ;-)


You have my full agreement on that! However, it is also a reality that 
we have to deal with today.



2.  If I add this, then folks will want other transport related fields
   (indeed I already had at least one other person suggest this).


I suggest weighing every such request individually - saying yes to ports 
is no reason to say yes to something else :)


Are the server side ACLs etc that need to be able to identify the 
client
so fine grained that they'd really give different treatment to 
different

clients arriving from the same CGN IP address?


Sadly, yes. In ISP networks, there may be policy differences per 
subscriber, and given CGNAT the DNS server can only identify the 
subscribers by their IP+port.


This is probably something that the WG should consider if (or 
hopefully

when) this becomes a WG item.


I encourage WG adoption in any case!

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt

[Ray Bellis]

On 10/02/2017 12:52, Peter van Dijk wrote:

> However, both in ECS, and now in XPF, we do not get client’s port
> number. With increasing CGNAT deployment, this makes it impossible to
> distinguish clients once a request has passed through a proxy, like
> dnsdist or a TLS frontend.
> 
> Can you please consider adding a port number field?

I see where you're coming from, but I'm not inclined to add it (yet) for
a couple of reasons:

1.  CGNAT is evil ;-)

2.  If I add this, then folks will want other transport related fields
   (indeed I already had at least one other person suggest this).

Are the server side ACLs etc that need to be able to identify the client
so fine grained that they'd really give different treatment to different
clients arriving from the same CGN IP address?

This is probably something that the WG should consider if (or hopefully
when) this becomes a WG item.

kind regards,

Ray

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

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt

[Peter van Dijk]

Hello Ray,

On 6 Jan 2017, at 23:02, Ray Bellis wrote:


On 06/01/2017 18:43, Wessels, Duane wrote:


The idea of "X-Forwarded-For" for DNS makes me nervous, but it is
probably inevitable.

It is of course quite similar to EDNS client subnet, except that
there is no masking and the client cannot opt-out.  Might be worth
saying in your document why EDNS client subnet wouldn't work for this
purpose.


I believe that dnsdist / PowerDNS is already (ab)using the ECS option
for this purpose.

The intent in part is to provide a separate option so that "real" ECS
can pass unhindered.  [ not that I think ECS is a good idea, but some
folks want it, c'est la vie ]


Indeed, dnsdist uses ECS to pass the actual client IP to the real 
backend DNS server. And indeed, this gets confusing when there is also 
‘real’ ECS. So thank you for writing this draft, it will be very 
useful!


However, both in ECS, and now in XPF, we do not get client’s port 
number. With increasing CGNAT deployment, this makes it impossible to 
distinguish clients once a request has passed through a proxy, like 
dnsdist or a TLS frontend.


Can you please consider adding a port number field?

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Stephane Bortzmeyer]

On Fri, Feb 10, 2017 at 12:57:25PM +1100,
 Mark Andrews  wrote 
 a message of 29 lines which said:

> Even with everything working properly QNAME minimisation DOES NOT
> STOP THE QUERIES.
> 
> RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC 
> 4035)

RFC 4035 (if more security needed, but it is not *necessary*) + RFC
7816 + RFC 8020 -> no leaks

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Stephane Bortzmeyer]

On Thu, Feb 09, 2017 at 04:40:23PM -0800,
 Brian Dickson  wrote 
 a message of 78 lines which said:

> If you really care about privacy, IMHO, the place to instantiate the
> private namespace, is under one of the heavily used AS112 zones.
[...]
> even if a leak
> occurs, it will be hiding among the sheer volume of crap.
> Plus, having the AS112 decentralization applied, means any incidental
> leakage is going to be nearly impossible to find.

This was proposed in draft-bortzmeyer-dname-root. But read its
Security considerations section: not everyone agrees that leaking to
AS112 is harmless.

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Stephane Bortzmeyer]

On Fri, Feb 10, 2017 at 11:48:01AM +1100,
 Mark Andrews  wrote 
 a message of 36 lines which said:

> No, it will ask for foo.alt because:

This is false (and Ted Lemon was correct in describing QNAME
minimisation). Here, with a recent Unbound, when I ping foo.alt, I see only:

09:05:55.233366 IP6 2001:4b98:dc2:43:216:3eff:fea9:41a.64146 > 
2a01:4f8:161:6106:1::10.53: 36407% [1au] A? alt. (32)

If, afterwards, I ping bar.alt, there is no outgoing DNS request (this
is because of "NXDOMAIN cut").

> QNAME minimisation prevents the root learning about foo.com because
> there is a delegation for com in the root zone.  This does not apply
> for foo.alt.

This does not seem true.

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Stephane Bortzmeyer]

On Fri, Feb 10, 2017 at 09:48:51AM +1100,
 Mark Andrews  wrote 
 a message of 43 lines which said:

> and has agressive negative caching (so the answer from the minimised
> QNAME query get turned into a answer for *.alt).

As I already said here, if by "agressive negative caching", you mean
draft-ietf-dnsop-nsec-aggressiveuse, then the above sentence is
*false*. RFC 8020 is enough to "turn the answer from the minimised
QNAME query to a answer for *.alt".

[And I would really like to see BIND implement it.]

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Stephane Bortzmeyer]

On Fri, Feb 10, 2017 at 06:57:22AM +1100,
 Mark Andrews  wrote 
 a message of 40 lines which said:

> Only if you are willing to break lookups for names where there are
> missing delegations in parent zone and the parent and child zones
> share the same nameservers or the nameserver just misimplements ENT
> or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist
> with RFC 2535).  All of these result in NXDOMAIN for ENT.

Funny, I did not expect *you* to claim we have to accomodate broken
name servers :-)

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