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

From: bert hubert <[email-masked]>
Date: Fri, 13 Apr 2018 16:47:07 +0200

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 13 Apr 2018 07:59:19 -0700

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

> and best practices" authoritative nameserver.

Thank you, thank you.

> 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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 13 Apr 2018 08:05:14 -0700

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.

---

From: bert hubert <[email-masked]>
Date: Fri, 13 Apr 2018 17:11:52 +0200

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) 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.com	IN	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.

> should include your favored postal address so some of us can help your

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

	Bert

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 13 Apr 2018 08:22:31 -0700

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

---

From: Evan Hunt <[email-masked]>
Date: Fri, 13 Apr 2018 16:31:35 +0000

> 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 -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 14 Apr 2018 01:13:30 +0800

> google skills, or did I dream the whole thing?

RFC 2181

		Mukund

---

From: Evan Hunt <[email-masked]>
Date: Fri, 13 Apr 2018 17:35:14 +0000

> > google skills, or did I dream the whole thing?

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.

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 14 Apr 2018 01:51:25 +0800

> 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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 13 Apr 2018 11:15:37 -0700

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

> 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. AAAA 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./AAAA by itself.  So the AAAA 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

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 13 Apr 2018 15:02:32 -0400

On 13 April 2018 at 11:11, bert hubert <[email-masked]> wrote:

> server

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.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Apr 2018 20:19:40 +0000

On 4/13/18, 15:02, "DNSOP on behalf of Matthew Pounsett" <mailto:[email-masked] on behalf of mailto:[email-masked]> wrote:

>On 13 April 2018 at 11:11, bert hubert <mailto:[email-masked]> wrote:

>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...

---

From: Tony Finch <[email-masked]>
Date: Mon, 16 Apr 2018 15:30:36 +0100

> this ok, and do we already have words on if chasing CNAMEs outside of zones

I'm slightly surprised that Evan and Mukund haven't mentioned this, but
BIND 9.1 to 9.11 had additional-from-cache and additional-from-auth
options which controlled this behaviour. (I turned them off on my servers
years ago.) In 9.12 the options have been removed and authoritative
answers never chase around in search of gossip.

The additional-from-auth toggle reminds me of the somewhat painful history
of glue handling in the shared .com / .net registry and DNS servers...

>   bugs.  Not practically very relevant, but still.

My recursive server gets upset because in noerror/nodata answers, the SOA
record appears in the answer section not the authority section.

I guess (without checking) the libc stub resolver is objecting to the
hostname syntax violations. But if I

	$ ping 'some host.tdns.powerdns.org'

it does actually ask the recursive server before giving up in disgust.
Weird.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
justice and liberty cannot be confined by national boundaries

---

From: bert hubert <[email-masked]>
Date: Mon, 16 Apr 2018 17:13:33 +0200

> answers never chase around in search of gossip.

Ok - so it appears staying "in zone" for CNAME and glue is fine, or perhaps
even recommended? A best practice?

> record appears in the answer section not the authority section.

Fixed! 

> it does actually ask the recursive server before giving up in disgust.

It is indeed somewhat strange, but I'm not even sure if this is bad or good.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Apr 2018 08:38:05 -0700

one thing to note is that when the server is authoritative for more than 
one zone, a cname that crosses from one such zone to another is allowed 
by 1035 to be chased. however, the resolver has no reason to accept 
out-of-zone records, since it cannot be sure that a new query in the 
bailiwick of the second zone would be answered the same way (or by the 
same server.) after kashpureff, we ignore the out-of-zone data and 
re-fetch it. this strongly calls for an update to 1035, since akamai and 
other CDN's are sending multi-zone cname chains, and they need to know 
that they should not do that, and also, resolver implementers need to 
know that they should be stripping any answer from the response whose 
owner name is not in-bailiwick with their QNAME.

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 18 Apr 2018 18:21:41 -0400

>   bugs.  Not practically very relevant, but still.

I think this is intentional behavior in the stub resolver, e.g. in glibc
there's a function res_hnok used to enforce restrictions on hostnames.

It looks like res_hnok in glibc got rewritten recently, too:

https://sourceware.org/bugzilla/show_bug.cgi?id=22412

-- 
Robert Edmonds

---

From: Florian Weimer <[email-masked]>
Date: Fri, 20 Apr 2018 14:46:25 +0200

>    bugs.  Not practically very relevant, but still.

It is relevant because sometimes * wildcards leak into such CNAME chains:

   https://sourceware.org/bugzilla/show_bug.cgi?id=12154

glibc should just filter out such wildcards, and not completely reject 
the answer.  (I think that stub resolvers should stop processing CNAMEs 
completely and use the actual QNAME, after search list processing, as 
the canonical name, but that is controversial.)

I'm slightly worried that a naïve implementation of the skipping 
introduces a denial-of-service vulnerability because parsing many binary 
domain names can be quite costly, requiring millions of cycles and 
expanding to 6 MiB in total for 64 KiB packet.

Thanks,
Florian