Joe Abley 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 val
On 03/15/2013 03:34 PM, Steve Crocker wrote:
>
> On Mar 15, 2013, at 11:21 AM, Hugo Salgado 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 w
On 2013-03-15, at 14:34, Steve Crocker 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 becaus
On Mar 15, 2013, at 11:21 AM, Hugo Salgado 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
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,
On Mar 14, 2013, at 6:55 PM, Joe Abley wrote:
>
> On 2013-03-14, at 18:52, George Michaelson 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
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
_
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" wrote:
Instead of delegatin
On 2013-03-14, at 18:52, George Michaelson 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 synth
On 2013-02-22, at 15:14, "Dickson, Brian" 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 p
On Feb 22, 2013, at 8:52 PM, P Vixie 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,
On Feb 26 2013, Tony Finch wrote:
[...]
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
On Feb 26 2013, Tony Finch wrote:
Dickson, Brian 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
Dickson, Brian 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 intero
On 2/25/13 7:29 PM, "Tony Finch" wrote:
>Dickson, Brian 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 yo
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 th
...
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
...
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 mailin
Joe Abley 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
Dickson, Brian 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 h
On Feb 25, 2013, at 4:52 PM, SM 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 th
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 opportunit
On Feb 22, 2013, at 3:47 PM, P Vixie 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
On Feb 22, 2013, at 4:25 PM, P Vixie 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 an
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 wrote:
> At 11:27 22-02-2013, Warren Kumari wrote:
>> If the WG consensus is NXDOMAIN,
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
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
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"
signallin
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 wrote:
>Hi Paul,
>
>That was our starting point; however, it turned out that res
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 foll
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 t
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 wrote:
>
>On Feb 22, 2013, at 6:57 AM, Paul Vixie
On 2/22/13 2:27 PM, "Warren Kumari" 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
On Feb 22, 2013, at 6:57 AM, Paul Vixie 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* fe
On Feb 22, 2013, at 8:49 AM, Joe Abley wrote:
>
> On 2013-02-22, at 09:39, 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
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" wrote:
>
>On 2013-02-22, at 12:33, "Dickson, Bri
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, an
On 2013-02-22, at 12:33, "Dickson, Brian" 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 MINIMU
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 ne
On 2013-02-22, at 10:42, Nick Hilliard 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
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
On 2013-02-22, at 09:39, 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, out of interest, do you think it's legi
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 rever
On 2013-02-22, at 07:57, Paul Vixie 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 wr
Subject: Re: [DNSOP] Adoption of
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 serv
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.o
On 2013-02-22, at 01:47, Mark Andrews wrote:
> In message , George
> Michaels
> on writes:
>
>> On 21/02/2013, at 6:46 AM, Mark Andrews wrote:
>>
>>> * it changes the response from NXDOMAIN to NOERROR NODATA.
>>
>> And why is that "wrong" ? I dont understand what you see as the outcomes.
>
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
In message , George Michaels
on writes:
>
> On 21/02/2013, at 6:46 AM, Mark Andrews 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
On 21/02/2013, at 6:46 AM, Mark Andrews 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
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
[ Quoting in "Re: [DNSOP] Adoption of 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
signature.asc
Description: Digital signature
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
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
On 9 feb 2013, at 21:45, Peter Koch 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 maintain
Sure, looks good. I'll review drafts.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Fri, Feb 15, 2013 at 5:05 PM, Paul Ebersman 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 als
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.
> 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 exten
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 (
On Feb 9, 2013, at 3:45 PM, Peter Koch 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 wel
I support adoption. I am volunteering for document review.
-G
On 10/02/2013, at 6:45 AM, Peter Koch 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 o
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
sys
63 matches
Mail list logo
