Subject: [DNSOP] what's the right thing to do upon receiving something like this?

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Feb 2007 19:18:35 +0000

there is an rfc1918 address for this nameserver.  there's no way for me to
be sure that it's the same 10.20.2.102 that i would reach if i tried, yet
there's no way to be sure that it's not the same, either.  granted that the
best thing is if the address would not be published outside the connectivity
realm where that address works, what should i as the recipient do if it's
published by mistake?  (and what of 127/8, 0/8, 169.254/16, et al?)

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30414
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 31

;; QUESTION SECTION:
;drvthru.com.                   IN      NS

;; ANSWER SECTION:
drvthru.com.            172556  IN      NS      ns1.drvthru.com.
drvthru.com.            172556  IN      NS      ns2.drvthru.com.

;; ADDITIONAL SECTION:
ns1.drvthru.com.        172556  IN      A       65.36.252.4
ns2.drvthru.com.        3356    IN      A       65.36.252.20
ns2.drvthru.com.        3356    IN      A       65.36.252.11
ns2.drvthru.com.        3356    IN      A       65.36.252.14
ns2.drvthru.com.        3356    IN      A       65.36.252.13
ns2.drvthru.com.        3356    IN      A       65.36.252.4
ns2.drvthru.com.        3356    IN      A       65.36.252.12
ns2.drvthru.com.        3356    IN      A       65.36.252.22
ns2.drvthru.com.        3356    IN      A       65.36.252.21
ns2.drvthru.com.        3356    IN      A       65.36.252.6
ns2.drvthru.com.        3356    IN      A       65.36.252.32
ns2.drvthru.com.        3356    IN      A       10.20.2.102
ns2.drvthru.com.        3356    IN      A       65.36.251.163
ns2.drvthru.com.        3356    IN      A       65.36.252.31
ns2.drvthru.com.        3356    IN      A       65.36.252.30
ns2.drvthru.com.        3356    IN      A       65.36.252.29
ns2.drvthru.com.        3356    IN      A       65.36.252.28
ns2.drvthru.com.        3356    IN      A       65.36.252.27
ns2.drvthru.com.        3356    IN      A       65.36.252.26
ns2.drvthru.com.        3356    IN      A       65.36.252.25
ns2.drvthru.com.        3356    IN      A       65.36.252.24
ns2.drvthru.com.        3356    IN      A       65.36.252.23
ns2.drvthru.com.        3356    IN      A       65.36.252.16
ns2.drvthru.com.        3356    IN      A       65.36.252.7
ns2.drvthru.com.        3356    IN      A       65.36.252.15
ns2.drvthru.com.        3356    IN      A       65.36.252.17
ns2.drvthru.com.        3356    IN      A       65.36.252.8
ns2.drvthru.com.        3356    IN      A       65.36.252.18
ns2.drvthru.com.        3356    IN      A       65.36.252.9
ns2.drvthru.com.        3356    IN      A       65.36.252.19
ns2.drvthru.com.        3356    IN      A       65.36.252.10

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Feb 16 19:03:16 2007
;; MSG SIZE  rcvd: 561

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: bert hubert <[email-masked]>
Date: Fri, 16 Feb 2007 20:46:09 +0100

> published by mistake?  (and what of 127/8, 0/8, 169.254/16, et al?)

The PowerDNS recursor has recently gained support for the "dont-query"
setting:

 The DNS is a public database, but sometimes contains delegations to private
 IP addresses, like for example 127.0.0.1. This can have odd effects,
 depending on your network, and may even be a security risk. Therefore, since
 version 3.1.5, the PowerDNS recursor by default does not query private space
 IP addresses. This setting can be used to expand or reduce the limitations.

