Subject: [dnsext] Wildcard expansion in DNS caches

From: John Levine <[email-masked]>
Date: 23 Nov 2010 22:08:22 -0000

I've been pondering how rDNS and DNSBLs will or won't work with IPv6.

Since each end user is likely to get a /64, it would be easy even if
somewhat antisocial for a host to use a different IP address for every
HTTP or SMTP conection.  Bulk mailers who think they're clever might
use that to do bounce or delivery management by IP address, and
spammers will doubtless do it both on outbound SMTP connections and
inbound HTTP payload connections to try to evade IP based filters.

It will surely be common for the whole /64 to have the same rDNS, or a
common DNSBL entry.  While it is straightforward for rDNS and DNSBL
servers to use wildcards or, in specialized BL servers, CIDR ranges,
to keep the file sizes down to something reasonable, this will be bad
news for DNS caches that will fill up with uselesly cached single use
rDNS and BL entries.

I see that there is an arcane but well documented* aspect of DNSSEC
that makes it possible for a DNS cache that has an entry synthesized
from a wildcard to use RRSIG to see what the wildcard was, and NSEC to
tell the range of names the wildcard covers, so the cache can handle
other names under the same wildcard itself, without having to contact
the authoritative server.  RFC 4035 says it would be "prudent" not to
do that, but it's not clear why.  It would certainly help mitigate the
rDNS and DNSBL cache explosion.

Do any caches do wildcard expansion?  Is anyone planning to do it?

R's,
John

* - a pleasant switch from the usual tradition

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Wed, 24 Nov 2010 12:41:34 -0500

>Do any caches do wildcard expansion?  Is anyone planning to do it?

Caches cannot do the expansion.  A cache would have to have the 
entire zone in it's memory to accurately apply the wild card rule.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John R. Levine" <[email-masked]>
Date: 24 Nov 2010 13:11:17 -0500

> Caches cannot do the expansion.  A cache would have to have the entire zone 
> in it's memory to accurately apply the wild card rule.

The authors of RFC 4035 disagree with you.  See section 4.5, particularly 
bullet 1 on page 22.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Nov 2010 14:37:30 -0400

rDNS for IPv6 is one place where DNAME is much better than wildcards,
but can still accomplish the same thing, more or less.

Recall that in IPv6, rDNS is on a nibble boundary (one hex digit).
The recipe using DNAME to pre-populate a /64 with identical data is:
At each nibble, have one "true" entry, and 15 DNAMEs pointing at the "true"
entry.

(Actually, the "true" entry is only needed at the last nibble,
i.e. the full /128 of the "real" RDATA to be used.)

So, pre-populating a /64 rDNS zone would require 16*15 DNAMEs,
plus the singleton "real" entry, or 241 entries.

This is less than pre-populating an IPv4 /24.

It also involves no further cache impact than the entries above.

Caches might have to synthesize CNAMEs for DNAME-unaware clients,
but those values don't get cached.

DNAME-unaware caches would explode with synthesized CNAMES,
which is why they should probably upgrade to DNAME-aware code.

Brian

---

From: Chris Thompson <[email-masked]>
Date: 24 Nov 2010 19:37:32 +0000

>The authors of RFC 4035 disagree with you.  See section 4.5, particularly 

Which says: yes, you could use such learned data to second-guess what
is in the rest of the zone, but it's a bloody stupid idea. "Resolvers
that follow this recommendation [i.e. not to do that] will have a more
consistent view of the namespace."

-- 
Chris Thompson
Email: [email-masked]

---

From: "John R. Levine" <[email-masked]>
Date: 24 Nov 2010 14:57:39 -0500

> consistent view of the namespace."

It's true, your view of the namespace would be less consistent, but if the 
alternative is to blow your cache out with useless entries, I would have 
to say the stupid alternative would be not to do so.  Assuming the TTLs on 
the wildcards are chosen sensibly, I don't see any reason why one would 
expect the decrease in consistency to be significant.

