Subject: [DNSOP] refer-down

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 May 2018 13:22:12 -0400

Dear colleagues,

As a consequence of some of the discussion about clarifying the term
"referrals" in terminology-bis, it became clear that we didn't really
have a place that said not to do upward referrals.  So, Joe Abley and
I put this little draft together:

https://tools.ietf.org/html/draft-sullivan-dnsop-refer-down-00

I _think_ it is useful, but it didn't get much comment when we put it
out because everyone was paying attention to the terminology
document.  Does anyone else think it's useful?  If so, and some people
are prepared to do some reviews, I'm prepared to work on it.  But it's
about to expire, and if nobody else thinks it's worth the wasted
electrons I don't feel strongly enough about it to have the fight.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 May 2018 23:17:33 +0530

Hi Andrew

> electrons I don't feel strongly enough about it to have the fight.

RFC 1034 mentions how to handle upward referrals - ignore them. Section
5.3.3:

If the response shows a delegation, the resolver should check to see
that the delegation is "closer" to the answer than the servers in SLIST
are.  This can be done by comparing the match count in SLIST with that
computed from SNAME and the NS RRs in the delegation.  If not, the reply
is bogus and should be ignored.  If the delegation is valid the NS
delegation RRs and any address RRs for the servers should be cached.
The name servers are entered in the SLIST, and the search is restarted.

But I do note the difference that your document is about "don't create
upward referrals" whereas the above is "don't accept upward referrals".

		Mukund

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 May 2018 14:14:51 -0400

Hi,

On Mon, May 28, 2018 at 11:17:33PM +0530, Mukund Sivaraman wrote:
> 
> RFC 1034 mentions how to handle upward referrals - ignore them.

Ok, I'll just let this expire.  Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 May 2018 00:08:36 +0530

Hi Andrew

> Ok, I'll just let this expire.  Thanks,

I didn't mean to discourage this.. clarified explanations are usually
good to have. You seem to have put a lot of effort into it; perhaps you
can update it as a clarification that provides more detail.

		Mukund

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 May 2018 14:47:59 -0400

> can update it as a clarification that provides more detail.

It was just ancillary effort needed to make the terminology-bis
discussion work, so it wasn't really much effort.  Maybe it's useful
text to have around if we ever get around to fixing up STD13 to be a
modern document, but perhaps not that useful just now, since most
people are unlikely to read it anyway.  Also, you're the only person
who's commented directly and that makes me think the WG isn't going to
do much review of it, which makes me think the effort would be
rewarded with more effort and then no document coming out :)

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 28 May 2018 21:34:06 -0400

> Also, you're the only person who's commented directly and that makes
> me think the WG isn't going to do much review of it

Sheesh, it's a national holiday in the US and UK today.  Some of us
were out having picnics.

I like it because I like anything that makes the DNS simpler.  I'd
make the advice clearer, authoritative servers that want to
interoperate MUST refuse out of zone requests.  (I realize there are
some clients that will misinterpret that but they're already so broken
it's hard to care if they are now differently broken.)  It's MUST
rather than SHOULD because of course you can do what you want, but you
will not interoperate with a standard compliant client by returning
anything else.

I'd also like to consider offering clearer advice on what do do when a
recursive server gets an authoritative query.  Is there any situation
other than misconfiguration or testing when that would happen?  Are we
doing anyone a real favor by returning anything other than REFUSED?

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 May 2018 23:28:40 -0400

> Sheesh, it's a national holiday in the US and UK today.  Some of us

My apologies for being unclear.  My point was rather that the draft is
about to expire, and Joe and I created it entirely to draw away the
debate of how referrals _should_ happen from the terminology
document.  Tht was what I meant by "the only person".  As someone who
can barely manage to cope with emails at a 1 week interval any more,
I'm hardly likely to complain people don't get back the same day; but
I do apologise that wasn't clear.

> interoperate MUST refuse out of zone requests.

This is an interesting suggestion.  

> doing anyone a real favor by returning anything other than REFUSED?

You mean, when a server that is not authoritative for anything
nevertheless gets a query with RD==0?  I think that's fine.  How else
do you debug a cache?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 29 May 2018 11:52:23 -0400

>This is an interesting suggestion.  

Thanks.

>nevertheless gets a query with RD==0?  I think that's fine.  How else

I'm guessing that it's intended to mean return the answer if you
already have it.  If so, we should document that.  I see that unbound
makes it an option but normally refuses any RD=0 queries.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 May 2018 12:03:27 -0400

> makes it an option but normally refuses any RD=0 queries.

When you're doing support and someone is having a problem, one good
thing to do is dig @targetresolver +norec to see what it gives you,
yes.  A difference between that and what you get at the authoritative
server is often the explanation for the trouble.  (One fun example: an
ISP on the wrong end of a slow pipe in a certain country was doing
unauthorized zone transfers for a TLD's zone.  When TSIG became
required for the zone transfers, their transfers were suddenly
failing.  Instead of fixing it or alerting anyone, they just kept
restarting BIND to use the old zone.  It took quite a lot of effort to
sort that out, and determining how caches were getting so much bad
data in them was a key to figuring it out.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 May 2018 09:09:29 -0700

John Levine wrote:
> ...

it's a diagnostic query, like qtype=ANY, or qtype=NS. answering it 
should be privileged in some way, since it's an information leak that 
does not help the rdns operator in any way, but may help an attacker.

-- 
P Vixie