It defaults to blocking RFC1918 addresses.

 arg().set("dont-query", "If set, do not query these netmasks for DNS
 data")="127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, ::1/128,
 fe80::/10"; 
 
This has solved several odd situations with misconfigured domains listing
10.0.0.1 and 127.0.0.1 as some of their nameservers.

People tell us they perceive our dont-query flag to be an improvement.
Dont-query is part of 3.1.5, which is not yet released, but snapshots are in
use at various very large places.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: bert hubert <[email-masked]>
Date: Fri, 16 Feb 2007 20:46:09 +0100

Bert

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Feb 2007 21:27:12 +0000

> 10.0.0.1 and 127.0.0.1 as some of their nameservers.

if there was an rfc that talked about this, it would be more widely
implemented.  (i'm not sure bind wouldn't follow powerdns's lead on this
topic, but i am sure that if there was an rfc, bind would have a similar
feature.)  so the key question is, have we got consensus on the behaviour?
(compared to consensus, finding someone to write it up is relatively easy.)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Feb 2007 21:27:12 +0000

---

From: Robert Story <[email-masked]>
Date: Fri, 16 Feb 2007 16:50:16 -0500

On Fri, 16 Feb 2007 21:27:12 +0000 Paul wrote:
PV> >  The DNS is a public database, but sometimes contains delegations to private
PV> >  IP addresses, like for example 127.0.0.1. This can have odd effects,
PV> >  depending on your network, and may even be a security risk. Therefore, since
PV> >  version 3.1.5, the PowerDNS recursor by default does not query private space
PV> >  IP addresses. This setting can be used to expand or reduce the limitations.
PV> [...]
PV> if there was an rfc that talked about this, it would be more widely
PV> implemented.  (i'm not sure bind wouldn't follow powerdns's lead on this
PV> topic, but i am sure that if there was an rfc, bind would have a similar
PV> feature.)  so the key question is, have we got consensus on the behaviour?

Sounds good to me...

-- 
Robert Story
SPARTA

---

From: Robert Story <[email-masked]>
Date: Fri, 16 Feb 2007 16:50:16 -0500

Sounds good to me...

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Feb 2007 09:20:47 +1100

> (compared to consensus, finding someone to write it up is relatively easy.)

	Named already has this capability.

	You can use the blackhole acl or you can use multiple
	server "cidr" { bogus yes; };.

		server 10.0.0.0/8 { bogus yes; };
		server 172.16.0.0/12 { bogus yes; };
		server 192.168.0.0/16 { bogus yes; };

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Feb 2007 09:20:47 +1100

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Feb 2007 22:23:42 +0000

> > implemented.  ...

what i'd like is permission from the IETF community to change our default.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Feb 2007 22:23:42 +0000

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Feb 2007 09:38:52 +0100

> 		server 192.168.0.0/16 { bogus yes; };
is there a way to say "if source is in same domain, allow, else deny"?
I'd like to allow 10.0.0.53 as a nameserver on *my* (home) network....

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Feb 2007 09:38:52 +0100

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 18:47:03 +0800

>what i'd like is permission from the IETF community to change our default.

My opinion...and just that...

Don't change.  I prefer having the nameserver be told to take extra 
measures in a case like this.

1) RFC 1918 is legitimate space, it's just not routed.
2) By moulding a platform to peculiar behaviors it looses flexibility.
3) I don't buy this as a security risk.  I don't think there is a problem here.

I mention #3 in the vein that I don't like to see permanent fixes to 
temporary problems (or extremely rare misconduct).

I don't buy that this is a security risk; if it is, DNSSEC would be 
the fix to that (for once).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"Two years ago you said we had 5-7 years, now you are saying 3-5.  What I
need from you is a consistent story..."

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 18:47:03 +0800

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Feb 2007 10:55:08 +0000

> 3) I don't buy this as a security risk.  I don't think there is a problem

It allows you to use a DNS server to tunnel past a firewall. It allows you
to use a DNS server to probe a private network.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BAILEY: SOUTHEAST BACKING EAST 5 OR 6 INCREASING 7 OR GALE 8, PERHAPS SEVERE
GALE 9 LATER. VERY ROUGH OR HIGH. OCCASIONAL RAIN. MODERATE OR GOOD.

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Feb 2007 10:55:08 +0000

Tony.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 19:14:27 +0800

>to use a DNS server to probe a private network.

How?

Let's say I am an iterating server.

I send out a query

I get a referral effectively saying to go to 10.1.1.1.

I try my query (again) to that address

Either I will have a 10.1.1.1 locally and it has a port 53 resident DNS
or
I have a 10.1.1.1-enclosing subnet locally
or
I have a default route to the Internet

case 1 - the server will probably reply with a lame indication
case 2 - the UDP's will dry up in the ether
case 3 - the UDP will be dropped at a border router or the ISP's router

How would the person that put the 10.1.1.1 address into the DNS 
benefit from this in the sense that it compromises my security?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 19:14:27 +0800

How?

I send out a query

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Feb 2007 11:22:32 +0000

Edward Lewis wrote:
>>>  3) I don't buy this as a security risk.  I don't think there is a
>>> problem
>>>  here.
>>

Not if you told the server to recurse.

> How would the person that put the 10.1.1.1 address into the DNS benefit
> from this in the sense that it compromises my security?
> 

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Feb 2007 11:22:32 +0000

---

