Re: [DNSOP] Fwd: New Version Notification
note, i have removed the leading tab character from this author's paragraphs, since i find it very distracting. (a cautionary note to marka and bmanning.) [EMAIL PROTECTED] (Phil Regnauld) writes: Question: How do existing implementations react to the presence of a single, terminal dot ? What if an A record is published for '.' ? I know it probably won't happen. but I'm also curious to know, and I think the document should specify this: what is the impact of this on existing implementations ? i'm afraid that this will just result in a lot of QTYPE A messages sent to the authority servers for . asking about ., and a lot of new useless RCODE 3 responses therefrom. Question: In some cases it can be useful to be able to identify the real master anyway. But MNAME was never a reliable way of ascertaining which server in an NS set was the source of data, if such a source existed at all. during the preparation of RFC 2136 we knew that SOA.MNAME was often meaningless, and so the rule is, if it's the same as an NS.NSDNAME, then it's the best target for an update. the purpose of this was to avoid having to forward updates from secondaries toward the master. but as it happened, noone read RFC 2136 carefully. every second of every day, the SOA.MNAME for 10.in-addr.arpa receives update requests from all over the world, even though it is not also an NS.NSDNAME. those update requests are all coming from a single vendor's implementation. Do people on this list think that we are losing any valuable information by using the convention suggested by Joe, or was it already too uncertain, and that no usefull debugging/troubleshooting information is being lost by implementing the suggested approach ? i think it will not be correctly implemented, just as RFC 2136 was not correctly implemented, and if people start putting SOA.MNAME=. then it will just lead to a lot more QTYPE A queries for .. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification
Paul Vixie wrote: [EMAIL PROTECTED] (Phil Regnauld) writes: Question: How do existing implementations react to the presence of a single, terminal dot ? What if an A record is published for '.' ? I know it probably won't happen. but I'm also curious to know, and I think the document should specify this: what is the impact of this on existing implementations ? i'm afraid that this will just result in a lot of QTYPE A messages sent to the authority servers for . asking about ., and a lot of new useless RCODE 3 responses therefrom. Are you certain? (And does RCODE 3 mean, as I understand it, NXDOMAIN?) I tried doing just such a query using dig, and got: ; DiG 9.3.2 @f.root-servers.net A . +norec ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47975 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN A ;; AUTHORITY SECTION: . 86400 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2008062800 1800 900 604800 86400 ;; Query time: 3 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Sat Jun 28 16:11:59 2008 ;; MSG SIZE rcvd: 92 i think it will not be correctly implemented, just as RFC 2136 was not correctly implemented, and if people start putting SOA.MNAME=. then it will just lead to a lot more QTYPE A queries for .. Hypothetically speaking, if an actual answer for such a query were returned, would anything actually *use* the answer? Again, hypothetically speaking, if an A RR were added for . , with a very long TTL, such as 8640, that would be cached ubiquitously, and reduce these queries at the root servers, right? Again, hypothetically, what values for such an A RR would cause benign behaviour? E.g. 127.0.0.1? Just thinking *way* outside the box Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification
[EMAIL PROTECTED] (Brian Dickson) writes: Are you certain? (And does RCODE 3 mean, as I understand it, NXDOMAIN?) i mean of course ANCOUNT=0 RCODE=0, thank you for your correction. Again, hypothetically, what values for such an A RR would cause benign behaviour? E.g. 127.0.0.1? Just thinking *way* outside the box i think that if LOCALHOST. could be made to return A 127.0.0.1 and ::1 then we could use LOCALHOST. as a meaningless value for SOA.MNAME, but that would just be there to handle the case where RFC 2136 initiators were talking to an SOA.MNAME that did not match any NS.NSDNAME, in which case they are already out of spec and it's difficult to say how much effort should be spent changing the spec further. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-jabley-dnsop-missing-mname-00
(updated subject to reflect draft being discussed) Paul Vixie (vixie) writes: i think that if LOCALHOST. could be made to return A 127.0.0.1 and ::1 then we could use LOCALHOST. as a meaningless value for SOA.MNAME, I actually considered that option for a moment. but that would just be there to handle the case where RFC 2136 initiators were talking to an SOA.MNAME that did not match any NS.NSDNAME, in which case they are already out of spec and it's difficult to say how much effort should be spent changing the spec further. Is it then out of spec if we're working with a hidden/unreachable master server, and even though it is disclosed in SOA.MNAME, it is not listed in NS.NSDNAME ? What should one put in the SOA.MNAME in that case ? Any one of the slaves ? Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
A number of the points you raise have already been addressed. The IPV6 Reverse resolution question has been discussed at length in DNSEXT previously. In fact, it was proposed to remove reverse resolution entirely from IPV6 for just the reason Dr. Huang notes. A 128 bit IPV6 address is 16 octets. To perform reverse resolution requires traversing 16 levels of DNS tree. Even the delegations impose significantly larger trees on the registries. It is recognized that this isn't going to be very scalable, or even possible. IPV6 proposes to use ICMP Node Identification query instead. At present, there is an IPV6 reverse tree, but it is not guarenteed it will stay. It is for transition--so that gethostbyaddr() still works on IPv6 during transition. See for example the discussions here: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html --Dean On Sat, 28 Jun 2008, Phil Regnauld wrote: 2.3 Reverse Resolution Reverse Resolution uses .IN-ADDR.ARPA domain today. In IPv6, .IP6.ARPA was defined by [RFC3152], and more detail information can be found in [RFC3596]. Because IPv6 has a huge Name Space, it is difficult to keep reverse RRs in today's architecture. Question: Why ? Yes, IPv6 space is immense, but for the foreseeable future, only a very small part of it will be populated. Same goes for IP6.ARPA. But there are no data, either by you or others, supporting the claim that it will be more difficult to accomodate reverse information as IP6.ARPA grows. Do you have some simulation, model or other data-based prediction that can be used to illustrate this problem ? -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Dean Anderson (dean) writes: A number of the points you raise have already been addressed. Hi Dean, Where ? The IPV6 Reverse resolution question has been discussed at length in DNSEXT previously. In fact, it was proposed to remove reverse resolution entirely from IPV6 for just the reason Dr. Huang notes. Which one ? There's still nothing showing that there effectively is going to be a bottleneck of traffic to the root. Some curve, some data points, anything, we could use to extrapolate future problems from current trends, or even a *simulation* of load based on guesstimages/projections of network host population would come in handy. A 128 bit IPV6 address is 16 octets. To perform reverse resolution requires traversing 16 levels of DNS tree. How is that better than 32 steps for the proposed implementation ? (from the draft, §2.3) The Total address space of IPv6 is huge. But, only the Reserve Domain Name Servers managing used IP addresses will join the Virtual Hierarchical Overlay Network for DNS. And the worst maxium query steps are 32. With route cache the query steps will be less than 32. Therefore, this strategy for Reverse Resolution is feasible. Note: I may very well have gotten lost in the logic, and if there's something I missed, please point it out... Even the delegations impose significantly larger trees on the registries. It is recognized that this isn't going to be very scalable, or even possible. Again, where ? The references you point to below are somewhat old, and of course it doesn't make them any less relevant (after all, IPv6 is only going to be get used more and more), but still, I fail to see any kind of model that really does show that it will be a problem. C. Huitema's argument that the ... operational implications are daunting, I can easily identify with -- autoconfiguration, if it does get used, will mean that everything has to be automatized and most likely dynamic. Alain Durand does point out that due to the size of ipv6 space, reverse information for large ranges of IP addresses will have to be dynamically generated, use wildcard, only record some, or drop. But it still doesn't say how this is going to be a problem, that Mr. (not a Dr. it seems) is arguing his draft is the solution to. IPV6 proposes to use ICMP Node Identification query instead. You mean ICMP Node Information ? (RFC4620) Yes, it definitely looks like an interesting solution. It has issues, though, for example, the fact that it assumes that every node on the internet will be reachable so that they can be queries: (from RFC4620, §8. Security Considerations) This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol MUST have a default configuration that refuses to answer queries from global- scope [3] addresses. ... and the protocol doesn't propose implementing a collector/ local aggregator which could handle/reverse proxy such queries at the edge router or firewall level, so I guess if you've got a firewall, you haven't got reverse anyway. At present, there is an IPV6 reverse tree, but it is not guarenteed it will stay. It is for transition--so that gethostbyaddr() still works on IPv6 during transition. That's not the impression I got. Decisions to phase out ip6.int and use ip6.arpa look to me like ip6.arpa is here to stay. HOW we populate it -- or rather: how do we make that namespace return something useful, using gethostbyaddr(), is part of the challenge -- for the reasons stated by the sources you site. But I don't see either of these issues in anyway related to the the overload of traffic in tree structure that Mr. Huang says should be avoided. See for example the discussions here: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html Cheers, Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
I have just kicked off the open source project VIRGO-DNS. I will lead my students and other colleagues to implement the draft. I got my Ph.d from 2003, and was senior research assocate in Cardiff University. The cache route information by applying Zipf's law will make average hops much less than worst hops. By theretical calculation, in the case of total numbers of DNS servers with 1 million, alpha parameter 0.91 cache size is 1000, L is 32, then p is 0.537; and average hops is less than 3. From: Phil Regnauld [EMAIL PROTECTED] Reply-To: To: Dean Anderson [EMAIL PROTECTED] Subject: Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt Date:Sun, 29 Jun 2008 00:27:11 +0200 Dean Anderson (dean) writes: A number of the points you raise have already been addressed. Hi Dean, Where ? The IPV6 Reverse resolution question has been discussed at length in DNSEXT previously. In fact, it was proposed to remove reverse resolution entirely from IPV6 for just the reason Dr. Huang notes. Which one ? There's still nothing showing that there effectively is going to be a bottleneck of traffic to the root. Some curve, some data points, anything, we could use to extrapolate future problems from current trends, or even a *simulation* of load based on guesstimages/projections of network host population would come in handy. A 128 bit IPV6 address is 16 octets. To perform reverse resolution requires traversing 16 levels of DNS tree. How is that better than 32 steps for the proposed implementation ? (from the draft, ?.3) The Total address space of IPv6 is huge. But, only the Reserve Domain Name Servers managing used IP addresses will join the Virtual Hierarchical Overlay Network for DNS. And the worst maxium query steps are 32. With route cache the query steps will be less than 32. Therefore, this strategy for Reverse Resolution is feasible. Note: I may very well have gotten lost in the logic, and if there's something I missed, please point it out... Even the delegations impose significantly larger trees on the registries. It is recognized that this isn't going to be very scalable, or even possible. Again, where ? The references you point to below are somewhat old, and of course it doesn't make them any less relevant (after all, IPv6 is only going to be get used more and more), but still, I fail to see any kind of model that really does show that it will be a problem. C. Huitema's argument that the ... operational implications are daunting, I can easily identify with -- autoconfiguration, if it does get used, will mean that everything has to be automatized and most likely dynamic. Alain Durand does point out that due to the size of ipv6 space, reverse information for large ranges of IP addresses will have to be dynamically generated, use wildcard, only record some, or drop. But it still doesn't say how this is going to be a problem, that Mr. (not a Dr. it seems) is arguing his draft is the solution to. IPV6 proposes to use ICMP Node Identification query instead. You mean ICMP Node Information ? (RFC4620) Yes, it definitely looks like an interesting solution. It has issues, though, for example, the fact that it assumes that every node on the internet will be reachable so that they can be queries: (from RFC4620, ?. Security Considerations) This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol MUST have a default configuration that refuses to answer queries from global- scope [3] addresses. ... and the protocol doesn't propose implementing a collector/ local aggregator which could handle/reverse proxy such queries at the edge router or firewall level, so I guess if you've got a firewall, you haven't got reverse anyway. At present, there is an IPV6 reverse tree, but it is not guarenteed it will stay. It is for transition--so that gethostbyaddr() still works on IPv6 during transition. That's not the impression I got. Decisions to phase out ip6.int and use ip6.arpa look to me like ip6.arpa is here to stay. HOW we populate it -- or rather: how do we make that namespace return something useful, using gethostbyaddr(), is part of the challenge -- for the reasons stated by the sources you site. But I don't see either of these issues in anyway related to the the overload of traffic in tree structure that Mr. Huang says should be avoided. See for example the discussions here: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html Cheers, Phil ___ DNSOP mailing
Re: [DNSOP] Fwd: New Version Notification
On 28 Jun 2008, at 11:29, Paul Vixie wrote: [EMAIL PROTECTED] (Phil Regnauld) writes: Question: How do existing implementations react to the presence of a single, terminal dot ? What if an A record is published for '.' ? I know it probably won't happen. but I'm also curious to know, and I think the document should specify this: what is the impact of this on existing implementations ? i'm afraid that this will just result in a lot of QTYPE A messages sent to the authority servers for . asking about ., and a lot of new useless RCODE 3 responses therefrom. Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst failures to send DNS UPDATE messages to root servers would not be cached? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification
Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst
failures to send DNS UPDATE messages to root servers would not be cached?
the data at hand tells me that lots of people don't cache, and those who
do only cache positives. but in principle, yes, if the hosts who aren't
following the spec regarding using SOA.MNAME as a selection criteria among
{NS.NSDNAME} happen not to be the same hosts who aren't caching negative
or empty results, then some good could come of this.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification
Paul Vixie wrote:
Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst
failures to send DNS UPDATE messages to root servers would not be cached?
the data at hand tells me that lots of people don't cache, and those who
do only cache positives. but in principle, yes, if the hosts who aren't
following the spec regarding using SOA.MNAME as a selection criteria among
{NS.NSDNAME} happen not to be the same hosts who aren't caching negative
or empty results, then some good could come of this.
What about the behavior of (modern) caching resolvers, at start-up time,
when they prime themselves based on the root hints file?
What do they query for, i.e. . with query type of any?
If that's the case, then such resolvers will already have the answer
(empty though it may be), and no new traffic should be seen.
If I understand things correctly, that is, and some quick local tests I
did seem to point to this behavior.
(Even trying to do dig +trace on the A of . seems to short-circuit
locally, without querying any root servers.)
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
