Subject: [DNSOP] Adoption of <draft-wkumari-dnsop-omniscient-as112-01.txt> as a WG work item?

From: Peter Koch <[email-masked]>
Date: Sat, 9 Feb 2013 21:45:58 +0100

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.

Thanks,
  Peter & Stephen

---

From: George Michaelson <[email-masked]>
Date: Mon, 11 Feb 2013 08:42:01 +1000

I support adoption. I am volunteering for document review.

-G

On 10/02/2013, at 6:45 AM, Peter Koch <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Feb 2013 12:34:09 -0500

> 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

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)

---

From: Peter Koch <[email-masked]>
Date: Wed, 13 Feb 2013 18:42:51 +0100

On Wed, Feb 13, 2013 at 12:34:09PM -0500, Warren Kumari wrote:

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Feb 2013 15:37:02 -0800

Sure, looks good. I'll review drafts.

--Paul Hoffman

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Sun, 17 Feb 2013 23:37:20 +0100

> draft going forward - provided the overall response is positive.

Me too supports adoption!

Best regards,

- kurtis -

Best regards,

- kurtis -

---

From: Peter Koch <[email-masked]>
Date: Mon, 18 Feb 2013 18:16:39 +0100

Dear WG,

> 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)

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Feb 2013 00:50:13 +0900

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.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 20 Feb 2013 09:36:47 +0100

[ Quoting <[email-masked]> in "Re: [DNSOP] Adoption of <draft-wkum..." ]
> I know I'm late, but for what it's worth I'd support this.

+1

I've skimmed the document and support it being a wg doc. I also volunteer as
a reviewer.

Kind regards,
Miek Gieben

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2013 07:46:54 +1100

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: [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Fri, 22 Feb 2013 08:58:55 +1000

> * 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.

>  when there are lots of labels in the qname below the delegation to

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?

> 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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Feb 2013 16:47:00 +1100

In message <[email-masked]>, George Michaels
on writes:
> 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.
>
> 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.

> more query? bad DNS? load?

For much the same reason that *.COM was bad.  You *will* break things
that you are unaware of.
 
> 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?

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Feb 2013 10:23:29 +0000

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

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Feb 2013 07:01:27 -0400

> For much the same reason that *.COM was bad.  You *will* break things

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Feb 2013 03:57:45 -0800

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.

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 22 Feb 2013 13:07:38 +0100

> 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!

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Feb 2013 08:41:20 -0400

> 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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Feb 2013 00:39:01 +1100

> 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

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Feb 2013 09:49:12 -0400

> address and not proceeding with that address if it doesn't get a

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

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Feb 2013 14:42:24 +0000

> 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

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Feb 2013 10:49:57 -0400

> 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

---

From: "Dickson, Brian" <[email-masked]>
Date: Fri, 22 Feb 2013 16:33:25 +0000

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" <[email-masked]> wrote:

>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:
>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
>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

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Feb 2013 12:43:41 -0400

> 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.

> 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

---

From: Chris Thompson <[email-masked]>
Date: 22 Feb 2013 17:02:10 +0000

>address and not proceeding with that address if it doesn't get a

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: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: "Dickson, Brian" <[email-masked]>
Date: Fri, 22 Feb 2013 19:05:10 +0000

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" <[email-masked]> wrote:

>The longevity of the negative answer in the cache is defined as min(SOA
>TTL, SOA MINIMUM). There is no magic, here.
>
>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
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 Feb 2013 14:13:44 -0500

> 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 s…

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 +0000
+++ oas112d.c.orig	2013-02-22 18:35:52.546628018 +0000
@@ -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

-- 
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.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 Feb 2013 14:27:11 -0500

> 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...) 

--
"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

---

From: "Dickson, Brian" <[email-masked]>
Date: Fri, 22 Feb 2013 20:14:48 +0000

On 2/22/13 2:27 PM, "Warren Kumari" <[email-masked]> 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:

;; 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

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
;; MSG SIZE rcvd: xxxx

---

From: P Vixie <[email-masked]>
Date: Fri, 22 Feb 2013 12:38:53 -0800

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 <[email-masked]> 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.
>
>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...) 
>"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 
>
>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Feb 2013 16:43:55 -0400

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 <[email-masked]> 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 <[email-masked]> wrote:
>> ------------------------------
>>
>> DNSOP mailing list
>> [email-masked]
> ------------------------------
>
> DNSOP mailing list
> [email-masked]

