Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[Peter van Dijk]

Hello Suzanne,

On 6 Apr 2018, at 23:49, Suzanne Woolf wrote:

We’re hearing that having an RFC will be helpful to promoting 
implementation, and also that this draft may not be ready to be 
advanced for publication because it doesn’t include implementation 
experience. This is something the WG needs to comment on further, 
because it seems substantive to me so it will have to be addressed one 
way or another before we advance the document— but those inputs are 
somewhat in disagreement.


In WG context, not in draft context: I do not think these inputs are in 
disagreement. If a draft can find -zero- implementers that think the 
draft is a sufficiently good idea that they write an implementation 
during draft status, the draft is, most likely, a bad idea.


Editors: Please take “concern about a description of current 
implementation status” as WGLC input, and consider what you might be 
able to add to the draft to address it.


WG vendors/implementers: Can folks who have implemented 
kskroll-sentinel, or considered implementing it, please speak up on 
your concerns/plans?


Because of privacy concerns (currently raised in section 7 of the draft 
quite briefly), PowerDNS will not be implementing this protocol.


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

[DNSOP] tdns, 'hello-dns' progress, feedback requested

[bert hubert]

Hi everyone,

[tl;dr - is it ok not to chase CNAMEs out of zones and only to do in-zone
glue? how many CNAMEs should one follow? Plus some fun things]

Under the watchful eye of the lovely camel Farsight sent us [1], I've been
working on enhancing the 'hello-dns' pages on http://powerdns.org/hello-dns

Specifically, I thought it was a good a idea to make a "minimal but correct
and best practices" authoritative nameserver. It is called 'tdns', for
'teaching nameserver'.

This is described at https://powerdns.org/hello-dns/tdns/README.md.html - I
was hoping for a 500 line result, but it appears 1100-1200 or so is where
you end up without compression, but with EDNS.

The blurb: "Even though the 'hello-dns' documents describe how basic DNS
works, and how an authoritative server should function, nothing quite says
how to do things like actual running code.  tdns is small enough to read in
one sitting and shows how DNS packets are parsed and generated.  tdns is
currently written in C++ 2014, and is MIT licensed.  Reimplementations in
other languages are highly welcome, as these may be more accessible to other
programmers."

In writing this server and while consulting with some other implementors, I
for now have decided that in 2018 it makes no sense to:

1) chase CNAMEs that point to another zone
2) look for glue outside of the zone

Given that any resolver will ignore those answers anyhow. But I wonder, is
this ok, and do we already have words on if chasing CNAMEs outside of zones
is mandatory or not?

Some other fun thoughts:

1) It appears everyone has decided 10 CNAME indirections is 'enough' - is
that number somewhere (it was in Jeeves already!)

2) Try: 
  ping goes-via-embedded-nul.tdns.powerdns.org
  ping goes-via-embedded-space.tdns.powerdns.org.
  ping goes-via-embedded-dot.tdns.powerdns.org.

  None of these resolve when I try them, I wonder if that is because
  implementations want CNAMEs to be 'host names', or if this a chain of
  bugs.  Not practically very relevant, but still.

Your thoughts would be most welcome.

Bert

[1] - so cute https://twitter.com/PowerDNS_Bert/status/983659389935603712

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Paul Hoffman]

On 13 Apr 2018, at 7:47, bert hubert wrote:

Specifically, I thought it was a good a idea to make a "minimal but 
correct

and best practices" authoritative nameserver.


Thank you, thank you.

In writing this server and while consulting with some other 
implementors, I

for now have decided that in 2018 it makes no sense to:

1) chase CNAMEs that point to another zone
2) look for glue outside of the zone


1) What was the historical text that indicated that an authoritative 
server should chase CNAMEs before responding? This worries me.


2) What does "look for" mean here? Can you give an example of what you 
are no longer doing in this authoritative?


[1] - so cute 
https://twitter.com/PowerDNS_Bert/status/983659389935603712


Is this a suggestive plea for more camels to be sent to you? If so, you 
should include your favored postal address so some of us can help your 
collection grow. :-)


--Paul Hoffman

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Paul Vixie]