As Ed Lewis said two days ago:

> Since time began (for DNS), there is always something wrong somewhere. 
> The goal is a robust system, not a tightly correct system.

The suggestion to do it with DNAME is an interesting one.  I'll have to 
see if I can model the two approaches.

Regards,

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 24 Nov 2010 13:19:51 -0700

> see if I can model the two approaches.
Indeed a very interesting approach. The problem with both this and the
wildcard approach is that it fails the expectation in [RFC1912] for
forward and reverse to match.

What needs to be done to solve the rDNS in IPv6 problem is to synthesize
the mapping on the fly on the authoritative side and create some kind of
signaling mechanism between authoritative servers. This would either
require a whole new definition of wildcards or some kind of PTRPARAM /
AAAAPARAM records to tell the slave how to do the synthesis. I have some
ideas but can't really figure out how DNSSEC would work in such case.

/Stephan

---

From: "John R. Levine" <[email-masked]>
Date: 24 Nov 2010 16:33:46 -0500

>> The suggestion to do it with DNAME is an interesting one.  I'll have
>> to see if I can model the two approaches.
>>

Hmmn.  I suppose a name with 2^64 AAAA records would be pretty bulky, 
wouldn't it?   I'm more worried about DNSBLs where the forward/reverse 
problem doesn't apply.

> ideas but can't really figure out how DNSSEC would work in such case.

I can't help but wonder why, after a decade of IPv6, we're just thinking 
about these problems now.

Regards,

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Nov 2010 13:42:06 -0800

On Nov 24, 2010, at 1:33 PM, John R. Levine wrote:
> I can't help but wonder why, after a decade of IPv6, we're just thinking about these problems now.

They've been discussed before and I believe the answer has been "DDNS with online signing keys for reverse zones doing DNSSEC".

Regards,
-drc

---

From: "John R. Levine" <[email-masked]>
Date: 24 Nov 2010 16:49:04 -0500

> They've been discussed before and I believe the answer has been "DDNS 
> with online signing keys for reverse zones doing DNSSEC".

I'm a little unclear.  Is the idea that the hosts would poke their rDNS 
into the authoritative servers when they configure themselves, or DHCP 
servers would do it on their behalf, or something else?

Regards,

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 24 Nov 2010 14:38:26 -0700

Hi David,

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of David Conrad
> Sent: Wednesday, November 24, 2010 3:42 PM
> To: John R. Levine
> Cc: Stephan Lagerholm; [email-masked]
> Subject: Re: [dnsext] Wildcard expansion in DNS caches
> 
with
> online signing keys for reverse zones doing DNSSEC".

There is an RFC requirement with DDNS to commit to stable storage prior
sending an ACK back to the client. So DDNS performance is limited by the
number of disk writes your hardware can do. This is typically in the
range of a few hundreds with modern hardware. This doesn't really scale
to large service provider environments.

Additionally, how do you solve DHCP prefix delegation? How do you know
what address the client will use? How do you implement security around
this?

DDNS is just the wrong way to go.

/S

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 24 Nov 2010 14:16:51 -0800

On Wed, Nov 24, 2010 at 1:38 PM, Stephan Lagerholm
<[email-masked]> wrote:
> number of disk writes your hardware can do.

Nonsense.  Multiple transaction commits can be batched into a single disk write.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Nov 2010 18:23:57 -0400

> plus the singleton "real" entry, or 241 entries.

Slight correction - the bottommost nibble entries would have to be
CNAMEs, of course, 15 of them.

Brian

---

From: "John R. Levine" <[email-masked]>
Date: 24 Nov 2010 17:25:28 -0500

> Nonsense.  Multiple transaction commits can be batched into a single disk write.