From: Jim Reid <[email-masked]>
Date: Mon, 19 Feb 2007 11:34:59 +0000

On Feb 19, 2007, at 10:47, Edward Lewis wrote:

> I prefer having the nameserver be told to take extra measures in a  
> case like this.

Right. But it depends on what's meant by "extra measures". IMO it's  
more than reasonable to have a default that says "don't do reverse  
lookups of 1918 addresses on the Internet". This would be a Very Good  
Thing. If this was in place, the extra measures would then be for  
someone using 1918 addressing to switch off that default and properly  
configure their server for the local network.

Perhaps this should apply to reverse lookups on other "special"  
address ranges such as link-local 169.254/16 too?

Another desirable default resolver configuration would be to refuse  
recursive queries from non-local addresses.

---

From: Jim Reid <[email-masked]>
Date: Mon, 19 Feb 2007 11:34:59 +0000

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 19:39:33 +0800

>Not if you told the server to recurse.

I don't understand your reply.

I could send a "RD" bit in my query and still get a referral.

If I do send a "RD" bit in the query and the remote server allows 
("RA") then I wouldn't see the RFC 1918 address - and this all 
becomes a non-problem.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 19:39:33 +0800

---

From: Alok <[email-masked]>
Date: Mon, 19 Feb 2007 17:13:09 +0530

Just a comment, it is common for people to make entries in private DNS for  
IP addresses outside their control, not sure about vice versa but it is no  
big deal.

I remember this client requirement way back in 2000

It was more like 2 projects in a customer environment with something being  
developed here and something being developed there.

the original company was say a site www.xyz.com(whose DNS entry was  
unknown to me) with some IP range which was not common to the 2 clients.
more like his DNS had an entry say:

www.xyz.com IN A p.q.r.s

there was an IPSEC tunnel to the place where the p.q.r.s was located and  
their servers were not in our control.
and the local client's domain was say:  project.clientdomain.com

now because of the way the stuff/application was being built, i had to do  
something like

www.xyz.project.clientdomain.com IN A p.q.r.s

now is it right or wrong i dont know, im not a java developer, but this is  
what was done back then,

(from what i was given to understand as to why the local client could not  
use the other person's DNS was security issues, only the IP addresses were  
exposed)

-thanks
Alok

-- 
A revolutionary idea is usually made with sleeves rolled up

---

From: Alok <[email-masked]>
Date: Mon, 19 Feb 2007 17:13:09 +0530

www.xyz.com IN A p.q.r.s

-thanks
Alok

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 19:56:36 +0800

At 11:34 +0000 2/19/07, Jim Reid wrote:

>Right. But it depends on what's meant by "extra measures". IMO it's more than
>reasonable to have a default that says "don't do reverse lookups of 1918
>addresses on the Internet". This would be a Very Good Thing. If this was in
>place, the extra measures would then be for someone using 1918 addressing to
>switch off that default and properly configure their server for the local
>network.

I disagree about the "Very Good Thing."

If I am using RFC 1918 space locally I will use those addresses in my 
local forward DNS and have a local reverse DNS.  My remote-facing DNS 
will not have those addresses and hence not have any reverse zones.

Part of the problem is that the DNS server doesn't know if it is 
doing "reverse lookups of 1918 addresses on the Internet" or if it is 
doing reverse lookups of 1918 addresses on the company Intranet.

>
>Perhaps this should apply to reverse lookups on other "special" address
>ranges such as link-local 169.254/16 too?

I'd say no.

The addresses are special to the routing layer, not the DNS layer. 
This is another round of "let's screw the DNS protocol because of 
problems elsewhere" - just like last spring when we tried to do 
something about the first amplication attacks that became reflection 
attacks that then led to a least one task force to get the BCP on 
routing to be followed.

Sorry folks if I'm being dense or just ornery about fooling with 
Mother Nature here.  If you start bending the DNS protocol to route 
around damage in other parts of the network architecture, you'll be 
weakening one more element.

>recursive queries from non-local addresses.

How?  What's local?  What's not local?  Do you want to see the name 
server be required to also speak the local routing protocols to 
determine what's inside and what's outside?

Remember that the more you stuff into the configuration files, the 
more you are going to cost the operators that have to manage the 
configurations.  Unlike zone data, DNS doesn't not have a standard 
management protocol.

So, back before my rant.

First let's talk about whether it is a problem to have RFC 1918 space 
exposed as an address for a nameserver.  Second, let's talk about the 
severity, and is there some real threat to others if someone does 
this.  Third, then let's talk about placing safeguards up.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Feb 2007 19:56:36 +0800

I'd say no.

