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] New draft-livingood-negative-trust-anchors-04
On 2/20/13 1:50 PM, Richard Lamb richard.l...@icann.orgmailto:richard.l...@icann.org wrote: As I am late to looking at this draft please take this only as a comment from a narrow minded engineer ;-) After the rationale, explanations and caveats I kept looking for how to implement a NTA. After initially thinking this would be the introduction of some new functionality and RRset manipulation, I only found a reference to how Unbound implements it. Ack. Warren suggested the same. I will add to open issues in the next update and will add it to a future update of the doc! So it might be useful to have section 2 “Definition ..” make that clear for slow people like me - that the NTA is not an RR and is more of a configuration. Maybe simply replacing “placed” with “implemented” in section 2? “This NTA can potentially be [placed][implemented] at any level within the chain of trust…” Will do – added this to my open issues tracker as well. JL Feel free to ignore of this thread has already been covered. Regardless of whether my comment makes sense, I do this this is a useful draft to have. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft-livingood-negative-trust-anchors-04
On 2/18/13 3:24 PM, Olafur Gudmundsson o...@ogud.com wrote: Jason, in section 10 you talk about possible early removal the NTA when validation succeeds but there may be instances where validation succeeds when using a sub-set of the authoritative servers thus NTA should only be removed if all servers are providing good signatures. Excellent point! We have certainly see cases where 2 of 3 name servers are fine and one of them is acting wonky. I will add that to the open issue tracker for a future substantive update! Furthermore what to do if some names work but others do not, for example I remember a case where the records at the apex worked but all names below the apex were signed by a key not in the DNSKEY RRset, thus it is possible that either human or automated checks may assume there is no problem when there actually is one. What this is bringing to my mind is maybe you want a new section with guidelines on how to test for failures and in what cases failure justifies NTA and what tests MUST pass before preemttive removal of an NTA. Good question - will address in a future version as well. Also should there be guidance that removal of NTA should include cleaning the caches of all RRsets below the name? I think so, yes. I will add this as well - can't hurt. Thank you, Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft-livingood-negative-trust-anchors-04
On 2/20/13 1:52 PM, Joe Abley jab...@hopcount.ca wrote: On 2013-02-20, at 14:50, Richard Lamb richard.l...@icann.org wrote: FWIW: The -04 draft looks good. It is clear and well written and I think it is a valuable resource. As I am late to looking at this draft please take this only as a comment from a narrow minded engineer ;-) After the rationale, explanations and caveats I kept looking for how to implement a NTA. +1 The text seems to lead in that direction, and then end abruptly leaving the reader wondering what happened. Leaving room for a sequel? :-) Ack - will address in a future rev. :-) JL ___ 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