---

From: P Vixie <[email-masked]>
Date: Fri, 22 Feb 2013 12:52:41 -0800

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 <[email-masked]> wrote:

>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

---

From: P Vixie <[email-masked]>
Date: Fri, 22 Feb 2013 12:47:50 -0800

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 <[email-masked]> 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.
>>
>> 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...)
>>

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Feb 2013 17:11:53 -0400

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

On 2013-02-22, at 16:53, P Vixie <[email-masked]> wrote:

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 <[email-masked]> wrote:
> 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

---

From: P Vixie <[email-masked]>
Date: Fri, 22 Feb 2013 13:25:43 -0800

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 <[email-masked]> wrote:

>(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

---

From: SM <[email-masked]>
Date: Sun, 24 Feb 2013 08:46:04 -0800

>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

---

From: Joe Abley <[email-masked]>
Date: Sun, 24 Feb 2013 18:35:21 -0400

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.

On 2013-02-24, at 13:15, SM <[email-masked]> wrote:

> The subject line says "Adoption as WG item".  Has draft-wkumari-dnsop-omniscient-as112-01 been adopted yet?
>
> Regards,
> -sm

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 Feb 2013 12:52:34 -0500

> If I get ambitious and revive resimprove then the no children exist signaling will also matter.

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
> 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
> 

--
Credo quia absurdum est.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 Feb 2013 13:53:05 -0500

On Feb 22, 2013, at 3:47 PM, P Vixie <[email-masked]> 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 

> 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
> 

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien

---

From: SM <[email-masked]>
Date: Mon, 25 Feb 2013 13:52:49 -0800

Hi Joe,
>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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 Feb 2013 17:48:24 -0500

On Feb 25, 2013, at 4:52 PM, SM <[email-masked]> wrote:

> 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

--
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

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Feb 2013 00:29:03 +0000

> DNAME to a specific target "foo" (replace "foo" with what you will) in the

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  <[email-masked]>  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.

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Feb 2013 00:31:18 +0000

> 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.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Feb 2013 16:45:32 -0800

...

Tony Finch wrote:
> ...

for reference:
http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html

paul

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Feb 2013 16:48:40 -0800

...

> 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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Feb 2013 16:54:06 +0800

Suggested change to draft-wkumari-dnsop-omniscient-as112-01.txt.

From:

   AS112 Servers do not respond to AXFR (QTYPE=252) or IXFR (QTYPE=251)
   requests.

To:

   AS112 Servers respond to AXFR (QTYPE=252) or IXFR (QTYPE=251) with RCODE=REFUSED.

But I am not sure if the existing is just an explanation of what is defined elsewhere or whether it is setting the "standard."  I'd discourage any attempt to define "no response" as the default response to any query in DNS.  (I'm fine with so-called rate-limit-caused no responses, but not blanket no responses.)

---

From: SM <[email-masked]>
Date: Tue, 26 Feb 2013 01:34:17 -0800

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

---

From: "Dickson, Brian" <[email-masked]>
Date: Tue, 26 Feb 2013 16:30:49 +0000

>> DNAME to a specific target "foo" (replace "foo" with what you will) in

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

>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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 26 Feb 2013 12:56:18 -0500

> But I am not sure if the existing is just an explanation of what is defined elsewhere or whether it is setting the "standard."  I'd discourage any attempt to define "no response" as the default res…

Oh, yeah, nice catch -- and, as always, thanks for providing text.

W

-- 
"Does Emacs have the Buddha nature? Why not? It has bloody well everything else..."

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Feb 2013 19:38:32 +0000

Dickson, Brian <[email-masked]> wrote:
> 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.

---

From: Chris Thompson <[email-masked]>
Date: 27 Feb 2013 16:57:36 +0000

>Dickson, Brian <[email-masked]> wrote:
[...]
>server on a network with DNAMEd reverse DNS, and some recipient sites

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.

---

From: Chris Thompson <[email-masked]>
Date: 27 Feb 2013 17:13:42 +0000

[...]
>likely to become a tiresome FAQ.

Or it might speed up the phasing out of these old glibc versions,
which would be a boon to all of us deploying DNAMEs in reverse lookup
contexts.