the authority server should never fetch anything, and therefore, should 
not return out-of-zone data. if that means a cname chain ends without a 
result, that's the resolver's problem. if that means a delegated zone's 
name servers are only available in a sibling or uncle zone, that's the 
delegated zone's problem.


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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[bert hubert]

On Fri, Apr 13, 2018 at 07:59:19AM -0700, Paul Hoffman wrote:
> >Specifically, I thought it was a good a idea to make a "minimal but
> >correct and best practices" authoritative nameserver.
> Thank you, thank you.

I can also tell you it is fun to start one from scratch and not make the
same mistakes again!

> >1) chase CNAMEs that point to another zone
> >2) look for glue outside of the zone
> 
> 1) What was the historical text that indicated that an authoritative server
> should chase CNAMEs before responding? This worries me.

RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that
in step 2 we look up the best zone again for the target of the CNAME. I have
not looked if newer RFCs deprecate this or not. So with 'chase' I mean,
consult other zones it is authoritative for. There might be millions of
these btw, operated by other people.

> 2) What does "look for" mean here? Can you give an example of what you are
> no longer doing in this authoritative?

Sure. Let's say our auth has two zones loaded, 'red.com' and 'blue.com'.

In red.com:
france.red.com  IN  NS  ns1.blue.com

And in blue.com:
ns1.blue.comIN  A   127.0.0.1

If a query comes in for 'something.france.com', the authoritative server
will send out a delegation and answer with 'france.red.com IN NS
ns1.blue.com'. 

According to 1034, 4.3.2, step 3, b, we should now add 'addresses' if we
have them for ns1.blue.com. 

My question is, should we look at the blue.com zone for those addresses? 

If course, if the NS record would be ns1.france.red.com, we should of course
pass along glue since otherwise nothing can proceed.

> >[1] - so cute https://twitter.com/PowerDNS_Bert/status/983659389935603712
> 
> Is this a suggestive plea for more camels to be sent to you? If so, you
> should include your favored postal address so some of us can help your
> collection grow. :-)

The PowerDNS office at Herengracht 38b, 2511 EJ, The Hague, The Netherlands
loves receiving packages :-)

Bert

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Paul Hoffman]

My takeaway is that RFC 1034 Section 4.3.2 talks about "servers" without 
differentiating between authoritative servers and the server side of 
resolvers. If we can get agreement on detangling those two, it would be 
a huge service to the DNS community.


--Paul Hoffman

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Evan Hunt]

On Fri, Apr 13, 2018 at 05:11:52PM +0200, bert hubert wrote:
> RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that
> in step 2 we look up the best zone again for the target of the CNAME. I have
> not looked if newer RFCs deprecate this or not. So with 'chase' I mean,
> consult other zones it is authoritative for. There might be millions of
> these btw, operated by other people.

The search algorithm has been updated a few times (most recently 6672, I
believe?) but AFAIK this phrasing remains in effect, and probably ought to
be clarified in a future document. That said, it's up to you what zones you
consider "available" in step 2, and there's no reason you can't limit the
set of available zones to the ones that were in bailiwick for the original
query, so you're not breaking any rules.

I could have sworn there was an RFC published several years ago concerning
the prevention of cache poisoning, which specified that resolvers had to
ignore out of zone CNAMEs and re-query, but I can't find it now. Poor
google skills, or did I dream the whole thing?

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Mukund Sivaraman]

On Fri, Apr 13, 2018 at 04:31:35PM +, Evan Hunt wrote:
> I could have sworn there was an RFC published several years ago concerning
> the prevention of cache poisoning, which specified that resolvers had to
> ignore out of zone CNAMEs and re-query, but I can't find it now. Poor
> google skills, or did I dream the whole thing?

RFC 2181

Mukund

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Evan Hunt]

On Sat, Apr 14, 2018 at 01:13:30AM +0800, Mukund Sivaraman wrote:
> On Fri, Apr 13, 2018 at 04:31:35PM +, Evan Hunt wrote:
> > I could have sworn there was an RFC published several years ago concerning
> > the prevention of cache poisoning, which specified that resolvers had to
> > ignore out of zone CNAMEs and re-query, but I can't find it now. Poor
> > google skills, or did I dream the whole thing?
> 
> RFC 2181

