Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Mar 14, 2013, at 6:55 PM, Joe Abley jab...@hopcount.ca wrote: On 2013-03-14, at 18:52, George Michaelson g...@apnic.net wrote: how many of the deployed resolvers can understand DNAME Good question, it would interesting to design an experiment to measure that. and whats the outcome for dns lookups where the intermediate systems dont understand DNAME. CNAME synthesis, see RFC 6672 section 3. You mean like test.dname-only.res.dnssecready.net txt test.d-and-c.res.dnssecready.net txt test.d-bad-c.res.dnssecread.net txt The first name returns only dname, second one both, the third one has different targets for the C and D names. The txt record pointed to tells you if you the results tell you if the D or C name what happened. dhcp-606e:~/Code/evldns 23:09 dig test.d-bad-c.res.dnssecready.net txt ; DiG 9.8.3-P1 test.d-bad-c.res.dnssecready.net txt ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 12051 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.d-bad-c.res.dnssecready.net. IN TXT ;; ANSWER SECTION: d-bad-c.res.dnssecready.net. 300 IN DNAME good-Dname.dnssec-test.org. test.d-bad-c.res.dnssecready.net. 300 IN CNAME test.good-Dname.dnssec-test.org. test.good-Dname.dnssec-test.org. 3600 IN TXTGOOD: DNAME followed But the original server returned ;; ANSWER SECTION: d-bad-c.res.dnssecready.net. 300 IN DNAME good-Dname.dnssec-test.org. d-bad-c.res.dnssecready.net. 1 IN CNAME bad-Cname.dnssec-test.org. According to a large scale resolver/forwarder survey that I conducted recently DNAME is fully supported at least 50% of resolvers/forwarders tested supported it. Im sure the number is higher today because Google has added DNAME support since then. Fully supported means that the resolver follows DNAME and includes the DNAME 's used Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 03/14/2013 07:44 PM, Joe Abley wrote: (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's distribution masters who is retrieving the zone, and hence where the AS112++ operators were. So, this is also AS112 with DNSSEC, and it's measurable.) Also has the benefit of penalizing when a slave becomes stalled, going bogus when signatures expires. A resolver which falls in a bogus nameserver should try with the next one. So I think the organisations should host only one NS of the complete set, giving the chance of diversity. Hugo ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Mar 15, 2013, at 11:21 AM, Hugo Salgado hsalg...@nic.cl wrote: On 03/14/2013 07:44 PM, Joe Abley wrote: (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's distribution masters who is retrieving the zone, and hence where the AS112++ operators were. So, this is also AS112 with DNSSEC, and it's measurable.) Also has the benefit of penalizing when a slave becomes stalled, going bogus when signatures expires. A resolver which falls in a bogus nameserver should try with the next one. So I think the organisations should host only one NS of the complete set, giving the chance of diversity. It feels like there are two distinct issues here. If the signatures expire, all copies of those records will be affected, so diversity of name servers won't help. Diversity of name servers is certainly helpful in countering operational failures of equipment or network connectivity. Steve ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-03-15, at 14:34, Steve Crocker st...@shinkuro.com wrote: It feels like there are two distinct issues here. If the signatures expire, all copies of those records will be affected, so diversity of name servers won't help. My assumption was that this was a reference to the signatures expired because zone transfers stopped working and nobody noticed problem. Diversity of name servers is certainly helpful in countering operational failures of equipment or network connectivity. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 03/15/2013 03:34 PM, Steve Crocker wrote: On Mar 15, 2013, at 11:21 AM, Hugo Salgado hsalg...@nic.cl wrote: On 03/14/2013 07:44 PM, Joe Abley wrote: (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's distribution masters who is retrieving the zone, and hence where the AS112++ operators were. So, this is also AS112 with DNSSEC, and it's measurable.) Also has the benefit of penalizing when a slave becomes stalled, going bogus when signatures expires. A resolver which falls in a bogus nameserver should try with the next one. So I think the organisations should host only one NS of the complete set, giving the chance of diversity. It feels like there are two distinct issues here. If the signatures expire, all copies of those records will be affected, so diversity of name servers won't help. But the expiration affects only the instance that went stalled. The rest of correctly-slaved secondaries should maintain fresh signatures. Hugo Diversity of name servers is certainly helpful in countering operational failures of equipment or network connectivity. Steve ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Joe Abley jab...@hopcount.ca wrote: Once we have confidence that the AS112.ARPA zone is being hosted adequately, we could re-provision 10.IN-ADDR.ARPA, 168.192.IN-ADDR.ARPA and 16.172.IN-ADDR.ARPA and friends with DNAME and the old AS112 system can be retired. What will be the consequences of this for validators that are trying to use local versions of the RFC1918 zones? Will local zones have to be signed and provide trust anchors for validating users? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-02-22, at 15:14, Dickson, Brian bdick...@verisign.com wrote: Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target foo (replace foo with what you will) in the DNS tree? I've thought about this a bit, and I've decided that I quite like it. So, if I can paraphrase to ensure we're talking about the same thing, the current working omniscient plan involves: - custom code - some degree of discomfort, possibly unwarranted, with the NOERROR/no ANSWER approach Your idea, however, involves - hosting a known, empty zone on known nameservers - pseudo-delegating new worthy zones by provisioning a DNAME at a suitable point in another zone - no custom code - no protocol discomfort, so long as we don't gag too badly on the use of DNAME Your idea has advantages, then. Anybody could decide to sink traffic for any name at AS112++ servers by installing a similar DNAME. This would become a standard way to dispense with and junk DNS traffic; perhaps we need to think about writing this up as AS112.ARPA and make it a more general mechanism than just a place to sink default-local-zones traffic. Suppose AS112.ARPA is delegated to the nameservers BLACKHOLE-3.IANA.ORG and BLACKHOLE-4.IANA.ORG, and the AS112.ARPA zone is empty apart from an SOA (SOA.MNAME = PRISONER-2.IANA.ORG). The names of the servers don't matter much, except that they need not to be named under AS112.ARPA (since that would pollute the empty zone with A and RRSets). We acquire an IPv4 /24 and an IPv6 /48 from which to number those three servers. AS112++ operators listen on those addresses, announce the corresponding routes and host an AS112.ARPA zone which is empty apart from apex SOA and NS RRSets. (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's distribution masters who is retrieving the zone, and hence where the AS112++ operators were. So, this is also AS112 with DNSSEC, and it's measurable.) We want traffic for names under D.F.IP6.ARPA (RFC4291) to be handled in an AS112 like way. We install a DNAME in the IP6.ARPA zone: $ORIGIN IP6.ARPA. D.F IN DNAME AS112.ARPA. No changes are needed to the servers which serve AS112.ARPA. We can change our minds about D.F.IP6.ARPA or add new bits of namespace to be treated similarly at any time, with no coordination required by the AS112++ operators. Once we have confidence that the AS112.ARPA zone is being hosted adequately, we could re-provision 10.IN-ADDR.ARPA, 168.192.IN-ADDR.ARPA and 16.172.IN-ADDR.ARPA and friends with DNAME and the old AS112 system can be retired. RFC 6303 could be simplified by specifying that resolvers should host an empty AS112.ARPA zone, which would give similar behaviour to hosting a long list of empty zones (not as great a reduction in traffic for the zones mentioned in 6303, but with the benefit that other zones which are AS112++ified would get caught locally without requiring updates to 6303 or resolver configuration). RFC 6304 could be replaced with updated guidance (new addresses, just hosting AS112.ARPA). We can avoid re-enragement of the IESG by not re-proposing SINK.ARPA as a way to avoid generating junk traffic, understanding that using AS112.ARPA wherever SINK.ARPA might have been used is nearly as good. This seems like a good, pragmatic path forward. I'm intrigued to hear the reactions of others to the general idea or the details of this rambling thought experiment. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-03-14, at 18:52, George Michaelson g...@apnic.net wrote: how many of the deployed resolvers can understand DNAME Good question, it would interesting to design an experiment to measure that. and whats the outcome for dns lookups where the intermediate systems dont understand DNAME. CNAME synthesis, see RFC 6672 section 3. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
FWIW, this was first broached on the AS112 operators ML. Thread here: https://lists.dns-oarc.net/pipermail/as112-ops/2011-July/000209.html Hope this contributes to the discussion. On Thu, 14 Mar 2013, Joe Abley wrote: On 2013-02-22, at 15:14, Dickson, Brian bdick...@verisign.com wrote: Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target foo (replace foo with what you will) in the DNS tree? I've thought about this a bit, and I've decided that I quite like it. So, if I can paraphrase to ensure we're talking about the same thing, the current working omniscient plan involves: - custom code - some degree of discomfort, possibly unwarranted, with the NOERROR/no ANSWER approach Your idea, however, involves - hosting a known, empty zone on known nameservers - pseudo-delegating new worthy zones by provisioning a DNAME at a suitable point in another zone - no custom code - no protocol discomfort, so long as we don't gag too badly on the use of DNAME Your idea has advantages, then. Anybody could decide to sink traffic for any name at AS112++ servers by installing a similar DNAME. This would become a standard way to dispense with and junk DNS traffic; perhaps we need to think about writing this up as AS112.ARPA and make it a more general mechanism than just a place to sink default-local-zones traffic. Suppose AS112.ARPA is delegated to the nameservers BLACKHOLE-3.IANA.ORG and BLACKHOLE-4.IANA.ORG, and the AS112.ARPA zone is empty apart from an SOA (SOA.MNAME = PRISONER-2.IANA.ORG). The names of the servers don't matter much, except that they need not to be named under AS112.ARPA (since that would pollute the empty zone with A and RRSets). We acquire an IPv4 /24 and an IPv6 /48 from which to number those three servers. AS112++ operators listen on those addresses, announce the corresponding routes and host an AS112.ARPA zone which is empty apart from apex SOA and NS RRSets. (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's distribution masters who is retrieving the zone, and hence where the AS112++ operators were. So, this is also AS112 with DNSSEC, and it's measurable.) We want traffic for names under D.F.IP6.ARPA (RFC4291) to be handled in an AS112 like way. We install a DNAME in the IP6.ARPA zone: $ORIGIN IP6.ARPA. D.F IN DNAME AS112.ARPA. No changes are needed to the servers which serve AS112.ARPA. We can change our minds about D.F.IP6.ARPA or add new bits of namespace to be treated similarly at any time, with no coordination required by the AS112++ operators. Once we have confidence that the AS112.ARPA zone is being hosted adequately, we could re-provision 10.IN-ADDR.ARPA, 168.192.IN-ADDR.ARPA and 16.172.IN-ADDR.ARPA and friends with DNAME and the old AS112 system can be retired. RFC 6303 could be simplified by specifying that resolvers should host an empty AS112.ARPA zone, which would give similar behaviour to hosting a long list of empty zones (not as great a reduction in traffic for the zones mentioned in 6303, but with the benefit that other zones which are AS112++ified would get caught locally without requiring updates to 6303 or resolver configuration). RFC 6304 could be replaced with updated guidance (new addresses, just hosting AS112.ARPA). We can avoid re-enragement of the IESG by not re-proposing SINK.ARPA as a way to avoid generating junk traffic, understanding that using AS112.ARPA wherever SINK.ARPA might have been used is nearly as good. This seems like a good, pragmatic path forward. I'm intrigued to hear the reactions of others to the general idea or the details of this rambling thought experiment. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
I've got no objections to experimenting with DNAME like this. DNAME and NXDOMAIN are QTYPE agnostic whereas NOERROR/NODATA is not. 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] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 22, 2013, at 8:52 PM, P Vixie p...@redbarn.org wrote: Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. RCODE=3 states that the name does not exist. no children might be implied from that, but that is just it, an implication. A resolver assuming that no children exist is a resolver trying to be cute, and might be over-optimising. BIND9 (before 9.2.3) used to emit RCODE3 on empty non-terminals, and there are other implementations that currently still show this behaviour. Also see this message: http://www.ietf.org/mail-archive/web/dnsext/current/msg11084.html No data/noerror says there are either other types or children or both. No, it really does not. Again this is implicit. What Nodata/noerror says is that the type requested for a name does not exist. NOERROR-NODATA is perfectly valid. There is no data to return for that QNAME, as the QTYPE does not exist. This is a negative response that, according to RFC2308 (NO DATA RESPONSE TYPE3) is a valid response. This is not 'lying' or 'not true', as the type for that QNAME really does not exist. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? … Paul There is no ambiguity. You're trying to optimise query load, with the assumption that NXDOMAIN implies absence of children, while resolvers implementations should actually not use this assumption at all. Roy Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 07:57, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell. I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact. So, the suggestion is not to replace the existing AS112 servers (blackho le-1, blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that. Joe DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 26 2013, Tony Finch wrote: Dickson, Brian bdick...@verisign.com wrote: [...] Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target foo (replace foo with what you will) in the DNS tree? Like this? We have had (afaik) one interop problem with this setup: there was a mail server on a network with DNAMEd reverse DNS, and some recipient sites objected to this. Including in particular those for c*m*a*t.n*t, to whom we wrote in March 2011 | It appears that your servers fail to cope with this sort of result, | and respond with an immediate | | 421 [hostname] comcast Reverse DNS failure : Try again later | | to an SMTP connection. | | What surprises us is that they do not behave like this if reverse | lookup returns just a CNAME and a PTR record, in the style originally | envisaged by RFC 2317. The extra DNAME seems to make the difference, | but it ought to be ignored if not understood, and the synthesised | CNAME acted on instead. We never heard back from them, and we had to paper over the problem by replacing the DNAME for 233.232.128.in-addr.arpa with 256 CNAMEs. Still, this shouldn't be an issue if the intent is to generate a negative answer to a reverse lookup. More to the current point is that (unfortunately) few DNS registries support putting DNAMEs in parent zones in place of delegations. -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Hi Peter, Stephen, At 14:48 25-02-2013, Warren Kumari wrote: Yup -- the call for adoption on Saturday the 9th, and ended on Monday the 18th, which was a public holiday / long weekend in the USA. This means that US folk only had 4 or 5 working days to read and comment. If it had been run for the more traditional 2 weeks (and if folk had realized that they specifically had to state that they would be a reviewer) thing might have gone differently. There seems to have been a glitch during the call for adoption of draft-wkumari-dnsop-omniscient-as112-01. Would it be possible for you to look into whether anything could be done? Thanks, -sm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2/25/13 7:29 PM, Tony Finch d...@dotat.at wrote: Dickson, Brian bdick...@verisign.com wrote: However, there is another UGLY, EVIL way that might achieve what you're thinking of: Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target foo (replace foo with what you will) in the DNS tree? Like this? Yes. Except, of course, for AS112 domains, and for some agreed-upon target. While mail servers doing PTR look-up having problems is a potential concern, keep in mind that AS112 is meant to be used for local-ish zones, like 10.in-addr.arpa. If a mail server is doing PTR look-up for net-10, in a way that leaks, IMHO, failure _is_ an option. :-) (Hint - public mail servers establishing TCP to/from a net-10 address is already pretty bad. Behind firewalls/closed-doors, net-10 is fine, but reverse DNS on that should be handled both privately and properly.) Brian We have had (afaik) one interop problem with this setup: there was a mail server on a network with DNAMEd reverse DNS, and some recipient sites objected to this. ; DiG 9.9.2-vjs340.03-P1 @authdns0.csx.cam.ac.uk -x 128.232.255.255 ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 47436 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;255.255.232.128.in-addr.arpa. IN PTR ;; ANSWER SECTION: 255.232.128.in-addr.arpa. 86400 IN DNAME 255.232.128.in-addr.arpa.cam.ac.uk. 255.255.232.128.in-addr.arpa. 86400 IN CNAME 255.255.232.128.in-addr.arpa.cam.ac.uk. ;; AUTHORITY SECTION: in-addr.arpa.cam.ac.uk.14400 IN SOA authdns0.csx.cam.ac.uk. hostmaster.ucs.cam.ac.uk. 1361480354 14400 3600 604800 14400 ;; Query time: 0 msec ;; SERVER: 2001:630:212:8::d:a0#53(2001:630:212:8::d:a0) ;; WHEN: Tue Feb 26 00:25:59 2013 ;; MSG SIZE rcvd: 187 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Dickson, Brian bdick...@verisign.com wrote: While mail servers doing PTR look-up having problems is a potential concern, keep in mind that AS112 is meant to be used for local-ish zones, like 10.in-addr.arpa. Right. I probably should have said more clearly that it works pretty well if that is the worst interop problem. I just remembered another problem, that many unices have antediluvian stub resolvers that write to syslog when they see a DNAME record, e.g. gethostby*.getanswer: asked for 42.143.232.128.in-addr.arpa IN PTR, got type 39 Apart from logging, the code ignores the DNAME record and happily processes the synthesized CNAME record, so it is mostly a benign bug apart from the annoying noise in the logs. If AS112 were to use DNAME this is likely to become a tiresome FAQ. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 22, 2013, at 4:25 PM, P Vixie p...@redbarn.org wrote: I think your requirement is wrong, or misstated. You ought not want to imply there could be other types, except at the apex. The semantics of an empty riot zone in a disconnected name space suit you perfectly. If I get ambitious and revive resimprove then the no children exist signaling will also matter. Why get cute? Were not trying to get cute -- the initial version of the draft had an empty root (http://tools.ietf.org/html/draft-wkumari-dnsop-omniscient-as112-00 Section 6.2 Fig 3 ), but, as Mark correctly pointed out, the answers were not cached. I'll retest with minimal responses soon, but for now will simply s/NOERROR/NXDOMAIN/ in the draft (so I can squeeze it in before the revision cutoff). W Paul Joe Abley jab...@hopcount.ca wrote: We want the absence of (qname, qtype) to be cached by resolvers who follow a delegation to an omniscient as112 server for all (qname, qtype). Given that requirement the thought was that NOERROR/no data and NXDOMAIN were equally plausible. However, I see now that the lack of no children signalling has the potential to cause increased query load, since resolvers will re-query for children despite an earlier query for a parent. My feeling is that this is not a big deal and the ability to add/drop with no coordination with server operators represents a greater win, but I have no science behind my words. The current scheme (witness Warren's code) seems to do this (modulo extra queries for children) for all (qname, qtype) where qtype != SOA. Which is not perfect, but, I think pretty good. We could servfail on qtype == SOA I guess, which is crazy nasty but which I think for all practical purposes would work. I like your other message's minimal response notion, though. When I'm not sitting on a plane headed for a beach, I will play with that. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:53, P Vixie p...@redbarn.org wrote: Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 07:57, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell. I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact. So, the suggestion is not to replace the existing AS112 servers (blackhole-1, blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that. Joe DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Credo quia absurdum est. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 22, 2013, at 3:47 PM, P Vixie p...@redbarn.org wrote: Sounds like you want it to return the nxd with no 2308 proof which means most receives will cache it because the erroneous delegation isn't present. Bind calls this a minimal response I think. … Paul Hmmm… 'minimal-responses yes' doesn't seem to change the response -- the ARM says: If yes the server will only add records to the authority and additional data sections when they are required, for instance, delegations and negative responses. This may improve the performance of the server by reducing outgoing data volumes. The BIND default is no. This statement may be used in a view or a global options clause. Couldn't find any other hopeful sounding options, but will look a little more / poke the code... I tried testing anyway, but answer didn't seem to get cached. Did it all in a bit of a rush, so entirely possible my testing is flawed (it often is :-P) I have a box configured with 'minimal-responses yes' at minimal.superficialinjurymonkey.com. (204.194.22.106) if folk want to test against it… W Joe Abley jab...@hopcount.ca wrote: Hi Paul, That was our starting point; however, it turned out that resolvers wouldn't cache the name error, I think because the SOA returned with the name error in the authority section was clearly bogus (i.e. conflicted with the root zone SOA presumably already cached by the resolver client). I too have always preferred the idea of specifying configuration for standard software over custom code (neat though the custom code Warren is running is). We just couldn't figure out how to do it. Did we miss something? Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:39, P Vixie p...@redbarn.org wrote: I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname. Paul Warren Kumari war...@kumari.net wrote: On Feb 22, 2013, at 6:57 AM, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. W (If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) noerror/nodata is the wrong answer. DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. --Terry Prachett DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Hi Joe, At 14:35 24-02-2013, Joe Abley wrote: The most recent decision that I saw from the chairs was that it should not be adopted. I do not agree that that is the best path forward. The draft might have crossed the review threshold after the deadline. Authors are usually given an opportunity to cross that threshold. That tends to fail when there isn't adequate socialization. Regards, -sm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 25, 2013, at 4:52 PM, SM s...@resistor.net wrote: Hi Joe, At 14:35 24-02-2013, Joe Abley wrote: The most recent decision that I saw from the chairs was that it should not be adopted. I do not agree that that is the best path forward. The draft might have crossed the review threshold after the deadline. Authors are usually given an opportunity to cross that threshold. That tends to fail when there isn't adequate socialization. Yup -- the call for adoption on Saturday the 9th, and ended on Monday the 18th, which was a public holiday / long weekend in the USA. This means that US folk only had 4 or 5 working days to read and comment. If it had been run for the more traditional 2 weeks (and if folk had realized that they specifically had to state that they would be a reviewer) thing might have gone differently. But yes, fully agree that we could have socialized this better…. W Regards, -sm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Dickson, Brian bdick...@verisign.com wrote: However, there is another UGLY, EVIL way that might achieve what you're thinking of: Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target foo (replace foo with what you will) in the DNS tree? Like this? We have had (afaik) one interop problem with this setup: there was a mail server on a network with DNAMEd reverse DNS, and some recipient sites objected to this. ; DiG 9.9.2-vjs340.03-P1 @authdns0.csx.cam.ac.uk -x 128.232.255.255 ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 47436 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;255.255.232.128.in-addr.arpa. IN PTR ;; ANSWER SECTION: 255.232.128.in-addr.arpa. 86400 IN DNAME 255.232.128.in-addr.arpa.cam.ac.uk. 255.255.232.128.in-addr.arpa. 86400 IN CNAME 255.255.232.128.in-addr.arpa.cam.ac.uk. ;; AUTHORITY SECTION: in-addr.arpa.cam.ac.uk. 14400 IN SOA authdns0.csx.cam.ac.uk. hostmaster.ucs.cam.ac.uk. 1361480354 14400 3600 604800 14400 ;; Query time: 0 msec ;; SERVER: 2001:630:212:8::d:a0#53(2001:630:212:8::d:a0) ;; WHEN: Tue Feb 26 00:25:59 2013 ;; MSG SIZE rcvd: 187 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Joe Abley jab...@hopcount.ca wrote: I too have always preferred the idea of specifying configuration for standard software over custom code (neat though the custom code Warren is running is). We just couldn't figure out how to do it. Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
... Tony Finch wrote: ... Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
... Paul Vixie wrote: ... Tony Finch wrote: ... Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html that message's pdf attachment appears to have been corrupted. another copy is here: http://ss.vix.su/~vixie/mz.pdf paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
The most recent decision that I saw from the chairs was that it should not be adopted. I do not agree that that is the best path forward. Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-24, at 13:15, SM s...@resistor.net wrote: At 11:27 22-02-2013, Warren Kumari wrote: If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. The subject line says Adoption as WG item. Has draft-wkumari-dnsop-omniscient-as112-01 been adopted yet? Regards, -sm ___ 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] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 22/02/2013 05:47, Mark Andrews wrote: For much the same reason that *.COM was bad. *.com was certainly evil, but I don't think it's necessarily fair to compare the two, given the different usage scope of forward and reverse domains. You *will* break things that you are unaware of. can you quantify / clarify any things which you think it will break? Nick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-02-22, at 01:47, Mark Andrews ma...@isc.org wrote: In message f42adb61-fcf4-47b3-8062-745d136d8...@algebras.org, George Michaels on writes: On 21/02/2013, at 6:46 AM, Mark Andrews ma...@isc.org wrote: * it changes the response from NXDOMAIN to NOERROR NODATA. And why is that wrong ? I dont understand what you see as the outcomes. more query? bad DNS? load? For much the same reason that *.COM was bad. You *will* break things that you are unaware of. For clarity, the reason why the spec specifies NOERROR NODATA rather than NXDOMAIN is that the enclosing SOA is synthesised from the QNAME. Returning an NXDOMAIN with an SOA owner name of . was where we started, and (as pointed out by many) that breaks negative caching for most/all resolvers which is the opposite of what we want. Returning an NXDOMAIN with SOA owner name == QNAME seems wrong, since we're simultaneously saying that the name doesn't exist and returning an RRSet with the same name. Guessing at a different owner name for the SOA seems bad because at this point we're just making stuff up and surely it'll be wrong at least some of the time, and break negative caching again. Returning NOERROR NODATA with SOA owner name == QNAME seemed like the best option. It's still a form of negative response, which (according to our testing) is cached in a way that makes sense. For the record, we realise this is a hack. But it's a hack that facilitates new delegations to AS112 without risking lame delegations, which would be bad in their own way (lame delegations are to be expected when we have no central control over AS112 operators, and don't even know where they are in general, never mind how to contact the people who run them or check that they are not lame). Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Subject: Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item? Date: Fri, Feb 22, 2013 at 03:57:45AM -0800 Quoting Paul Vixie (p...@redbarn.org): if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. As Randy Bush suggested, some 10 years ago, accept dynupdates, and serve that ;-) An U-turn for fertilizer. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hand me a pair of leather pants and a CASIO keyboard -- I'm living for today! signature.asc Description: Digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-02-22, at 07:57, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell. I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact. So, the suggestion is not to replace the existing AS112 servers (blackhole-1, blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
In message 51274721.1030...@inex.ie, Nick Hilliard writes: On 22/02/2013 05:47, Mark Andrews wrote: For much the same reason that *.COM was bad. *.com was certainly evil, but I don't think it's necessarily fair to compare the two, given the different usage scope of forward and reverse domains. You *will* break things that you are unaware of. can you quantify / clarify any things which you think it will break? I can well imagine a machine doing a reverse lookup on a proposed address and not proceeding with that address if it doesn't get a NXDOMAIN. NODATA - unsafe NXDOMAIN - may be safe The problem is that we don't know what changing the status quo will do. We have to be very cautious about doing that. 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] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-02-22, at 09:39, Mark Andrews ma...@isc.org wrote: I can well imagine a machine doing a reverse lookup on a proposed address and not proceeding with that address if it doesn't get a NXDOMAIN. NODATA - unsafe NXDOMAIN - may be safe So, out of interest, do you think it's legitimate for an omniscient server to return something like this? (note the RCODE and the SOA RRSet returned in the authority section) ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.10.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 1.1.1.10.in-addr.arpa. 604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 1800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: 116 That would be a simple change to the spec. We chose NOERROR/ANSWER:0 because we thought it didn't make sense to say NXDOMAIN whilst at the same time synthesising an authority-section SOA with the same owner name as the QNAME when the RCODE we're returning indicates that that owner name doesn't exist. As someone familiar with implementing the receiver side of this hack, would/should this negative answer be cached? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 22/02/2013 13:39, Mark Andrews wrote: The problem is that we don't know what changing the status quo will do. We have to be very cautious about doing that. I agree we should be cautious. So why not run it on some as112 servers on a pilot basis and see what happens? Full logging would be required, as well as some idea of what sort of problems to look for (e.g. multiple repeated queries from the same source, etc). Does this seem sensible? Nick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-02-22, at 10:42, Nick Hilliard n...@inex.ie wrote: I agree we should be cautious. So why not run it on some as112 servers on a pilot basis and see what happens? Full logging would be required, as well as some idea of what sort of problems to look for (e.g. multiple repeated queries from the same source, etc). Does this seem sensible? I think an even more cautious approach would be to run it for zones that are not currently served by AS112 (e.g. those in the locally-served zones registry that are not currently delegated to AS112 servers). Providing omniscient servers on different addresses (so, a different anycast cloud, but presumably with overlaps with the current one) and leaving the existing AS112 servers untouched would give us some field experience with zero jeopardy for existing assumptions about AS112 service. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
One question/caveat: What would the practical impact be, if the TTL on the SOA were the same as the default negative caching TTL (for the NXDOMAIN)? I think it would be slightly less sniffy, to have the NXDOMAIN and the synthesized SOA both disappear at the same time. IIRC, the TTL would then need to be 900 rather than 604800. Brian On 2/22/13 8:49 AM, Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 09:39, Mark Andrews ma...@isc.org wrote: I can well imagine a machine doing a reverse lookup on a proposed address and not proceeding with that address if it doesn't get a NXDOMAIN. NODATA - unsafe NXDOMAIN - may be safe So, out of interest, do you think it's legitimate for an omniscient server to return something like this? (note the RCODE and the SOA RRSet returned in the authority section) ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.10.in-addr.arpa.IN PTR ;; AUTHORITY SECTION: 1.1.1.10.in-addr.arpa. 604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 1800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: 116 That would be a simple change to the spec. We chose NOERROR/ANSWER:0 because we thought it didn't make sense to say NXDOMAIN whilst at the same time synthesising an authority-section SOA with the same owner name as the QNAME when the RCODE we're returning indicates that that owner name doesn't exist. As someone familiar with implementing the receiver side of this hack, would/should this negative answer be cached? Joe ___ 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] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2013-02-22, at 12:33, Dickson, Brian bdick...@verisign.com wrote: One question/caveat: What would the practical impact be, if the TTL on the SOA were the same as the default negative caching TTL (for the NXDOMAIN)? The longevity of the negative answer in the cache is defined as min(SOA TTL, SOA MINIMUM). There is no magic, here. I think it would be slightly less sniffy, to have the NXDOMAIN and the synthesized SOA both disappear at the same time. IIRC, the TTL would then need to be 900 rather than 604800. The existing AS112 servers return SOA TTL = SOA MINIMUM = 604800, per RFC 6304. Setting the SOA TTL to 900 would reduce the longevity of both the SOA and the NOERROR/NODATA to 900 seconds from a week. I don't think that's desirable for these zones. Note I'm assuming that NOERROR/NODATA are cached the same way as NXDOMAIN. draft-kumari-omniscient-as112-01 specifies SOA MINIMUM = 604800 but doesn't specify the SOA TTL. Should probably fix that. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 22 2013, Mark Andrews wrote: I can well imagine a machine doing a reverse lookup on a proposed address and not proceeding with that address if it doesn't get a NXDOMAIN. NODATA - unsafe NXDOMAIN - may be safe So when I do a reverse lookup of 255.255.255.255 or ::0, and BIND gives me a NODATA response from its automatic empty zones that cover just those specific addresses and no others, then it is being unsafe? -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Good point, indirectly referencing RFC 2308 (I always seem to forget about that one). So, other than SOA TTL going into the draft, I think it's all good, and please ignore everything else I said (e.g. 900). Brian On 2/22/13 11:43 AM, Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 12:33, Dickson, Brian bdick...@verisign.com wrote: One question/caveat: What would the practical impact be, if the TTL on the SOA were the same as the default negative caching TTL (for the NXDOMAIN)? The longevity of the negative answer in the cache is defined as min(SOA TTL, SOA MINIMUM). There is no magic, here. I think it would be slightly less sniffy, to have the NXDOMAIN and the synthesized SOA both disappear at the same time. IIRC, the TTL would then need to be 900 rather than 604800. The existing AS112 servers return SOA TTL = SOA MINIMUM = 604800, per RFC 6304. Setting the SOA TTL to 900 would reduce the longevity of both the SOA and the NOERROR/NODATA to 900 seconds from a week. I don't think that's desirable for these zones. Note I'm assuming that NOERROR/NODATA are cached the same way as NXDOMAIN. draft-kumari-omniscient-as112-01 specifies SOA MINIMUM = 604800 but doesn't specify the SOA TTL. Should probably fix that. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 22, 2013, at 8:49 AM, Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 09:39, Mark Andrews ma...@isc.org wrote: I can well imagine a machine doing a reverse lookup on a proposed address and not proceeding with that address if it doesn't get a NXDOMAIN. NODATA - unsafe NXDOMAIN - may be safe So, out of interest, do you think it's legitimate for an omniscient server to return something like this? (note the RCODE and the SOA RRSet returned in the authority section) ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.10.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 1.1.1.10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 1800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: 116 That would be a simple change to the spec. We chose NOERROR/ANSWER:0 because we thought it didn't make sense to say NXDOMAIN whilst at the same time synthesising an authority-section SOA with the same owner name as the QNAME when the RCODE we're returning indicates that that owner name doesn't exist. Yup, the change to the spec and the change to the code are both simple. I also changed the TTLs to match what I got when querying AS112 (not because I necessarily think that they are the right numbers, just as an example) wkumari@dns-test:~/tmp/evldns$ diff -Naur oas112d.c oas112d.c.orig --- oas112d.c 2013-02-22 19:02:36.875829849 + +++ oas112d.c.orig 2013-02-22 18:35:52.546628018 + @@ -33,7 +33,7 @@ #include ctype.h #include evldns.h -static char *t_soa = @ SOA a.as112.net. hostmaster.as112.net. 1 1800 900 0604800 604800; +static char *t_soa = @ SOA a.as112.net. hostmaster.as112.net. 1 604800 2592000 0604800 604800; static char *t_ns1 = @ NS b.as112.net.; static char *t_ns2 = @ NS c.as112.net.; @@ -57,7 +57,7 @@ ldns_pkt *req = srq-request; /* the default response packet */ - ldns_pkt *resp = srq-response = evldns_response(req, LDNS_RCODE_NXDOMAIN); + ldns_pkt *resp = srq-response = evldns_response(req, LDNS_RCODE_NOERROR); /* copy the question and determine qtype and qname */ ldns_rr *question = ldns_rr_list_rr(ldns_pkt_question(req), 0); - The NOERROR version can be seen by querying scratch-monkey.kumari.net, the NXDOMAIN by querying dns-test.snozzages.com As someone familiar with implementing the receiver side of this hack, would/should this negative answer be cached? Folk are welcome to test against these and see how their particualr resolvers cache…. W Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft. --Anon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 22, 2013, at 6:57 AM, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. W (If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) noerror/nodata is the wrong answer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. --Terry Prachett ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 2/22/13 2:27 PM, Warren Kumari war...@kumari.net wrote: (If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) Uh, definitely not. The whole point is you don't know from where the delegation comes, e.g. at what depth in the label tree. However, there is another UGLY, EVIL way that might achieve what you're thinking of: Instead of delegating to omniscient AS112 servers, what about doing a DNAME to a specific target foo (replace foo with what you will) in the DNS tree? Then, that location foo can be the SOA to use (which does not change regardless of the original question), along with any synthesized NXDOMAIN response. I did say it was evil. :-) Brian P.S. Example case: 10.in-addr.arpa. DNAME as112-leaf.prisoner.iana.org. Imagine the recursive wants an answer for the question: 1.1.1.10.in-addr.arpa. IN PTR Any root provides the above DNAME The local omniscient-112 server sees the question: 1.1.1.as112-leaf.prisoner.iana.org. The local omniscient-112 server gives the following answer: ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.as112-leaf.prisoner.iana.org.IN PTR ;; AUTHORITY SECTION: as112-leaf.prisoner.iana.org. 604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: 116 And the recursive resolver would give the following answer (or something like it) to the client: (The CNAME is synthesized from the question and the DNAME, if I understand the relevant RFCs.) (I'm not sure if the recursive would send the SOA/Authority component) ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 41208 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.1.1.as112-leaf.prisoner.iana.org. IN PTR ;; ANSWER SECTION 10.in-addr.arpa. DNAME as112-leaf.prisoner.iana.org. 1.1.1.10.in-addr.arpa. CNAME 1.1.1.as112-leaf.prisoner.iana.org. ;; AUTHORITY SECTION: as112-leaf.prisoner.iana.org. 604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 900 604800 604800 ;; Query time: 3 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Fri Feb 22 13:45:36 2013 ;; MSG SIZE rcvd: ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname. Paul Warren Kumari war...@kumari.net wrote: On Feb 22, 2013, at 6:57 AM, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. W (If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) noerror/nodata is the wrong answer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. --Terry Prachett ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Hi Paul, That was our starting point; however, it turned out that resolvers wouldn't cache the name error, I think because the SOA returned with the name error in the authority section was clearly bogus (i.e. conflicted with the root zone SOA presumably already cached by the resolver client). I too have always preferred the idea of specifying configuration for standard software over custom code (neat though the custom code Warren is running is). We just couldn't figure out how to do it. Did we miss something? Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:39, P Vixie p...@redbarn.org wrote: I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname. Paul Warren Kumari war...@kumari.net wrote: On Feb 22, 2013, at 6:57 AM, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. W (If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) noerror/nodata is the wrong answer. -- DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. --Terry Prachett -- DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 07:57, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell. I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact. So, the suggestion is not to replace the existing AS112 servers (blackhole-1, blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Sounds like you want it to return the nxd with no 2308 proof which means most receives will cache it because the erroneous delegation isn't present. Bind calls this a minimal response I think. ... Paul Joe Abley jab...@hopcount.ca wrote: Hi Paul, That was our starting point; however, it turned out that resolvers wouldn't cache the name error, I think because the SOA returned with the name error in the authority section was clearly bogus (i.e. conflicted with the root zone SOA presumably already cached by the resolver client). I too have always preferred the idea of specifying configuration for standard software over custom code (neat though the custom code Warren is running is). We just couldn't figure out how to do it. Did we miss something? Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:39, P Vixie p...@redbarn.org wrote: I'd like to be able to implement this with a standard authority server, no special code, just a root zone that's empty other than its apex. So please no requirements for the soa other than that it be at or above the qname. Paul Warren Kumari war...@kumari.net wrote: On Feb 22, 2013, at 6:57 AM, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. If the WG consensus is NXDOMAIN, we can do that. *We* felt that NOERROR was more appropriate, but 'its entirely possible we are wrong. W (If folk feel sufficiently strongly we *could* even strip a label off, so that the synthesized SOA is not the same as the NXD. *This* feel really hacks, but putting it out there...) noerror/nodata is the wrong answer. -- DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is. --Terry Prachett -- DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
We want the absence of (qname, qtype) to be cached by resolvers who follow a delegation to an omniscient as112 server for all (qname, qtype). Given that requirement the thought was that NOERROR/no data and NXDOMAIN were equally plausible. However, I see now that the lack of no children signalling has the potential to cause increased query load, since resolvers will re-query for children despite an earlier query for a parent. My feeling is that this is not a big deal and the ability to add/drop with no coordination with server operators represents a greater win, but I have no science behind my words. The current scheme (witness Warren's code) seems to do this (modulo extra queries for children) for all (qname, qtype) where qtype != SOA. Which is not perfect, but, I think pretty good. We could servfail on qtype == SOA I guess, which is crazy nasty but which I think for all practical purposes would work. I like your other message's minimal response notion, though. When I'm not sitting on a plane headed for a beach, I will play with that. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:53, P Vixie p...@redbarn.org wrote: Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 07:57, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell. I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact. So, the suggestion is not to replace the existing AS112 servers (blackhole-1, blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that. Joe -- DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
I think your requirement is wrong, or misstated. You ought not want to imply there could be other types, except at the apex. The semantics of an empty riot zone in a disconnected name space suit you perfectly. If I get ambitious and revive resimprove then the no children exist signaling will also matter. Why get cute? Paul Joe Abley jab...@hopcount.ca wrote: We want the absence of (qname, qtype) to be cached by resolvers who follow a delegation to an omniscient as112 server for all (qname, qtype). Given that requirement the thought was that NOERROR/no data and NXDOMAIN were equally plausible. However, I see now that the lack of no children signalling has the potential to cause increased query load, since resolvers will re-query for children despite an earlier query for a parent. My feeling is that this is not a big deal and the ability to add/drop with no coordination with server operators represents a greater win, but I have no science behind my words. The current scheme (witness Warren's code) seems to do this (modulo extra queries for children) for all (qname, qtype) where qtype != SOA. Which is not perfect, but, I think pretty good. We could servfail on qtype == SOA I guess, which is crazy nasty but which I think for all practical purposes would work. I like your other message's minimal response notion, though. When I'm not sitting on a plane headed for a beach, I will play with that. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:53, P Vixie p...@redbarn.org wrote: Sorry to be late on this, missed it earlier. Nxd says there is no such name, no matter what the type was, and there are no children. No data/noerror says there are either other types or children or both. We know what the truth must be and we know which implications we want the requestor to follow. Right? Is there any doubt at all or any ambiguity in what we want said? ... Paul Joe Abley jab...@hopcount.ca wrote: On 2013-02-22, at 07:57, Paul Vixie p...@redbarn.org wrote: if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. It does smell a bit wrong, but I'm interested in more details of why you think that if it's more than just the smell. I'll note that the proposal is to assign new nameservers to be omniscient, and not to convert the existing ones. We are then in a position to delegate other local-zoneish zones to the new servers and review the impact. So, the suggestion is not to replace the existing AS112 servers (blackhole-1, blackhole-2 and prisoner) out of the gate. Any such replacement would happen later, once there was some degree of comfort that it was safe to do that. Joe -- DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 21/02/2013, at 6:46 AM, Mark Andrews ma...@isc.org wrote: While I think we should adopt the document I have grave concerns about it. * there is no demonstrated need for it. thats opinion, not fact Mark. 'demonstrated need' stems from other people's desires. you might as well come out and say you think AS112 has no demonstrated need, as say this draft has no role in administration of AS112. I tend to another opinion. I think this draft identifies a sensible path to making AS112 servers respond the way we want. * it is likely to interact badly with validating resolvers especially when there are lots of labels in the qname below the delegation to these servers. AS112 is designed to offer a quick termination of query hunting to a non-value. Can you explain how this fails to be satisfied by a wildcard response, when we are seeking to divert a query WHICH CANNOT BE ANSWERED IN THE WIDER NET to a 'not' answer? the internal side of anyone who has valid delegation of a domain which has hit an AS112 can have as much DNSSEC as they want. its everyone else, who sees the sideblow queries who needs this. I am probably being thick. can you do an illustrative instance of what you mean here? * it changes the response from NXDOMAIN to NOERROR NODATA. And why is that wrong ? I dont understand what you see as the outcomes. more query? bad DNS? load? If we have to build special servers can't they periodically transfer a list of zones they need to serve rather than return what is essentially the wrong answer? the back-end administration has proved fraught. btw, I continue to collect data on the volume of ULA, link-local, teredo traffic in reverse, and it continues to grow.. -George 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
In message f42adb61-fcf4-47b3-8062-745d136d8...@algebras.org, George Michaels on writes: On 21/02/2013, at 6:46 AM, Mark Andrews ma...@isc.org wrote: While I think we should adopt the document I have grave concerns about it. * there is no demonstrated need for it. thats opinion, not fact Mark. 'demonstrated need' stems from other people's desires. you might as well come out and say you think AS112 has no demonstrated need, as say this draft has no role in administration of AS112. I tend to another opinion. I think this draft identifies a sensible path to making AS112 servers respond the way we want. * it is likely to interact badly with validating resolvers especially when there are lots of labels in the qname below the delegation to these servers. AS112 is designed to offer a quick termination of query hunting to a non-value. Can you explain how this fails to be satisfied by a wildcard response, when we are seeking to divert a query WHICH CANNOT BE ANSWERED IN THE WIDER NET to a 'not' answer? It's not a wild card response. the internal side of anyone who has valid delegation of a domain which = has hit an AS112 can have as much DNSSEC as they want. its everyone = else, who sees the sideblow queries who needs this. It's the impact on those that are validating but don't have default local zones of equivalent. There a 30 delegations between d.f.ip6.arpa and the full reverse of a ULA under this proposal. Hunting for missing DS records will hit every one of them. I am probably being thick. can you do an illustrative instance of what you mean here? * it changes the response from NXDOMAIN to NOERROR NODATA. And why is that wrong ? I dont understand what you see as the outcomes. more query? bad DNS? load? For much the same reason that *.COM was bad. You *will* break things that you are unaware of. If we have to build special servers can't they periodically transfer a list of zones they need to serve rather than return what is essentially the wrong answer? the back-end administration has proved fraught. btw, I continue to collect data on the volume of ULA, link-local, teredo traffic in reverse, and it continues to grow.. And the traffic stats are where? The analysis of the recursive servers that are sending this traffic is where? Vendor, version, isp. Is it worth adding the terado prefix to locally served zones registry? -George 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 -- 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] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
While I think we should adopt the document I have grave concerns about it. * there is no demonstrated need for it. * it is likely to interact badly with validating resolvers especially when there are lots of labels in the qname below the delegation to these servers. * it changes the response from NXDOMAIN to NOERROR NODATA. If we have to build special servers can't they periodically transfer a list of zones they need to serve rather than return what is essentially the wrong answer? 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] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
I know I'm late, but for what it's worth I'd support this. I'm happy to help, if possible. Perhaps I can sync with Warren et alia in person in Orlando. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Dear WG, Please respond by the end of next week, so that we could ask future editors to submit a renamed -00 version by Monday, Feb 18. thanks to all who responded and especially to those three volunteer reviewers. However, we've not met the 5 reviewer threshold, so your chairs agreed the WG might want to spend a bit more time given that interest was signalled. The current authors are encouraged to fold in comments they received on this list and also we'd like to see discussion on content so that there might be a broader base next time. We will be going to start negotiating goals and milestones with our new AD in Orlando and will keep this topic in mind, but we also need a strong WG commitment to work on a draft. This means we'll not have a draft-ietf-dnsop-as112-omniscient this time, but no more, no less: nobody should be discouraged from making comments on this draft, the floor remains open. Best regards, Peter (as DNSOP co-chair) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On 9 feb 2013, at 21:45, Peter Koch p...@denic.de wrote: the topic of AS112 has been addresses in the DNSOP WG resulting in RFCs 6304 and 6305 and is also related to 'local zones' as described in RFC 6303. The question of extending AS112 service to IPv6 (as in transport) as well as the maintainability of the list of zones served by AS112 systems has been discussed before. We have a proposal in draft-wkumari-dnsop-omniscient-as112-01.txt to make the AS112 served zone set extendable in the future. Please read the draft and state whether you think this is something the WG - and you in particular - would want to work on. We'd like to find five volunteers for thorough document reviews to support the draft going forward - provided the overall response is positive. Me too supports adoption! Best regards, - kurtis - Best regards, - kurtis - signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
nick I like this and think it should be adopted as a WG doc. Am not nick going to volunteer for formal document review, but would be happy nick to run + provide feedback for this sort of code in a live nick environment. I also support this being adopted as a WG document. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Fri, Feb 15, 2013 at 5:05 PM, Paul Ebersman list-dn...@dragon.net wrote: nick I like this and think it should be adopted as a WG doc. Am not nick going to volunteer for formal document review, but would be happy nick to run + provide feedback for this sort of code in a live nick environment. I also support this being adopted as a WG document. aolme too!/aol seems like a great start. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
Sure, looks good. I'll review drafts. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Feb 9, 2013, at 3:45 PM, Peter Koch p...@denic.de wrote: Dear WG, the topic of AS112 has been addresses in the DNSOP WG resulting in RFCs 6304 and 6305 and is also related to 'local zones' as described in RFC 6303. The question of extending AS112 service to IPv6 (as in transport) as well as the maintainability of the list of zones served by AS112 systems has been discussed before. We have a proposal in draft-wkumari-dnsop-omniscient-as112-01.txt to make the AS112 served zone set extendable in the future. Please read the draft and state whether you think this is something the WG - and you in particular - would want to work on. We'd like to find five volunteers for thorough document reviews to support the draft going forward - provided the overall response is positive. It is always very helpful if people could identify open questions in/w.r.t. the draft, but please don't forget to also state your opinion on adoption. Please respond by the end of next week, so that we could ask future editors to submit a renamed -00 version by Monday, Feb 18. And just a note: The last day for submission of a -00 is Feb18th, but the last day for adoption was the 11th. So, if this is adopted, the authors can resubmit with a new name, but it approved till the cycle restarts… • 2013-02-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. • 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool. W Thanks, Peter Stephen ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- What our ancestors would really be thinking, if they were alive today, is: Why is it so dark in here? -- (Terry Pratchett, Pyramids) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
On Wed, Feb 13, 2013 at 12:34:09PM -0500, Warren Kumari wrote: The last day for submission of a -00 is Feb18th, but the last day for adoption was the 11th. So, if this is adopted, the authors can resubmit with a new name, but it approved till the cycle restarts? ? 2013-02-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. ? 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool. the time difference appears to be a leftover from pre-automation times. WG chairs can use automated tools to approve or even pre-approve a WG -00 submission, i.e., this will not be a process road block. -Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