I'd think that you could do a pretty effective DOS against the name 
service if you were planning to use a lot of addresses in your /64.  I 
realize that's not what people anticipated, but it's not hard to think of 
more or less legitimate scenarios to use a lot of IP addresses to keep 
track of a lot of sessions.  And it would be pitiful to say, well, yes, 
the bits are there, but because of our lame infrastructure, you can't use 
them.

Regards,

---

From: [email-masked]
Date: Wed, 24 Nov 2010 23:45:17 +0100 (CET)

> the bits are there, but because of our lame infrastructure, you can't use 

We've been very happy with machine generated static forward and reverse
DNS for our DHCP customers. Using DDNS for customers just because they
have an IPv6 address / prefix is not particularly interesting. As I see
it, the relevant alternatives for us are:

- Some kind of static forward and reverse mapping, presumably involving
wildcards / CNAMEs / DNAMEs.

- DNS records synthesized on the fly by name servers (as is possible
with for instance a suitable PowerDNS backend).

- No DNS entries at all for our DHCP customers.

YMMV, obviously. But DDNS is not on the table...

Steinar Haug, Nethelp consulting, [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 24 Nov 2010 16:14:06 -0700

Matthew,

> Nonsense.  Multiple transaction commits can be batched into a single
disk
> write.

There is a flip side of that coin. You will not be able to answer any
queries while you batch.

RFC 2136: When a zone is modified by an UPDATE operation, the server
must commit the change to nonvolatile storage before sending a response
to the requestor or answering any queries or transfers for the modified
zone.

/S

---

From: "John R. Levine" <[email-masked]>
Date: 24 Nov 2010 18:38:45 -0500

>> disk write.

This all sounds rather hypothetical.

Does anyone here have actual experience with DNS for IPv6 networks of 
non-toy size?  I certainly don't.

Regards,

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 24 Nov 2010 15:44:46 -0800

> There is a flip side of that coin. You will not be able to answer any

You just delay responding while you batch.  If you're limited to 100
writes per second, that's only adding 10ms of latency to your response
time.

If you can only do 100 writes and you get 500 requests, what's better?
 To answer 100 of them with minimal overhead, or to answer all 500
with an average of 5ms of extra latency?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Nov 2010 10:49:34 +1100

In message <[email-masked]>, "Ste
> DDNS is just the wrong way to go.

Given lots of enterpises do reverse dns this way today, and they
don't fall over, why do you think ISP's will fallover?  The addresses
for hosts will be relatively stable unless the ISP deliberately
forces address changes on the customers.  One can always monitor
for abuses and cut off / recommend that they run their own servers
if they exceed reasonable update rates.  A couple of counters is
all that is needed on a per zone basis.  updates and updates with
commit.

ISP do this today for customers that make huge numbers of queries.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Nov 2010 16:52:02 -0800

> number of disk writes your hardware can do.

As others have pointed out, there are ways of getting around this.

> DDNS is just the wrong way to go.

I think you may have misinterpreted my comment. I simply noted that the topic of IPv6 reverses had been brought up before (in response to John's question) and that the answer had been "DDNS". See section 7 of RFC 4472. I am not arguing it is a good answer (I always thought it introduced a few too many moving parts for ISPs to be comfortable with), merely that it has been an answer in the past.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Nov 2010 16:52:40 -0800

On Nov 24, 2010, at 1:49 PM, John R. Levine wrote:
> I'm a little unclear.  Is the idea that the hosts would poke their rDNS into the authoritative servers when they configure themselves, or DHCP servers would do it on their behalf, or something else?

Both have been suggested.  See RFC 4472 section 7.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Nov 2010 16:55:19 -0800

> There is a flip side of that coin. You will not be able to answer any

There are name servers that are multi-threaded and which can queue queries for names, deferring responses until some condition (e.g., disk writes) are met.

There are numerous arguments against using DDNS.  Performance is not one of the better ones.

Regards,
-drc

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 24 Nov 2010 18:26:11 -0700

Given that:

1. A wildcard/DNAME solution for rDNS violates RFC 1912.
2. There are many arguments against DDNS, performance might or might not be one of them.

Would it then make sense to:
1. Adopt draft-howard-isp-ip6rdns-04 so that it is ok to do nothing. (I'm not in favor for this myself)
or
2. start working on extending the DNS protocol with some type of signaling mechanism describing how Synthesize of records on the fly would look?

/S

-----Original Message-----
From: David Conrad [mailto:[email-masked]]
Sent: Wed 11/24/2010 5:55 PM
To: Stephan Lagerholm
Cc: Matthew Dempsky; John R. Levine; [email-masked]
Subject: Re: [dnsext] Wildcard expansion in DNS caches

Regards,
-drc

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 24 Nov 2010 17:48:28 -0800

> 1. A wildcard/DNAME solution for rDNS violates RFC 1912.

This argument is a red herring.  In practice, nobody cares about
forward and reverse DNS entries matching.

$ dig +short -t a secure64.com
72.167.37.13

$ dig +short -t ptr 13.37.167.72.in-addr.arpa
ip-72-167-37-13.ip.secureserver.net.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Nov 2010 02:08:15 +0000

> Date: Wed, 24 Nov 2010 14:38:26 -0700
> From: "Stephan Lagerholm" <[email-masked]>
> 

in large service provider environments, battery backed ram disks are used,
and it scales just fine, like 10K updates per second, more if you RAID it.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Nov 2010 13:29:39 +1100

> $ dig +short -t a secure64.com

You left out the linkage most applications care about.
That if you start with a address you get that address
when you lookup the name returned from the reverse zone.

getaddrinfo(getnameinfo(address)) == address

% dig +short ip-72-167-37-13.ip.secureserver.net
72.167.37.13
% 

Mark

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Nov 2010 04:44:29 +0000

> Date: Wed, 24 Nov 2010 17:48:28 -0800
> From: Matthew Dempsky <[email-masked]>
> 

this is false by obvious example.

% man 5 postconf
...
smtpd_peername_lookup (default: yes)
       Attempt to look up the remote SMTP client hostname, and verify
       that the name matches the client IP address. A client name is set
       to "unknown" when it cannot be looked up or verified, or when
       name lookup is disabled.  Turning off name lookup reduces delays
       due to DNS lookup and increases the maximal inbound delivery
       rate.

       This feature is available in Postfix 2.3 and later.
...
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 25 Nov 2010 09:23:20 +0100

> non-toy size?  I certainly don't.

I did it for a large LAN party (5000+ computers) once -- some 200
VLAN's with a /64 on each. Router had /64-prefix::1 which was in DNS 
with PTR and all, and then i made wildcards like

*.<expanded-64-prefix>.ip6.arpa. PTR some-computer-on-VLAN-234.<domain.tld>.

to address any queries for nodes on that VLAN. Worked.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Where do your SOCKS go when you lose them in th' WASHER?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Nov 2010 04:08:30 +0000

% man 5 postconf
...

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Nov 2010 12:44:33 -0500

> 1. Adopt draft-howard-isp-ip6rdns-04 so that it is ok to do nothing. (I'm not in favor for this myself)

Speaking as chair, I want to note that wherever that document might be
adopted, this WG is not it.  It makes no change to the DNS protocol.

(Speaking only personally, I'd also like to suggest that exploring the
reverse-mapping rathole yet again is not the best use of our time.
But I appreciate that others' views may be different.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Nov 2010 12:45:43 -0500

Moderator hat on.

> forward and reverse DNS entries matching.

Exploration of the details of operational practice for the DNS does
not belong on the dnsext list, please.

A

---

From: "John R. Levine" <[email-masked]>
Date: 25 Nov 2010 13:03:50 -0500

> $ dig +short -t a secure64.com

It would be more helpful if you refrained from speculating in areas with 
which you are unfamiliar.  MTAs check rDNS->DNS, not DNS->rDNS.  And yes, 
they really do.

$ dig  +short -t a  ip-72-167-37-13.ip.secureserver.net
72.167.37.13

Regards,

---

From: John Levine <[email-masked]>
Date: 26 Nov 2010 00:23:46 -0000

>if they exceed reasonable update rates.

ISPs have a lot less control over their users than enterprises do, and
the users can be very self-righteous.  Look at the absurd food fight
that ensued when Comcast did some clumsy peak shaving of their
heaviest Bittorrent users.

If an ISP has a rule that each consumer can only use N of their 2^64
IP addresses, expect a great deal of pushback, even if N is entirely
technically reasonable.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Nov 2010 12:12:00 +1100

> heaviest Bittorrent users.

Which was because Comcast failed to set expectations to match reality
in the first place.  When you live in parts of the world where the
expectations coincide with reality you don't get such fights.  This
was pointed out on numerous occasions at the time.

I get 1X G per/month 12:00-24:00 and 2X G per/month 00:00-12:00 and
if I exceed that I get throttled until the end of the month.  That
was plain and clear when I signed up for the contract.

I also get to see how much I've used in each category and how far
into the month I am for comparison.  The ISP is clearly trying to
get me to shift bulk traffic to the low period (midnight to noon)
and I update my machines during that period.

> IP addresses, expect a great deal of pushback, even if N is entirely

It's all about how it's presented.

X records free and if you exceed X records it costs you $ per/month/X
records additional records or part there of.

Z changes per/month/X records and if you exceed Z then you need to
run your own servers if you are worried about transaction rates.

Provide the ability to see where you are up to on each and customers
will self regulate.

If you are doing reverse zones one may as well do forward zones as
well.

Anyway its out there as a idea.

Another alternative is to allow delegations to those that do DDNS
already or have the ability for customers to add DNAME records. The
latter requires OS vendors to do the right thing when they see a
DNAME / CNAME and adjust the DDNS update request to take the DNAME
/ CNAME into account.

Many DDNS services operate on records and changes per month basis
so its really nothing new.   Just new for the ISPs.

Mark

---

From: "John R. Levine" <[email-masked]>
Date: 25 Nov 2010 22:54:19 -0500

> Easily solved—delegate the zone for the /64 to the customer and let them sweat it.

Sigh.  I get the impression you haven't dealt with many consumer ISP 
users.

Regards,

---

From: Florian Weimer <[email-masked]>
Date: Fri, 26 Nov 2010 08:28:14 +0000

> news for DNS caches that will fill up with uselesly cached single use

Per-address rewriting of TXT records is considered crucial by several
DNSBL operators.  This is fundamentally incompatible with wildcard
synthesis because under the current wildcard model, you cannot have a
wildcard apply to one record type, but not to another type.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John R. Levine" <[email-masked]>
Date: 26 Nov 2010 07:37:30 -0500

> wildcard apply to one record type, but not to another type.

It's true that DNSBLs often embed the IP address in the TXT record.  But 
crucial?  Given a choice between using a fixed record, and people telling 
you that they can't use your DNSBL because it blows out their cache, what 
would you do?

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Nov 2010 19:27:39 -0800

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Nov 2010 23:05:16 -0500

> Sigh.  I get the impression you haven't dealt with many consumer ISP 

Not my point at all.   My point is that if they are in the entitled 0.05% who absolutely must have things their way, delegating will actually make them much happier than letting them do DDNS.   For regular customers, you can just do DDNS.   Granted, having two choices is a pain, but if you plan for it in advance, it's probably not a very big deal.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Nov 2010 10:20:23 -0500

I would not be too worried about the effect RBLs might have on DNS
infrastructure. If they start to bust caches too often, people are going to
be implementing controls to avoid caching records from badly behaved RBLs.

Given that there are only 2^32 address bits available for the entire planet
today and given the fact that most people have no intention of mapping MAC
addresses to IP addresses in any form whatsoever, I have a real hard time
understanding why a residential user is going to be inconvenienced or upset
should they get a less than a /64.

Most will be happy with a /120 and nobody is going to actually need more
than a /96.

It is probably unwise to make too many assumptions about how people are
going to make use of allocation mechanisms. What is in the best interests of
RIPE, ARIN and so on is not necessarily what is in the best interests of the
ISPs.

What I would do is to propose that RBL maintainers adopt a different
strategy entirely. Instead of mapping the entire address in one go, map the
address in segments.

So querying at the root would specify that the default bucket interval was
maybe a /56 (or whatever the minimum allocation unit turns out to be.

In 99% of addresses that would map straight to the record.  For another 1%
of addresses there would be another record to say 'dig deeper'.

Approaches that were employed with IPv4 are going to have to be rethought
for IPv6. Well tough, you were going to have to write new code anyway.

Approaches that have the IP address in the TXT record are not going to work
with DNSSEC  and IPv6. Tough.

If you want to synthesize records on the fly then you should either write
your own protocol or look to mechanisms such as DNSCurve and/or DPLS

On Thu, Nov 25, 2010 at 10:54 PM, John R. Levine <[email-masked]> wrote:

> Sigh.  I get the impression you haven't dealt with many consumer ISP users.
>
>
> Regards,

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Nov 2010 10:31:13 -0800

On Nov 26, 2010, at 10:20 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:

> Given that there are only 2^32 address bits available for the entire planet today and given the fact that most people have no intention of mapping MAC addresses to IP addresses in any form whatsoever, I have a real hard time understanding why a residential user is going to be inconvenienced or upset should they get a less than a /64. 

You can't do CGA and SEND without a /64 or better.  This would be a deal-breaker to me.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John R. Levine" <[email-masked]>
Date: 26 Nov 2010 17:52:45 -0500

> be implementing controls to avoid caching records from badly behaved RBLs.

If bad guys are going to pick a new IPv6 address for every message, how 
are DNSBLs supposed to deal with it?  The DNSBLs I know keep their 
internal data as CIDR ranges, but there's no way to publish them that way.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Nov 2010 18:05:53 -0500

> internal data as CIDR ranges, but there's no way to publish them that 

Why not?

A

---

From: Paul Vixie <[email-masked]>
Date: Sat, 27 Nov 2010 00:34:22 +0000

> Date: 26 Nov 2010 17:52:45 -0500
> From: "John R. Levine" <[email-masked]>
> 
> If bad guys are going to pick a new IPv6 address for every message,
> how are DNSBLs supposed to deal with it?  The DNSBLs I know keep their

rpz format 2 will have that.  still tinkering with the exact zone syntax.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: John Levine <[email-masked]>
Date: 27 Nov 2010 00:58:45 -0000

>rpz format 2 will have that.  still tinkering with the exact zone syntax.

That could certainly help for zones that change slowly, although I
expect DNSSEC aware caches that did wildcard expansion would help more
since that won't need to arrange for AXFR or IXFR access.

There's two kinds of DNSBLs, policy and evidence.  The policy DNSBLs like
the SBL tend to list largish CIDR ranges based on analyses of the policies
of the block owner.  The evidence DNSBLs tend to list single IPs based on
evidence of spam, zombies, or whatever.

The most widely used evidence DNSBL is probably the CBL, which has
about 7 million entries, and is updated about every 15 minutes, based
on what arrives in their spam feeds.  At that size it's probably OK,
but I worry what happens when bad guys use a different IP for each
message.  IXFR at that rate would be a bit much, although it's possible
that listing and querying by /64 could keep things under control.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Nov 2010 22:23:56 -0500

What is a deal breaker for you is almost certainly incomprehensible to the
average user.

Your use is not going to cause potential issues here. It is what the ISPs
decide to do to support the average user that may.

In the event I suspect that many ISPs will give end users a /128 just like
they gave out a /32 with IPv4 and demanded more money for additional
addresses.

Attempts to 'prevent' this outcome by limiting functionality merely play
into the ISPs hands and encourage this behavior.

On Fri, Nov 26, 2010 at 1:31 PM, Ted Lemon <[email-masked]> wrote:

> > Given that there are only 2^32 address bits available for the entire
> planet today and given the fact that most people have no intention of
> mapping MAC addresses to IP addresses in any form whatsoever, I have a real
> hard time understanding why a residential user is going to be inconvenienced
> or upset should they get a less than a /64.
>

---

From: Paul Vixie <[email-masked]>
Date: Sat, 27 Nov 2010 04:16:29 +0000

> Date: 27 Nov 2010 00:58:45 -0000
> From: John Levine <[email-masked]>
> 
> >> how are DNSBLs supposed to deal with it?  The DNSBLs I know keep
> >> their internal data as CIDR ranges, but there's no way to publish
> >> them that way.
> >
> That could certainly help for zones that change slowly, ...

no, really.  my own personal dnsbl is robotically fed by nsupdate dozens
to hundreds and under load testing thousands of updates per second.  bind9
is able to turn these into NOTIFY and IXFR (signed by TSIG) in a way that
all of the zone's secondary servers are only a few seconds behind at any
given moment.  any story showing DNSIND (ixfr-notify-dynupd) being useful
only for slow-changing zones is total fiction.

see <http://sciencelinks.jp/j-east/article/200422/000020042204A0728684.php>
for publication info on a paper about this.  the paper is no longer online
at that site but i'll send a PDF to anyone who asks.

> although I expect DNSSEC aware caches that did wildcard expansion
> would help more since that won't need to arrange for AXFR or IXFR
> access.

i agree, and moreover i think that wildcard expansion and rrset synthesis
should always have been done in the full recursive server and not in the
authority server.  i would love to see an applicability statement for NSEC
which explains how this can be done.  (i don't think NSEC3 will allow it.)
i think it would take a new signal bit from recursive to authoritative, of
the nature of "don't synthesize for me, i'll do it, just send me wildcard
proofs and i'll work it out."

> There's two kinds of DNSBLs, policy and evidence.  The policy DNSBLs
> like the SBL tend to list largish CIDR ranges based on analyses of the
> policies of the block owner.  The evidence DNSBLs tend to list single
> IPs based on evidence of spam, zombies, or whatever.
> 
> message.  IXFR at that rate would be a bit much, although it's
> possible that listing and querying by /64 could keep things under
> control.

note that i'd love to know if the cbl guys have ever tried bind9 with
ixfr-from-differences, that is, generate a new zone once a minute from
cron, tell bind9 to reload it, and let bind9 generate the ixfr deltas.

but you're right, for ipv6 it's going to generally be /64's which are
listed, not /128's, since the low order 64 bits are under bad guy control.
(that's not due to limitations of dns, it's just security architecture.)
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: John Levine <[email-masked]>
Date: 27 Nov 2010 04:45:58 -0000

>given moment.

Hmmn.  How big is it?

>cron, tell bind9 to reload it, and let bind9 generate the ixfr deltas.

I'm pretty sure they use rbldnsd.  We've been scratching our heads for
a while about what to do to rbldnsd for IPv6 BLs.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sat, 27 Nov 2010 04:51:34 +0000

> Date: 27 Nov 2010 04:45:58 -0000

currently it's about 45000 entries.  it's run in production at 350K entries,
and i've load tested it at 5M entries.

> a while about what to do to rbldnsd for IPv6 BLs.

ok, well, i'm sorry to raise a bind-specific topic on the protocol forum.
the point i was really trying to make is that DNSIND (ixfr, notify, dynupd)
has been shown to do pretty well even for fast-changing zones.  as to what
BIND can do, i should take that to a BIND specific mailing list.  oops.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Nov 2010 22:58:13 -0600

On Nov 26, 2010, at 9:23 PM, Phillip Hallam-Baker wrote:
> Attempts to 'prevent' this outcome by limiting functionality merely play into the ISPs hands and encourage this behavior. 

Attempts to help the functionality to proliferate, on the other hand, might make it so that not providing it will be a deal breaker for more people than just me.   At this point, not having IPv6 addresses isn't a dealbreaker for anyone I'm aware of, so how could the lack of a /64 be a dealbreaker?

---

From: Brian Dickson <[email-masked]>
Date: Sat, 27 Nov 2010 01:59:45 -0400

> proofs and i'll work it out."

I think it boils down to this: if (and only if) it is possible for the
recursive server to synthesize
an answer (and proof) which validates correctly, then it may do so.

Basically, the recursive server would follow the same rules as the
authority server, until it failed to find
the needed data, at which point it punts the query to the authority
server (which by definition must
return all the necessary records).

The recursive server doesn't really need to signal anything to the
authority server.
Any failed attempt (to synthesize data) needs to fall back to the
authority server, at which point the needed
data will be received (and cached).

The RRs that would need to be present in the cache, to synthesize an answer are:
- the wildcard RR plus RRSIGs
- suitable NSEC/NSEC3 records and RRSIG for the wildcard proof.

For NSEC, it's very straightforward, given that the owner names match
1:1 to the covered names.

For NSEC3, the original query name would need to be hashed, and a
covering NSEC3 record found.
But other than that, it's the same logic.

I think the main issue is the concern over requiring all NSEC (or
NSEC3 and NSEC3PARAM) records
to be time-synchronous, and for the cache to somehow know about
changes to the zone signing events.

Here's what isn't clear to me - are the two kinds of zone signing
actions independent (orthogonal)?
The actions are:
- generating NSEC or NSEC3 records over the zone
- signing the RRsets in the zone (which could include NSEC/NSEC3 RRs)

A cache that does wildcard synthesis would need to know about changes
to the NSEC/NSEC3 records in a zone.
Is that implicitly or explicitly signaled by any particular record,
e.g. SOA record (e.g. serial number change)?

Or is failure to bump the SN and re-sign the zone when
adding/changing/deleting zone data an operator error which is presumed
to not occur?

Is it acceptable for the TTL on the SOA to determine how long a cache
can synthesize wildcard answers (presuming it is able), before
checking the SOA SN again?

Brian

---

From: [email-masked]
Date: Sat, 27 Nov 2010 10:38:36 +0100 (CET)

> decide to do to support the average user that may.

Not getting on the net at all is definitely a "potential issue".

> they gave out a /32 with IPv4 and demanded more money for additional

Maybe so - however, it's going to be far easier for the ISPs to support
their users if they hand out more normal sizes, like /56.

> into the ISPs hands and encourage this behavior.

Normal competition between the ISPs will probably take care of this.
ISPs giving end users /128 are simply going to have a more difficult
(and resource intensive/expensive) job getting this to work.

We'll be giving out /56 as the default IPv6 prefix to our users, for
whatever it's worth.

---

From: John Levine <[email-masked]>
Date: 27 Nov 2010 14:39:05 -0000

>checking the SOA SN again?

Why wouldn't it use the usual cache rules?  The NSEC, RRSIG, and
wildcard record all have TTLs (which should, I presume, be the same.)

You'd use the SOA and NSEC to synthesize NXDOMAIN, again using the usual
cache rules.

R's,
John

---

From: Florian Weimer <[email-masked]>
Date: Mon, 29 Nov 2010 17:54:19 +0000

* John R. Levine:

> It's true that DNSBLs often embed the IP address in the TXT record.
> But crucial?

I'm just relaying the feedback I got when I tried to sign one of the
larger DNSBL zones.  I was told I couldn't apply the wildcard trick
because it removed important information from the TXT records.

(I would certainly prefer if we could use wildcards.)