So, back before my rant.

---

From: Jim Reid <[email-masked]>
Date: Mon, 19 Feb 2007 12:47:44 +0000

On Feb 19, 2007, at 11:56, Edward Lewis wrote:

> If I am using RFC 1918 space locally I will use those addresses in  
> my local forward DNS and have a local reverse DNS.  My remote- 
> facing DNS will not have those addresses and hence not have any  
> reverse zones.
>
> doing "reverse lookups of 1918 addresses on the Internet" or if it  
> is doing reverse lookups of 1918 addresses on the company Intranet.

Which in the final analysis is a matter of configuration. Which is  
where this needs to be done anyway because it depends on local  
policy. For the scenario you describe, this needs to be done no  
matter what default exists or doesn't exist.
You simply have to tell your server whether it's resolving local or  
"public" 1918 space. Or not resolving it at all.

IMO, it's better if there's a sensible default configuration -- for  
some definition of sensible -- that works "right out the box". This  
has to be an improvement on leaving things undefined, usually  
misconfigured and DNS administrators in complete ignorance of the  
problems that this misconfiguration causes for others.

In a way this parallels the early days of inetd. Once upon a time  
this was shipped with a default config file that had everything  
enabled. Admins mostly left inetd.conf alone because they assumed it  
was set up the way the OS vendor wanted. Nowadays, everything is  
usually switched off by default, forcing the admin to make a  
conscious decision to enable service: ie implicitly define and  
implement local policy. Why can't we learn from that experience?

> weakening one more element.

I fail to see how changing -- I'd say defining -- the default  
behaviour of a name server in this way could possibly be a protocol  
issue.

> determine what's inside and what's outside?

Ed, you're being ridiculous. All I was suggesting here was, in BIND  
terms, making "allow-recursion { localnets; };" the default. This has  
to be preferable to the current situation of a free-for-all for  
everyone. If that default isn't right, then the admin is required to  
make a conscious act to make the server comply with local policy.  
Which they should be doing anyway of course. Where's the harm?

> configurations.

True enough. But there are trade-offs here. Tweaking a handful of  
config file options is a one-off cost. And has the side-effect of  
minimally documenting local policy, if only through reading the  
config file. The consequences of bad defaults and undefined  
configurations leaves many name servers creating all sorts of  
trouble. Worse, the trouble is for others and the local DNS admin is  
blissfully unaware of that. ISTR 40-60% of root server traffic would  
go away if people using 1918 addressing configured their name servers  
properly. IMO this WG shouldn't wash its hands of this problem,  
claiming its a protocol issue and not an operational one. Which is  
what you appear to suggesting Ed. I hope not.

> First let's talk about whether it is a problem to have RFC 1918  
> space exposed as an address for a nameserver.

It is.

> Second, let's talk about the severity, and is there some real  
> threat to others if someone does this.

There is.

> Third, then let's talk about placing safeguards up.

I refer you to my previous posting. :-)

---

From: Jim Reid <[email-masked]>
Date: Mon, 19 Feb 2007 12:47:44 +0000

It is.

There is.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Feb 2007 14:02:14 +0100

On Mon, Feb 19, 2007 at 07:56:36PM +0800,
 Edward Lewis <[email-masked]> wrote 

> determine what's inside and what's outside?

While I agree with most of what you said (we should not treat the RFC
1918 addresses in a special way because they are not special), here, I
find that you exaggerate: many programs test what is local or not by
checking if the client is on a directly-connected network. (And, of
course, the sysadmin can override it.) If handles most of the
cases. So, using "local" to mean "LAN" is not too bad.

Postfix works that way (by default, it relays only for local
addresses) and everyone seems happy.

The source code in ./src/util/inet_addr_local.c is fun to read, with
all the comments on portability.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Feb 2007 14:02:14 +0100

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Feb 2007 14:27:30 +0000

> > to use a DNS server to probe a private network.

If you point NS records at private networks then you can get DNS servers
to send queries to their private networks. The timing of any responses you
get might give you some information about their network topology, e.g.
which hosts are up, etc.

More interestingly, consider a user on a private network that is heavily
firewalled (not even NAT connectivity to the Internet) and who wants to
tunnel out. If there is a nameserver connected to the internal and
external networks, and the user can persuade it to make a query controlled
by the user, then the user can get it to recurse back and forth between a
public IP address and the user's private IP address, passing data in the
process. Note that the user does not require direct access to a recursive
resolver: for example, they could trigger the query by saying HELO to a
mail server. One trigger query can result in several back-and-forth
exchanges via the tunnel.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: SOUTHEAST 5 OR 6, INCREASING 7 OR GALE 8. ROUGH OR VERY ROUGH.
OCCASIONAL RAIN. MODERATE OR GOOD.

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Feb 2007 14:27:30 +0000

