Re: [DNSOP] new Questions...
Date: Thu, 03 Sep 2009 06:48:21 -0700 From: Todd Glassey tglas...@earthlink.net Actually Dean - good point - the MOU was never codified in a formal contract meaning that the US Department of Commerce still formally owns the root's and so under this newly proposed cyber-control law would give the US President the legal authority to on a mere presidential order (especially a HSPD) or just a simple presidential directive can shut all - repeat ALL - of ARIN's and each of the root systems down since the US DoC still owns them. todd, please do not feed the trolls. the ietf saw fit to ban mr. anderson from this mailing list (and a few others) and he's now created his own mailing lists and added all of us to them so that he can continue posting, but that shouldn't mean i have to read his text when included by others in their replies, nor should we have threads hijacked in the ways that got mr. anderson banned in the first place. I wonder how many of the Internet-Mavens on this list have figured that out... every statement you made above is factually wrong. so, no. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00
-Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Monday, August 31, 2009 9:53 PM To: Doug Barton Cc: dnsop Subject: Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00 Windows already attempts to do UPDATE. It just does it over UDP. Switching to TCP for the UPDATE message should be trivial. I guess that's for them to decide, but certainly the protocols are there. I think I said that in the draft, too. Since this is IPv6 give each customer their own address block and corresponding reverse zone. You don't need a single big machine to do this. Would you delegate the reverse zone to CPE, or support updates on your servers? Hm, need to filter at the edge, make sure customer's don't update each other's records. Some rate limiting, maybe. Is a matching forward zone required, too? Education needed: how do you tell a residential user what server will accept their dynamic PTR updates? Lee ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00
-Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Tuesday, September 01, 2009 2:18 PM To: Doug Barton Cc: dnsop; Shane Kerr Subject: Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00 Saying IPv6 reverse DNS is not considered a practical means to determine legitimate IP address use needs to be either stated or refuted. It would probably devolve into a debate of legitimate. Maybe we could try the reverse: IPv6 is a practical means to determine useful information. What useful information is expected? I'm trying to describe the best current practice. DNS timeouts already consume a large portion of MTA resources when attempting to discover reverse DNS entries. When IPv6 forces use of positive reputations, reverse DNS entries become superfluous. Negative reputations within the IPv6 address space also seems impractical, largely due to the scale of the space involved. I agree. Is there documentable consensus on that point? Lee -Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new Questions...
Dean Anderson wrote: BTW, RFC2870 is not the authority on root server operations. The authority is found in the MoU with ICANN that root server operators are supposed to sign. Rumor has it that many root server operaters haven't signed the MoU, defying ICANN's authority over their operation. --Dean Actually Dean - good point - the MOU was never codified in a formal contract meaning that the US Department of Commerce still formally owns the root's and so under this newly proposed cyber-control law would give the US President the legal authority to on a mere presidential order (especially a HSPD) or just a simple presidential directive can shut all - repeat ALL - of ARIN's and each of the root systems down since the US DoC still owns them. I wonder how many of the Internet-Mavens on this list have figured that out... Todd Glassey On Wed, 2 Sep 2009, Dean Anderson wrote: RFC2870 describes root server operational requirements. Unsurprisingly, I see you only received frivolous answers from the same group of people who don't want to have any accountability for root server operations. You might review the archives for discussion of RFC2870. A while back, they were trying to alter the charter to remove root server operations from the first item of the WG charter, in order to silence my attempts to discuss TCP Anycast issues on root servers. But ICANN/IANA/D.O.C. looks to the IETF and particularly the DNSOP WG for technical advice on root server operations. Of course, D.O.C. could find technical advice somewhere else. --Dean On Wed, 26 Aug 2009, Todd Glassey wrote: Since the Internet is formally listed as a component of US Critical Infrastructure - I want to know the specific provisioning requirements for operating a root server. Anyone got a pointer to these? Todd Glassey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.76/2342 - Release Date: 09/02/09 18:03:00 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] A practical solution for ISP-level support of the reverse DNS tree for IPv6
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. 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. 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. 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6...
At 16:08 -0400 9/3/09, Lee Howard wrote: You can AXFR, or you can use the same algorithm: That's the issue, keeping the zone's contents coherent (AXFR) or the zone's synthesis coherent (copying the algorithm from A to B). generate on the fly--seems to be common practice already. It doesn't seem like PTR records need to be static just so transfers will work. That's not where (static PTRs) I was going. If my rule is like s/^3ffe:cafe:cafe:\(.*\)$/$1.customer.isp.tld/ (I.e., mapping like 3ffe:cafe:cafe::8001 to ::8001.customer.isp.tld) then I just need to ship that rule around. It looks simple with one rule, but if there are many, I'd like see it automated. I don't understand. In a non-ISP environment, say a large enterprise, the situation is a little more dynamic. The solution should work for that too. Go on... If I wasn't busy with work. Just thinking of when I worked with ENUM stuff. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6...
-Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Edward Lewis Sent: Thursday, September 03, 2009 12:07 PM To: Lee Howard Cc: dnsop@ietf.org; 'Edward Lewis' Subject: Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6... At 11:49 -0400 9/3/09, Lee Howard wrote: -Original Message- From: dnsop-boun...@ietf.org ... On Behalf Of Edward Lewis 1) Zone transfers? Is this a requirement for IP6.ARPA zones used for residential users? Kind of. To achieve a sufficient number 9's of availabilty (that is 99.9 or 99.999) more than one source of data is needed. That is, you In the on the fly scenario, you have the same level of availability if multiple authoritative servers provide the same response to a PTR query. You can AXFR, or you can use the same algorithm: any query for 1...8.b.d.0.1.0.0.2.ip6.arpa will always return 1...1.0.0.2.customer.example.com. could have just one server for an IPv6 range but then it is a single point of failure. Most DNS zones are on at least 2 servers - deep in the tree. The root zone is on 100's (13 visible at any one place at a a time), TLDs usually about a half-dozen (visible plus anycast). If there is no zone transfer, an admin would have to manually get the multiple sources to be in sync some other way. The admin could use things like RSYNC, but that means that the constellation is running in a special mode and if the admin is on vacation it might be hard to fix. It's safest to always have zone transfer defined for any DNS extension as this is the only means to provide interoperability and in-band maintenance of the system. I agree with you in principle. And I agree with you in specific cases, where DNS is updated dynamically, or reverse zones are prepopulated (i.e., any time the PTR records point to something actually useful). But most ISPs just put in placeholder records or generate on the fly--seems to be common practice already. It doesn't seem like PTR records need to be static just so transfers will work. 2) Dynamic update? Mutually exclusive per zone. For any given zone, you can either generate on the fly, or support dynamic updates. If you want both, you'll have to number them out of different scopes, which may not be as bad as it sounds. This is a question more based on things like Active Directory. This is not so vital, but given that incrementalism is growing in importance it would be a desired feature. In this case, I'd like to be able to add new synthesis rules on the fly (as opposed to DHCP lease information). I don't understand. 3) DNSSEC? I think such synthesis is the way to go. The problem is usually keeping a constellation of servers synchronized with respect to the synthesis rules, keeping up with changes, and signing the data. I'd like to see more on this topic. Me too. I don't mean to shoot down what Fujiwara-san has suggested. I am shooting down the notion that what we have now is good enough. Perhaps this is the next major incremental addition to the DNS protocol - a more general synthesis mechanism. (I envision something involving NAPTR...it has the seeds we need.) Go on... Lee ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new Questions...
Dean Anderson wrote: Todd is right. While I rather doubt that the USG /would/ shut down the roots or ARIN (thats pretty extreme), I believe the objective of the bill is to make explicit and indisputable USG control over infrastructure. As I understand it, the objective of the bill is so that the USG indisputably /could/ shut down whatever they thought necessary, including as Todd correctly notes, ARIN and the roots. --Dean Actually this is really funny because Mike Rubin (NIST's general counsel) on the morning he was running off to congress to testify before the 9/11 commission on NIST's findings on the collapse of the WTC towers told me Todd I will be dead before I let NIST run the Internet. It was a response to me personally (i.e. over a phone) where I suggested that this specific piece of legislation was a couple of years out at most. Seems like I may have been more accurate than anyone wanted. Todd Glassey On Thu, 3 Sep 2009, Todd Glassey wrote: Dean Anderson wrote: BTW, RFC2870 is not the authority on root server operations. The authority is found in the MoU with ICANN that root server operators are supposed to sign. Rumor has it that many root server operaters haven't signed the MoU, defying ICANN's authority over their operation. --Dean Actually Dean - good point - the MOU was never codified in a formal contract meaning that the US Department of Commerce still formally owns the root's and so under this newly proposed cyber-control law would give the US President the legal authority to on a mere presidential order (especially a HSPD) or just a simple presidential directive can shut all - repeat ALL - of ARIN's and each of the root systems down since the US DoC still owns them. I wonder how many of the Internet-Mavens on this list have figured that out... Todd Glassey On Wed, 2 Sep 2009, Dean Anderson wrote: RFC2870 describes root server operational requirements. Unsurprisingly, I see you only received frivolous answers from the same group of people who don't want to have any accountability for root server operations. You might review the archives for discussion of RFC2870. A while back, they were trying to alter the charter to remove root server operations from the first item of the WG charter, in order to silence my attempts to discuss TCP Anycast issues on root servers. But ICANN/IANA/D.O.C. looks to the IETF and particularly the DNSOP WG for technical advice on root server operations. Of course, D.O.C. could find technical advice somewhere else. --Dean On Wed, 26 Aug 2009, Todd Glassey wrote: Since the Internet is formally listed as a component of US Critical Infrastructure - I want to know the specific provisioning requirements for operating a root server. Anyone got a pointer to these? Todd Glassey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.76/2342 - Release Date: 09/02/09 18:03:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.76/2343 - Release Date: 09/03/09 05:50:00 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6...
Lee Howard wrote: 1) Zone transfers? Is this a requirement for IP6.ARPA zones used for residential users? Even if it were, you can use notify and IXFR. But, as availability of dynamic update of DNS is not very high (there is only one master server), don't mind so many 9s. 2) Dynamic update? Mutually exclusive per zone. Right. As dynamic generation of PTRs is a form of dynamic update, there is no point to have another form of dynamic update. 3) DNSSEC? I think such synthesis is the way to go. The way to go is to ignore both IPv6 and DNSSEC, neither of which are useful. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00
In message 002701ca2caf$549d3bd0$fdd7b3...@org, Lee Howard writes: -Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Monday, August 31, 2009 9:53 PM To: Doug Barton Cc: dnsop Subject: Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00 Windows already attempts to do UPDATE. It just does it over UDP. Switching to TCP for the UPDATE message should be trivial. I guess that's for them to decide, but certainly the protocols are there. I think I said that in the draft, too. Since this is IPv6 give each customer their own address block and corresponding reverse zone. You don't need a single big machine to do this. Would you delegate the reverse zone to CPE, or support updates on your servers? I would expect ISP's would accept updates on their own servers but may support a delegation being added. Hm, need to filter at the edge, make sure customer's don't update each other's records. A ISP should be doing this anyway for lots of reasons. Some rate limiting, maybe. Is a matching forward zone required, too? Eventually. IPv6 is a paradigm shift. Education needed: how do you tell a residential user what server will accept their dynamic PTR updates? You can send to any nameserver listed for the zone with a preference for the one that matched the SOA MNAME. You can find the zone by doing a query for SOA name of record to be added I have a expired draft which says to make the response to this have a 0 ttl if it would be a NXDOMAIN so you use any cache and not have the search poison the cache with a long lived NXDOMAIN response. The SOA's owner in the authority section will match the zone's name. From that you can get the zoness NS records etc. It authoritative servers don't do RFC2308 you just stip the left and label and try again. You will get a SOA when you reach the zone apex. Lee -- 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