That was a "should", not a MUST. I thought I remembered something that
upgraded it to MUST, but I can't find it now.

It's possible I was thinking of RFC 5452 (which I now see was authored by
the person whose question I was answering -- *this* is how you suck eggs,
grandma).  It says, "Care must be taken to only accept data if it is known
that the originator is authoritative for the QNAME or a parent of the
QNAME.  One very simple way to achieve this is to only accept data if it is
part of the domain for which the query was intended." This is less
strongly-worded than what I remembered, but at least it does strongly hint
that returning out-of-zone CNAMEs is likely to be a waste of effort.

When we do the 1034 bis I'd like to see this made more explicit.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Mukund Sivaraman]

On Fri, Apr 13, 2018 at 05:35:14PM +, Evan Hunt wrote:
> On Sat, Apr 14, 2018 at 01:13:30AM +0800, Mukund Sivaraman wrote:
> > On Fri, Apr 13, 2018 at 04:31:35PM +, Evan Hunt wrote:
> > > I could have sworn there was an RFC published several years ago concerning
> > > the prevention of cache poisoning, which specified that resolvers had to
> > > ignore out of zone CNAMEs and re-query, but I can't find it now. Poor
> > > google skills, or did I dream the whole thing?
> > 
> > RFC 2181
> 
> That was a "should", not a MUST. I thought I remembered something that
> upgraded it to MUST, but I can't find it now.

Nod, RFC 2181 doesn't use RFC 2119/8174 keywords, so the "should" there
doesn't have a pointy meaning.

Mukund

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[神明達哉]

At Fri, 13 Apr 2018 16:47:07 +0200,
bert hubert  wrote:

> In writing this server and while consulting with some other implementors, I
> for now have decided that in 2018 it makes no sense to:
>
> 1) chase CNAMEs that point to another zone

It may not even make sense to chase CNAME in the same zone, since the
receiving resolver generally can't be sure if it's really in the same
zone and would need to chase it by itself anyway.

When a resolver receives this from an 'example.com' authoritative server:
alias.example.com. CNAME cname1.example.com.
cname1.example.com.  2001:db8::1

It might look cname1.example.com. is actually in the
example.com. zone, but the resolver can't be 100% sure about it unless
it also knows cname1.example.com. is on a zone cut.  And, in my
understanding, today's deployed resolvers actually chase
cname1.example.com./ by itself.  So the  added by the
authoritative server would effectively be a waste.

(If the zone is DNSSEC signed and the authoritative server can include
DNSSEC proofs of the RRsets in the chain, the story may become
different.  But I don't think we are discussing such an "advanced"
case).

--
JINMEI, Tatuya

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

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Matthew Pounsett]

On 13 April 2018 at 11:11, bert hubert  wrote:

> > >1) chase CNAMEs that point to another zone
> > >2) look for glue outside of the zone
> >
> > 1) What was the historical text that indicated that an authoritative
> server
> > should chase CNAMEs before responding? This worries me.
>
> RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that
> in step 2 we look up the best zone again for the target of the CNAME. I
> have
> not looked if newer RFCs deprecate this or not. So with 'chase' I mean,
> consult other zones it is authoritative for. There might be millions of
> these btw, operated by other people.
>

Wouldn't there be a security concern with doing that?

Let's say you're a DNS hosting company and I get you to host example.com
for me, and delegate it to your servers.  For some good, but obscure reason
I have:
update.example.com IN CNAME update.microsoft.com.

An attacker comes along and asks you to host microsoft.com, which is not
delegated to you.  They have:
update.microsoft.com IN CNAME attack.badguy.com.

If you follow CNAME chains outside the zone (but inside the "authoritative"
zones in your server) then you have just participated in redirecting a
CNAME chain away from where it's supposed to go.  Either recursive servers
will trust your supplied CNAME chain and their users will be attacked, or
they will (rightly) not trust you and go look up update.microsoft.com
themselves, which, in which case you have wasted resources looking it up in
your own.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Blog Post: DNS over TLS support in Android P Developer Preview