Tony.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Feb 2007 14:50:56 +0000

> I'd like to allow 10.0.0.53 as a nameserver on *my* (home) network....

you mean, a name server looking at its own fully qualified host name and
making policy decisions based on that?  (sounds Incredibly Dangerous.)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Feb 2007 14:50:56 +0000

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 19 Feb 2007 16:36:24 +0100

> making policy decisions based on that?  (sounds Incredibly Dangerous.)

I'm possibly confused. The scenario I was thinking of seems to involve two 
nameservers on the same 10.x.x.x network that want to point to each other 
(for zones that aren't visible off the local network), but don't want to 
accept 10.x.x.x addresses from anyone outside the network.

It may be a contrived example.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 19 Feb 2007 16:36:24 +0100

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Feb 2007 20:16:42 +0000

> It may be a contrived example.

i don't know if it's contrived.  i do know that i'm comfortable with the idea
that this configuration Would Not Work By Default.  if someone wants to use
private address space for DNS work, they should have to run an extra knob.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Feb 2007 20:16:42 +0000

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 11:01:30 +0800

>I fail to see how changing -- I'd say defining -- the default behaviour of
>a name server in this way could possibly be a protocol issue.

Being that the name server is the speaker of the protocol, that is 
true definition of the protocol, not the document.  Setting a default 
behavior is
effectively setting the basic form of the protocol.

>ISTR 40-60% of root server traffic would go away if people using 
>1918 addressing configured their name servers properly.

I would have thought that this would be cleaned up by BCP38 (or so).

>IMO this WG shouldn't wash its hands of this problem, claiming its a protocol
>issue and not an operational one. Which is what you appear to suggesting Ed.
>I hope not.

It isn't a protocol issue, which is why I'm questioning changes to 
the configuration of the protocol elements.

I haven't been convinced that this is an operational issue either, 
other than being what I'd label a mistake.

>>exposed as an address for a nameserver.
>
>It is.

I don't want to seem as leveling an insult, but this sort of response 
is just what is wrong with the level of discourse in the IETF. 
Claiming it is a problem is not convincing to someone like me that 
does not see the problem.

>>Second, let's talk about the severity, and is there some real threat to
>>others if someone does this.
>
>There is.

Ditto.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 11:01:30 +0800

Ditto.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 11:14:43 +0800

>get might give you some information about their network topology, e.g.

So, put in "myzone.example NS ns1.myzone.example." and 
"ns1.myzone.example A 10.0.0.1" and send out phishing spam causing a 
lookup on www.myzone.example.

If I click on the link, my local recursive server will be referred to 
ns1.myzone.example.  The next query ought to go to the local 10.0.0.1 
or at worst the border router.

What timing is going on?  Who's measuring?  I don't get this.

Or are you saying that the iterating server is accepting outside queries?

>exchanges via the tunnel.

There was a time when I worked in a place that looked at such 
exercises.  That's a security design issue.  I.e., if you have a 
bunch of machines that are not supposed to be able to send 
information out then you shouldn't have any means by which they can. 
Air gap, or some other theory application of multi-level security.

Then again, what does this have to do with an A record of an NS being RFC 1918?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 11:14:43 +0800

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 11:20:46 +0800

At 20:16 +0000 2/19/07, Paul Vixie wrote:

>if someone wants to use

Why?

Why make it hard to do something right?

Why is this a DNS issue?  Why use the DNS to make a statement on the 
use of RFC 1918 space?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 11:20:46 +0800

Why?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Feb 2007 05:00:23 +0000

> Why make it hard to do something right?

because the default is for ambiguous addresses to leak into places where
they make no sense.  similarly, rfc 1918 source addressed ip packets should
not be able to escape their routing domain by default.

> Why is this a DNS issue?  Why use the DNS to make a statement on the use of
> RFC 1918 space?

it's everybody's problem and every protocol's and service's problem.  in
dns, it looks like A RR's and so that's where i'm proposing to filter it.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Feb 2007 05:00:23 +0000

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 15:20:42 +0800

>not be able to escape their routing domain by default.

The addresses are "private" not "ambiguous."  Calling them as such 
makes them sound evil.  Is this meant to be a debate on the utility 
of RFC 1918 or on operational issues with DNS?  If the routing layer 
fails to live up to the standards for that, it needs to be fixed.

>dns, it looks like A RR's and so that's where i'm proposing to filter it.

You can alter your implementation to serve your user base.  But so 
long as there are standard ways to properly use RFC 1918 space, I 
would hope that there are tools to available to do that.

In other venues I have held a theme that if a protocol is often used 
incorrectly, the problem lay with the protocol as opposed to blaming 
this all on "dumb" or clueless users.  If there are problems with the 
protocol involved, that is where the fixes should happen.  If you 
start throwing hacks into the DNS to solve routing issues, you will 
someday find that the architecture of the Internet is no longer a 
modular system and just a tangled mess.

I still fail to be convinced that a name server with a RFC 1918 
address is a threat to the stability of DNS.  There are times when it 
can be done on intent and properly managed.  How prevalent is it 
mistakenly done?  When it happens, does the DNS (or significant 
portions) go dark?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 15:20:42 +0800

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Feb 2007 10:30:23 +0000

On Feb 20, 2007, at 07:20, Edward Lewis wrote:

> The addresses are "private" not "ambiguous."

No Ed, they're ambiguous. Paul's right. Consider two companies each  
of whom use 10/8 on their intranets.
They set up a joint venture and interconnect their nets. Whose 10/8  
is telling the truth for some 10/8 address and which one is lying?  
What goes into the DNS? Let's say they use a common 10/16 for the  
joint venture. If someone's in that /16, which (parts of) 10.in- 
addr.arpa do they resolve against for other parts of the network?
> would hope that there are tools to available to do that.

What I think we're trying to achieve here is define an element of   
the "standard way to properly use RFC 1918 space".

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Feb 2007 10:30:23 +0000

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 18:52:43 +0800

At 10:30 +0000 2/20/07, Jim Reid wrote:

>No Ed, they're ambiguous. Paul's right. Consider two companies each of whom
>use 10/8 on their intranets.
>They set up a joint venture and interconnect their nets. Whose 10/8 is
>telling the truth for some 10/8 address and which one is lying? What goes
>into the DNS? Let's say they use a common 10/16 for the joint venture. If
>someone's in that /16, which (parts of) 10.in-addr.arpa do they resolve
>against for other parts of the network?

"Truth" and "lying" ?  No, it's a conflict that needs to be part of 
the integration of the two companies.  There are people whose job is 
to iron this stuff out.  It's not as dramatic as "truth" and "lies." 
It's simply a cost of doing business.

If it's ambiguous that is distasteful, let's recommend a ban on 
putting anycasted IP addresses in DNS.  Or ban multi-homed (as you 
can't really tell anycast and multi-homing apart) addresses too.

>the "standard way to properly use RFC 1918 space".

Which is what this thread has morphed into.  Refining RFC 1918 is not 
in the charter of DNSOP however.  How does this come back to DNS 
operations?

If the answer is to recommend that NS records don't point to (servers 
with) RFC 1918 space, you are recommending that anyone using RFC 1918 
space go through hoops to get DNS working.  Getting any consensus on 
this will be as easy as that document on "publishing unusable 
addresses."  (Unusable to whom?)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Feb 2007 18:52:43 +0800

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Feb 2007 11:58:50 +0100

On Tue, Feb 20, 2007 at 10:30:23AM +0000,
 Jim Reid <[email-masked]> wrote 

> is telling the truth for some 10/8 address and which one is lying?

This is a well-known problem with RFC 1918, it is one of the reasons
behind RFC 3879, and it has *nothing* to do with the DNS and is
off-topic here.

If you want to make it a DNS issue, use ".local" instead of RFC 1918
IP addresses :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Feb 2007 11:58:50 +0100

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Feb 2007 11:16:48 -0500

> of whom use 10/8 on their intranets.

Surely, to the extent they're ambiguous, they're ambiguous by design.
RFC 1918 addresses are supposed to have local scope.  If you have
changed the meaning of "local" without resolving the conflicts in the
scope of two former meanings of "local", that's an operator error.

If what people are saying is, "RFC 1918 addresses are bad because they
leak past the local boundaries sometimes," fine.  I have to agree with
Ed, though, that hacking up the DNS to solve a problem that is not
strictly a DNS issue is a mistake.  It might be, however, that
guidelines for routing or for how to connect RFC 1918-addressed hosts
to other hosts are needed.  Those don't seem to be DNS issues, though.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Feb 2007 11:16:48 -0500

A

---

From: Daniel Senie <[email-masked]>
Date: Tue, 20 Feb 2007 12:27:33 -0500

>to other hosts are needed.  Those don't seem to be DNS issues, though.

DNS server software generally ships with a config file. In the case 
of BIND, it ships with a config that provides a caching server, at 
least on most distributions of Linux and whatnot.

As I've watched this whole discussion develop, I've been thinking 
"why are people so polarized over having the DNS server software 
packages ship with a default config file that limits leakage of RFC 
1918 addresses?"

I see no problem with a starting config that provides such limits as 
ignoring packets to/from RFC 1918 addresses and passing of RRs that 
contain RFC 1918 addresses. This won't preclude anyone with 1/2 a 
clue from configuring the software to more fully reflect their needs. 
This is an issue of doing something in the default case that will 
benefit the worldwide network.

A similar example is the sendmail package distributed with some 
flavors of Linux (perhaps with other systems too) which only listens 
to 127.0.0.1 by default, does not relay mail for other machines, etc.

The POINT we should be agreeing on is that the example config file, 
the default config file or whatever, should be well crafted to avoid 
unnecessary noise on the Internet. I see no reason for the underlying 
code in BIND or any other DNS server to be altered to behave differently.

The network's grown over the years, and isn't the friendly place it 
once was. Not everyone implementing servers understands the 
implications of default configurations that might allow propagation 
of attacks. From time to time we need to re-evaluate this. Some years 
ago we altered RFC 1812 (Router Requirements) with a subsequent 
document to change a default (directed broadcast) because we found it 
was an attack vector, and most of the time people didn't need the 
feature. Users who need it can turn it back on. The choice of 
defaults, ESPECIALLY those which are simply a sample, default or 
recommended starting point config should not result in the world 
ending, and may just be beneficial.

Please take a few minutes BEFORE you reply to this or other emails on 
this thread, think about what is really being discussed, then flame away.

Dan

---

From: Daniel Senie <[email-masked]>
Date: Tue, 20 Feb 2007 12:27:33 -0500

Dan

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Feb 2007 18:50:44 +0000

> packages ship with a default config file that limits leakage of RFC 

There may have been some confusion about the meaning of "default".

When I hear that word, I assume we're talking about the default behavior
of the name server--what it does when the behavior is not specified in the
config file.  Changing that sort of thing has alarming and unexpected
effects on people who schlep their existing named.conf files onto new
systems and expect them to keep working, and so it should only be
undertaken cautiously, and it's natural that you'd get pushback.

Shipping with a default config file, which *overrides* the system defaults
in some socially-appropriate manner, is totally different.  I'd be a lot
more open to that, personally.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Feb 2007 18:50:44 +0000

---

From: [email-masked]
Date: Tue, 20 Feb 2007 23:14:46 +0000

> making policy decisions based on that?  (sounds Incredibly Dangerous.)

	future of the DNS there Paul.  The natural growth of local policy.
	(fwtw, i think Ed is right - the problem is conflating the protocol
	 w/ implementaitons artifacts)

--bill

---

From: [email-masked]
Date: Tue, 20 Feb 2007 23:14:46 +0000

--bill

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Feb 2007 10:46:24 +0100

On Tue, Feb 20, 2007 at 06:50:44PM +0000,
 Evan Hunt <[email-masked]> wrote 

> There may have been some confusion about the meaning of "default".
...
> Shipping with a default config file, which *overrides* the system
> defaults in some socially-appropriate manner, is totally different.
> I'd be a lot more open to that, personally.

I am not sure that there is a difference. For me, "default" is "the
behaviour you get when you do the absolute minimum of work", which is,
for most Unix, typing "aptitude install bind" or "emerge bind" or
"pkg_add bind". For most Unix, things "just work" after that and many
sysadmins will not go further.

The fact that the default is in the code or in the installed config
file seems irrelevant to me.

Which means, BTW, that the "default BIND behavious" may not be choosen
by ISC, but by Debian, Gentoo or FreeBSD.

(The good thing about config files is that you can put comments in
them, such as "uncomment this only if you know what you are doing".)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Feb 2007 10:46:24 +0100

...

---

From: Robert Story <[email-masked]>
Date: Wed, 21 Feb 2007 09:40:42 -0500

>> > 		server 192.168.0.0/16 { bogus yes; };  

PV> > I'm possibly confused. The scenario I was thinking of seems to involve two
PV> > nameservers on the same 10.x.x.x network that want to point to each other
PV> > (for zones that aren't visible off the local network), but don't want to
PV> > accept 10.x.x.x addresses from anyone outside the network.
PV> 
PV> i don't know if it's contrived.  i do know that i'm comfortable with the idea
PV> that this configuration Would Not Work By Default.  if someone wants to use
PV> private address space for DNS work, they should have to run an extra knob.

I don't agree with you in this case. If the server line noted above are
the default (which I support), I think there should also be an exception
for the listening IP subnet(s)/localnets. eg.

	server localnets { bogus no; };

Of course, there is also a difference between packets received from
outside the local net and inside. A local ip from a local server is
fine; the same address from an external server is suspect.

---

From: Robert Story <[email-masked]>
Date: Wed, 21 Feb 2007 09:40:42 -0500

---

From: Paul Vixie <[email-masked]>
Date: 21 Feb 2007 16:39:36 +0000

This change-of-default is analagous to the change to limit recursion to
the local network.  This change will break many working configurations,
but the danger of open recursive nameservers is so high that the cost of
having a lot of configurations stop working after a software upgrade is
bearable.

So it is, in my view, in the case of leaking RFC 1918 addresses.  Yes, it
will mean you can't always copy a config file and get expected behaviour.
Yes, it will break working configurations after a software upgrade.  But,
for the good of the internet community, we have to be willing to do the
"tough love" thing from time to time.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: 21 Feb 2007 16:39:36 +0000

---

From: Evan Hunt <[email-masked]>
Date: Wed, 21 Feb 2007 17:20:31 +0000

> "pkg_add bind".

For some sysadmins, that's the absolute minimum of work.  For others, the
absolute minimum is to take their existing named.conf and zone files from a
running server and drop them onto a new system with no modification.  If
you've changed the _intrinsic_ default behavior, then their nameserver
won't work anymore; they'll have to edit their files to add new directives
to bring the original behavior back.  This will make them grumpy.

But if whoever does the packaging provides a default config file (or a
suite of them to choose from, perhaps), without altering the intrinsic
behavior of named, that satisfies both kinds of sysadmin.

---

From: Evan Hunt <[email-masked]>
Date: Wed, 21 Feb 2007 17:20:31 +0000

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Feb 2007 10:51:22 -0800

On Feb 21, 2007, at 9:20 AM, Evan Hunt wrote:

>
>> I am not sure that there is a difference. For me, "default" is  
>> "the behaviour you get when you do the absolute minimum of work",  
>> which is, for most Unix, typing "aptitude install bind" or "emerge  
>> bind" or "pkg_add bind".
>
> For some sysadmins, that's the absolute minimum of work.  For  
> others, the absolute minimum is to take their existing named.conf  
> and zone files from a running server and drop them onto a new  
> system with no modification.  If you've changed the _intrinsic_  
> default behavior, then their nameserver won't work anymore; they'll  
> have to edit their files to add new directives to bring the  
> original behavior back.  This will make them grumpy.
>
> But if whoever does the packaging provides a default config file  
> (or a suite of them to choose from, perhaps), without altering the  
> intrinsic behavior of named, that satisfies both kinds of sysadmin.

By defining something like:
  allow-private-only-from {...}

could then be used to setup a filter with undefined name servers.

The "new" default config file could then include this statement  
without any name servers listed.  This would not "break" systems  
upgraded that use prior configuration files, but new installations  
might need to comment out this configuration or fill in the permitted  
servers.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Feb 2007 10:51:22 -0800

-Doug

---

From: Florian Weimer <[email-masked]>
Date: Thu, 22 Feb 2007 17:42:05 +0100

> the fix to that (for once).

The risk is that you accidentally add an uncooperative name server to
your NS set.  Mistyping addresses in glue records or name server names
is probably a more relevant source of such potential badness than
deliberately added RFC 1918 addresses.  (I'm not sure how to
automatically detect such lame delegations, based on static data.
Suggestions welcome.)

And yes, DNSSEC would fix this indeed.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 22 Feb 2007 17:42:05 +0100

---

From: Kenji Rikitake <[email-masked]>
Date: Fri, 23 Feb 2007 09:39:56 +0900

In the message <[email-masked]>
dated Wed, Feb 21, 2007 at 04:39:13PM +0000,
> "tough love" thing from time to time.

All I can say is that I support to have such a configuration file
provided in a BIND distribution (I don't know what is the *best* choice,
but the Mark Andrews' one seems to me a good choice).  

Leaking RFC1918 addresses has been a chronic problem on the global
Internet operation, and I welcome a proposal to reduce the chance of
leakage.  I think it's time for the sysadmins to learn a new thing.

// Kenji Rikitake

---

From: Kenji Rikitake <[email-masked]>
Date: Fri, 23 Feb 2007 09:39:56 +0900

// Kenji Rikitake