Re: [DNSOP] A practical solution for ISP-level support of the reverse DNS tree for IPv6
On Sep 3, 2009, at 6:37 PM, Mark Andrews wrote:
First what DoS that doesn't exist today? Updates already get sent
to the ISP's {IN-ADDR,IP6}.ARPA servers.
If you do prefix delegation, you're delegating typically 64 bits of
address space. If you allow your customer to do arbitrary DNS
updates to the reverse tree for the entire /64, that could wind up
being a tremendous amount of data. So on the one hand, you're
opening yourself up to the potential for a buggy client to cause
operational problems.
And on the other hand, what makes DoS attacks work is that you have
some resource that people really care about, and you are able to
exhaust it by sending too many queries to it. One really great
defense against DoS is distribution of load. So delegating the
reverse tree for a customer's zone to the customer's equipment
protects against DoS that way.
Secondly of CPE equipement can automate this so can a ISP so there
isn't a bad configuration issue.
The problem is that I've never had an ISP that would actually populate
the reverse tree based on hints from the client, despite the fact that
this technology has existed for over a decade. I know there are ISPs
out there who do it, because I've worked with them in getting it
working. But in general, ISPs don't do this.
Thirdly I've already presented two different authentication methods
both of which have working implementations. A third is to define
how to use the public key associated with a CGA's to sign a update.
This shouldn't be too hard.
I think CGA is a viable solution, but it's a *lot* harder to set up
than just delegating the tree and insisting that the customer take
care of it if they care to.
Delegating to the CPE leads to a single point of failure. If the
ISP automatically slaved the zones it delegates to the CPE this
problem would go away. This would require the ability to tell the
CPE what other nameservers to put in the NS RRset. The CPE device
would process the UPDATEs and the ISP would provide the redunancy
required.
A single point of failure in this case isn't an issue: if your
residential gateway dies, nobody's going to be querying your PTR
records, because you're not going to be communicating with anyone.
If we were talking about A records, I'd agree with you, but for PTR
records this is really a non-issue. I don't see ISP-based slaving of
zones as a viable thing to do, for the same reason that I don't think
ISPs will ever correctly maintain the PTR tree for clients.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A practical solution for ISP-level support of the reverse DNS tree for IPv6
In message 63fd8b00-b74f-465e-95c8-129a69f52...@nominum.com, Ted Lemon writes
:
On Sep 3, 2009, at 6:37 PM, Mark Andrews wrote:
First what DoS that doesn't exist today? Updates already get sent
to the ISP's {IN-ADDR,IP6}.ARPA servers.
If you do prefix delegation, you're delegating typically 64 bits of
address space.
/56 should be typical for homes
/48 should be typical for businesses
If you allow your customer to do arbitrary DNS
updates to the reverse tree for the entire /64, that could wind up
being a tremendous amount of data. So on the one hand, you're
opening yourself up to the potential for a buggy client to cause
operational problems.
The size of the name space has NOTHING to do with it. If
I have 1 name I can add billions of records at that name.
And on the other hand, what makes DoS attacks work is that you have
some resource that people really care about, and you are able to
exhaust it by sending too many queries to it. One really great
defense against DoS is distribution of load. So delegating the
reverse tree for a customer's zone to the customer's equipment
protects against DoS that way.
Pure FUD.
Secondly of CPE equipement can automate this so can a ISP so there
isn't a bad configuration issue.
The problem is that I've never had an ISP that would actually populate
the reverse tree based on hints from the client, despite the fact that
this technology has existed for over a decade. I know there are ISPs
out there who do it, because I've worked with them in getting it
working. But in general, ISPs don't do this.
Which is basically because ISP's had to work around a problem
before there was technology for a solution and they havn't
rethought the problem since. Additionall the solution was
designed when residential customers dialed up over the PSTN
so there was not stability in the reverse space. The solution
won't work for IPv6 without specialised servers so they MUST
rethink the issue.
ISP's do support customer generated reverse zones for their
commercial customers. It really isn't that hard to do it
for all customers. It's just inertia that has stopped it.
Thirdly I've already presented two different authentication methods
both of which have working implementations. A third is to define
how to use the public key associated with a CGA's to sign a update.
This shouldn't be too hard.
I think CGA is a viable solution, but it's a *lot* harder to set up
than just delegating the tree and insisting that the customer take
care of it if they care to.
All of these can be made very easy.
Delegating to the CPE leads to a single point of failure. If the
ISP automatically slaved the zones it delegates to the CPE this
problem would go away. This would require the ability to tell the
CPE what other nameservers to put in the NS RRset. The CPE device
would process the UPDATEs and the ISP would provide the redunancy
required.
A single point of failure in this case isn't an issue: if your
residential gateway dies, nobody's going to be querying your PTR
records, because you're not going to be communicating with anyone.
Really? Lots of log processing is done in batches.
If we were talking about A records, I'd agree with you, but for PTR
records this is really a non-issue. I don't see ISP-based slaving of
zones as a viable thing to do, for the same reason that I don't think
ISPs will ever correctly maintain the PTR tree for clients.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A practical solution for ISP-level support of the reverse DNS tree for IPv6
On Sep 7, 2009, at 6:52 PM, Mark Andrews wrote: /56 should be typical for homes /48 should be typical for businesses I don't think this is germane to the discussion. My point in mentioning /64 was simply that if you go narrower than that, important things break, so it's a pretty good number to assume as an absolute minimum. If you allow your customer to do arbitrary DNS updates to the reverse tree for the entire /64, that could wind up being a tremendous amount of data. So on the one hand, you're opening yourself up to the potential for a buggy client to cause operational problems. The size of the name space has NOTHING to do with it. If I have 1 name I can add billions of records at that name. True, and with an IPv4 delegation I can have a filter that prevents you from adding names that don't make sense, stopping that particular failure mode. But there is no filter that could similarly disallow an excessive number of names in an IPv6 delegation. And on the other hand, what makes DoS attacks work is that you have some resource that people really care about, and you are able to exhaust it by sending too many queries to it. One really great defense against DoS is distribution of load. So delegating the reverse tree for a customer's zone to the customer's equipment protects against DoS that way. Pure FUD. ? The problem is that I've never had an ISP that would actually populate the reverse tree based on hints from the client, Which is basically because ISP's had to work around a problem before there was technology for a solution and they havn't rethought the problem since. No, that's not the case at all. The technology I'm talking about predates the existence of most of the really big ISPs, and there are ISPs that have been doing DNS updates right for over a decade. The problem is a lack of motivation to implement, not a lack of working technology. ISP's do support customer generated reverse zones for their commercial customers. It really isn't that hard to do it for all customers. It's just inertia that has stopped it. Do they do it with DDNS, or with web forms? The only commercial support for the reverse tree that I know of for sub-class-C subnets is done with web forms. A single point of failure in this case isn't an issue: if your residential gateway dies, nobody's going to be querying your PTR records, because you're not going to be communicating with anyone. Really? Lots of log processing is done in batches. Sure, and PTR queries can always fail. There is no way to guarantee that PTR queries will succeed when processing logs, no matter what solution an ISP implements. An auditing mechanism that depends on the PTR tree is not valid. Any mechanism necessary for interoperation that fails in the absence of a PTR record is invalid. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A practical solution for ISP-level support of the reverse DNS tree for IPv6
In message f4529f1d-1a2f-48be-bf7c-e06419c07...@nominum.com, Ted Lemon writes : On Sep 7, 2009, at 6:52 PM, Mark Andrews wrote: /56 should be typical for homes /48 should be typical for businesses I don't think this is germane to the discussion. My point in mentioning /64 was simply that if you go narrower than that, important things break, so it's a pretty good number to assume as an absolute minimum. If you allow your customer to do arbitrary DNS updates to the reverse tree for the entire /64, that could wind up being a tremendous amount of data. So on the one hand, you're opening yourself up to the potential for a buggy client to cause operational problems. The size of the name space has NOTHING to do with it. If I have 1 name I can add billions of records at that name. True, and with an IPv4 delegation I can have a filter that prevents you from adding names that don't make sense, stopping that particular failure mode. But there is no filter that could similarly disallow an excessive number of names in an IPv6 delegation. And on the other hand, what makes DoS attacks work is that you have some resource that people really care about, and you are able to exhaust it by sending too many queries to it. One really great defense against DoS is distribution of load. So delegating the reverse tree for a customer's zone to the customer's equipment protects against DoS that way. Pure FUD. ? The problem is that I've never had an ISP that would actually populate the reverse tree based on hints from the client, Which is basically because ISP's had to work around a problem before there was technology for a solution and they havn't rethought the problem since. No, that's not the case at all. The technology I'm talking about predates the existence of most of the really big ISPs, and there are ISPs that have been doing DNS updates right for over a decade. The problem is a lack of motivation to implement, not a lack of working technology. Residential was basically dialup for a long time. This has shifted to cable, dsl and wireless which are essentially always on technologies. ISP's do support customer generated reverse zones for their commercial customers. It really isn't that hard to do it for all customers. It's just inertia that has stopped it. Do they do it with DDNS, or with web forms? The only commercial support for the reverse tree that I know of for sub-class-C subnets is done with web forms. Which is a matter of tools which is what we are talking about developing. It isn't that hard to make a update tool that works with RFC 2317 style delegations but you don't really need have a delegation if you are doing dynamic updates in the first place. nsupdate was designed to allow the CNAME to be removed. A slightly different tool is needed to follow the CNAME and construct a PTR using the CNAME's rdata as the ownername. This can be done outside of nsupdate by whatever is translating the IP address into the in-addr.arpa/ip6.arpa name. DNAME's are likely to be in the ip6.arpa which have the same issues. A single point of failure in this case isn't an issue: if your residential gateway dies, nobody's going to be querying your PTR records, because you're not going to be communicating with anyone. Really? Lots of log processing is done in batches. Sure, and PTR queries can always fail. There is no way to guarantee that PTR queries will succeed when processing logs, no matter what solution an ISP implements. An auditing mechanism that depends on the PTR tree is not valid. Any mechanism necessary for interoperation that fails in the absence of a PTR record is invalid. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A practical solution for ISP-level support of the reverse DNS tree for IPv6
In message e2dcddf0-5aba-4bb0-aaff-0113cea4a...@nominum.com, Ted Lemon writes
:
On Sep 3, 2009, at 11:58 AM, Lee Howard wrote:
Education needed: how do you tell a residential user what server
will accept their dynamic PTR updates?
I think this is an unnecessarily difficult answer. Maintaining the
zones at the ISP is a recipe for DoS attacks, bad configuration, angry
phone calls from end users, and, frankly, ISPs simply not doing it
because it's too hard. The problem of authenticating the DNS updates
is another dozen miles of bad road on top of that. It's better to
delegate to the customer, and it's not that hard to do.
First what DoS that doesn't exist today? Updates already get sent
to the ISP's {IN-ADDR,IP6}.ARPA servers.
Secondly of CPE equipement can automate this so can a ISP so there
isn't a bad configuration issue.
Thirdly I've already presented two different authentication methods
both of which have working implementations. A third is to define
how to use the public key associated with a CGA's to sign a update.
This shouldn't be too hard.
Residential gateways are, in practice, almost always configured using
DHCP. For DHCPv6 prefix delegation, it would be a fairly simple
matter to set up a DNS delegation for the zone containing PTR records
for that prefix. The delegation could be to an IP address designated
by the residential gateway, which would typically be its own IP
address. The residential gateway could also present DNSSEC
information in its DHCP messages for insertion into the parent zone if
that was considered valuable.
Delegating to the CPE leads to a single point of failure. If the
ISP automatically slaved the zones it delegates to the CPE this
problem would go away. This would require the ability to tell the
CPE what other nameservers to put in the NS RRset. The CPE device
would process the UPDATEs and the ISP would provide the redunancy
required.
This sounds like a security problem, but it's not: if the residential
gateway is getting its configuration through the DHCP server, then it
is permitted both to use the delegated prefix and to control the zone
documenting the contents of that prefix. As long as the DHCPv6
transaction is acceptably secure, so is the zone delegation.
There is existing technology for populating PTR records via DHCP, and
this would work for the next-hop address to the prefix - the outward
facing IP address of the home gateway, which would be allocated via
DHCPv6. AFAIK this functionality already works on several commercial
and at least one open source DHCP implementation, and support in
DHCPv4 clients is widespread, so it's not unreasonable to think that
DHCPv6 clients would have support for it as well. I haven't checked
the Microsoft client, but I'd be surprised if it didn't do this.
Following this plan, end users who care about the reverse tree will
spend the extra money to run gateways that support the delegation; end
users who do not would have no reverse DNS. This seems like a
winning solution to me, since the incentives and effort are all placed
on the interested parties. There would be some minimal effort
required by the ISP to set this up, but it really would be pretty
minimal - for instance, it's a lot easier to get right than the
routing for prefix delegation.
Of course, this solution doesn't work for ISPs that use static
allocation, but they've bought a whole manual process anyway, so the
additional expense for them of doing this is minimal, and existing
ISPs that allocate IP addresses this way (e.g., Speakeasy in the U.S.)
in practice support maintaining the DNS this way anyway - the big
change here would be that rather than maintaining the customer's
reverse tree for them, they'd be able to delegate it.
Static is just long term dynamic.
For ISPs that do neither manual allocation nor DHCPv6, implementation
is problematic, but I don't know of any. I'd be curious to know if
anybody is aware of any alternativees for doing this that would work
in practice.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