[Warren Kumari]

Hi all,

As Erik Kline and Ben Schwartz seem to be too modest to toot their own
horn, I'll do it for them:
https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html

Snippet from the above:
"The Android P Developer Preview includes built-in support for DNS
over TLS. We added a Private DNS mode to the Network & internet
settings.

By default, devices automatically upgrade to DNS over TLS if a
network's DNS server supports it. But users who don't want to use DNS
over TLS can turn it off."

W
 (Also posted to dprive)
-- 
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] Blog Post: DNS over TLS support in Android P Developer Preview

[Marek Vavruša]

This is great, well done.

On Fri, Apr 13, 2018 at 12:49 PM, Warren Kumari  wrote:
> Hi all,
>
> As Erik Kline and Ben Schwartz seem to be too modest to toot their own
> horn, I'll do it for them:
> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
>
> Snippet from the above:
> "The Android P Developer Preview includes built-in support for DNS
> over TLS. We added a Private DNS mode to the Network & internet
> settings.
>
> By default, devices automatically upgrade to DNS over TLS if a
> network's DNS server supports it. But users who don't want to use DNS
> over TLS can turn it off."
>
> W
>  (Also posted to dprive)
> --
> 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

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

[DNSOP] "Trustworthiness" - was Re: [Ext] Re: tdns, 'hello-dns' progress, feedback requested

[Edward Lewis]

On 4/13/18, 13:51, "DNSOP on behalf of Mukund Sivaraman" 
 wrote:

>Nod, RFC 2181 doesn't use RFC 2119/8174 keywords, so the "should" there
>doesn't have a pointy meaning.

In "Clarifications to the DNS Specification" (the title of RFC 2181, which 
ought to give some idea of how significant the work is), it talks of 
"trustworthiness" in a section on "ranking data" (5.4.1).

But note this wording:

"The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:"

At the time DNSSEC was just beginning, with the clarifications from DNSIND WG 
and DNSSEC in the DNSSEC WG.  The words about "assumed from its source" is 
interesting this context, at least two people in the acknowledgements or 
editors for the clarifications document and the January 1997 edition of "DNS 
Security Extensions" (RFC 2065).


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

Re: [DNSOP] [Ext] Re: tdns, 'hello-dns' progress, feedback requested

[Edward Lewis]

On 4/13/18, 15:02, "DNSOP on behalf of Matthew Pounsett" 
 wrote:

>On 13 April 2018 at 11:11, bert hubert  wrote:

>>RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that
in step 2 we look up the best zone again for the target of the CNAME. I have
not looked if newer RFCs deprecate this or not. So with 'chase' I mean,
consult other zones it is authoritative for. There might be millions of
these btw, operated by other people.

>Wouldn't there be a security concern with doing that?

Certainly.

And you just woke up a hole I've seen but not realized.

A name server may be properly authoritative (legit?) for a zone - meaning that 
somehow, when consulting the (grand)parent of the zone on another server, you 
can manage to get to the zone.  (The wording here is hairy as I'm accounting 
for cases where the NS sets above the cut and below the cut aren't the same, 
having some overlap.  Yes, that's broken, but it works.)

Name servers may also be configured to host zones they "ought not" (ill-legit) 
- such as a zone of an exited customer of a DNS hosting service.  I know this 
could happen in multi-tenant hosting providers who don't check whether their 
customers are registered "owners" of the zones the customer configures.  Or 
forget to clean up after departed customers.

If a name server CNAME chases from a "legit" zone to an "ill-legit zone" things 
could get interesting, especially when debugging.

I have thought, for a very long time, "chasing" of any DNS "rewrite rule" is 
wrong - CNAME or DNAME.  Leave the query gymnastics to the DNS iterator, the 
trust policy ought to be homed at the searcher's end.  But that is just 
opinion...

Oh, I meant to say - the above opinion I had when I worked for a hoster.  Since 
the hoster charged by query volume, if I had made that public I'd be accused of 
trying to raise revenue artificially.  But as a protocol analyst, I think that 
a few more queries is worth the simplicity...but you can argue "round trips" 
and all latency problems...but then I'd argue "that's what caching is for...





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