Re: [DNSOP] what's the right thing to do upon receiving something like this?

2007-02-19 Thread Paul Vixie
you mean, a name server looking at its own fully qualified host name and making policy decisions based on that? (sounds Incredibly Dangerous.) I'm possibly confused. The scenario I was thinking of seems to involve two nameservers on the same 10.x.x.x network that want to point to each

Re: [DNSOP] Feedback on draft-koch-dnsop-resolver-priming

2007-05-10 Thread Paul Vixie
mailing list posts, and the moderator ought to simply squash anything that's encumbered. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Feedback on draft-koch-dnsop-resolver-priming

2007-05-11 Thread Paul Vixie
I think this is exactly the sort of thing the IPR RFC requires for accepting encumbered ideas. (Although the restriction to root zone operators is a bit troubling.) yes. (also, TAKREM was offered free for GPL implementators, and so, worthless.) Anyways, the basic idea is that there's no

Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?

2007-06-05 Thread Paul Vixie
IETF to standardize encumbered IPR so that he can make money from license fees paid by people who deploy it. i think that's offensive screwheadedness and i am opposed to it. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org

[DNSOP] Re: Adopt draft-koch-dnsop-resolver-priming as WG work item?

2007-06-06 Thread Paul Vixie
anyone who is going to submit proposals for dns technology should not include encumbered IPR. This leaves open the issue of futile patents. If we decide We will never standardize a technology for which there is a patent somewhere in the world, no matter how futile it is, then, we will

Re: [DNSOP] draft-ietf-dnsop-respsize-07

2007-06-06 Thread Paul Vixie
important. Other than that, I think this is a good and useful draft, and should be advanced. me too! -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?

2007-06-09 Thread Paul Vixie
Mr. Paul Vixie to ISC, and the subordination relationship that can be inferred from Mr. Paul Vixie's position as ISC president. Paul has never tried to control what I do as DNSOP WG co-chair, and clearly understands the obligations that go with my position. Paul also knows me well

Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?

2007-06-11 Thread Paul Vixie
Austein needs to avoid participating in issues that affect his company, its financial position, or that of his co-workers. Should Rob recuse himself from *any* matter that Paul's sent an email about? What about opinions Paul may have discussed with Rob privately? Or just things he's

Re: [DNSOP] AS112 LOA?

2007-11-28 Thread Paul Vixie
So, would it be possible for one or more of the root server operators to prepare a generic-yet-official-looking LOA on suitable letterhead and perhaps stash it on www.root-servers.org somewhere? in principle, sure. but i think if it's a form available on the web, then some enterprising

Re: [DNSOP] Re: AS112 for TLDs

2007-12-05 Thread Paul Vixie
can. I support using AS112 for that. Great way to reduce the error traffic at root-servers.net. wildcards can't be cname's or ns's. (of the many important reasons why the suggestion is terrible, that's the first/simplest that comes to mind.) -- Paul Vixie

Re: [DNSOP] AS112 for TLDs

2008-04-03 Thread Paul Vixie
in political controversy that it's barely worth suggesting them. Call me cynical :-) that's not the least iota cynical. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AS112 for TLDs

2008-04-14 Thread Paul Vixie
[EMAIL PROTECTED] (William F. Maton Sotomayor) writes: At this point, I'd like to see the current pair of drafts move forward, and would cast this particular issue as the subject of some sort of other document. likewise, me. -- Paul Vixie

Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt

2008-06-24 Thread Paul Vixie
. ... therefore while i find your proposed solution to be of high quality, there is a cost in overall system complexity for adding a virtual routing layer to the DNS, which would have to be justified by a much more complete problem statement and an objective analysis of more than one alternative. -- Paul Vixie

Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt

2008-06-25 Thread Paul Vixie
From: 黄理灿 [EMAIL PROTECTED] ... almost all web pages was unreachable even the machine was in China because of root servers are located in USA. ... according to http://f.root-servers.org/, there are two f-root servers in china. if you have local contacts within china, please help us add

Re: [DNSOP] Fwd: New Version Notification

2008-06-28 Thread Paul Vixie
as RFC 2136 was not correctly implemented, and if people start putting SOA.MNAME=. then it will just lead to a lot more QTYPE A queries for .. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification

2008-06-28 Thread Paul Vixie
NS.NSDNAME, in which case they are already out of spec and it's difficult to say how much effort should be spent changing the spec further. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification

2008-06-28 Thread Paul Vixie
Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst failures to send DNS UPDATE messages to root servers would not be cached? the data at hand tells me that lots of people don't cache, and those who do only cache positives. but in principle, yes, if the hosts who aren't

Re: [DNSOP] Kaminsky on djbdns bugs (fwd)

2008-08-11 Thread Paul Vixie
mistreatment. (had i known at the outset how IETF worked, i would have worked to prevent that mistreatment, but i was a n00b.) -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean

[DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

2008-08-18 Thread Paul Vixie
of these serve any nondiagnostic purpose, and they are all dangerous to the stability of responders. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

2008-08-18 Thread Paul Vixie
Paul's original proposal, C (if I interpret it correctly) applies to resolver-authority-server communications, not stub-resolver communications. no, i was pretty much ruling them out period. especially (RA=1 AND RD=0). however, i could accept a SHOULD NOT for ADNS vs. a SHOULD for RDNS

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

2008-08-18 Thread Paul Vixie
what would it do if it had a TCP-forbidding firewall between it and its RDNS? Dunno, but when PowerDNS had TCP bugs in its resolver code, all the complaints I got were from Exchange users. they'll cope. What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

2008-08-18 Thread Paul Vixie
Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. we don't need a reason to deprecate tcp/53 beyond what's written in

Re: [DNSOP] Cache poisoning on DNSSEC

2008-08-20 Thread Paul Vixie
worried about corruption inside servers not just between them, and i want to defend against provider-in-the-middle attacks (including several that opendns currently monetizes.) -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR

2008-08-20 Thread Paul Vixie
... let's deprecate these bit patterns altogether for OP=QUERY: QTYPE=255 Breaks some sendmail versions and qmail. i once hacked sendmail internals, and what i remember is that it would try a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the hopeful

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR

2008-08-20 Thread Paul Vixie
i answered this on namedroppers, where the thread actually belongs. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] Cache poisoning on DNSSEC

2008-08-20 Thread Paul Vixie
no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. DNSSEC will not stop that. please explain how i can get undetectably bad data in a dnssec environment,

[DNSOP] trolls (Re: Reflectors are Evil was Re: Anycast was Re: Cache)

2008-09-03 Thread Paul Vixie
of the silent majority of fence sitters watching the back forth. show some willpower, folks, please. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] trolls (Re: Reflectors are Evil was Re: Anycast was Re: Cache)

2008-09-03 Thread Paul Vixie
the un-answered argument wins only if it's never answered. that would cross the line. answering it every day for the rest of all of our lives crosses the other line. (not responding publically to the personal parts of what bill said to me.)

Re: [DNSOP] MX 0 . standard way of saying we don't do email ?

2009-04-14 Thread Paul Vixie
As for MX 0 . the sooner this gets defined as no SMTP service for this domain the better. The cost for changing this is only every going to increase. It may take years before a significant portion of SMTP servers recognize root domains as meaning no service. that would never happen.

Re: [DNSOP] measuring TCP query performance

2009-08-25 Thread Paul Vixie
From: David Conrad d...@virtualized.org Date: Tue, 25 Aug 2009 15:45:58 -0700 Since time is quite short for folks to upgrade their servers and given some root server operators are financially / operationally / politically constrained in how they would go about doing the upgrade, it seems to

Re: [DNSOP] measuring TCP query performance

2009-08-26 Thread Paul Vixie
Date: Wed, 26 Aug 2009 16:39:31 -0500 From: Michael Graff mgr...@isc.org ... since by definition, I always really need stuff. +1. years ago i tried to differentiate between additional data or authority section data that a requestor could live without, vs. additional data or authority section

Re: [DNSOP] new Questions...

2009-09-03 Thread Paul Vixie
Date: Thu, 03 Sep 2009 06:48:21 -0700 From: Todd Glassey tglas...@earthlink.net Actually Dean - good point - the MOU was never codified in a formal contract meaning that the US Department of Commerce still formally owns the root's and so under this newly proposed cyber-control law would

Re: [DNSOP] Should root-servers.net be signed

2010-03-19 Thread Paul Vixie
From: Nicholas Weaver nwea...@icsi.berkeley.edu Date: Fri, 19 Mar 2010 12:48:24 -0700 ... Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the

[DNSOP] dns interface to whois? (Re: Taking Back the DNS )

2010-11-21 Thread Paul Vixie
here's something interesting. You have just received a comment for: Taking Back the DNS http://www.circleid.com/posts/20100728_taking_back_the_dns/#7331 By Marc Perkel ... Also - I would like to see some sort of DNS lookup to determine the age of a domain and the expiration date through

Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )

2010-11-21 Thread Paul Vixie
From: John L. Crain john.cr...@icann.org Date: Sun, 21 Nov 2010 09:51:45 -0800 Why would we do this, who gains by adding this? I don't see the benefit. i think it's so that folks can refuse e-mail from domains under N days old where N is a local policy decision. i have no direct use for

Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )

2010-11-22 Thread Paul Vixie
Date: Mon, 22 Nov 2010 20:36:17 + From: bmann...@vacation.karoshi.com we tried this a couple time last decade with limited success. (pre SRV). it would work, if and only if there were general agreement by the zone admins to actually keep up w/ the data. while i expect that it would

Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )

2010-11-22 Thread Paul Vixie
Date: Mon, 22 Nov 2010 22:52:34 + From: bmann...@vacation.karoshi.com well, at least two schemas have been proposed and there was limited uptake either time. perhaps times have changed. the fact that so few people have spoken up gives me my answer -- there's not enough

Re: [DNSOP] A new appoarch for identifying anycast name server instance

2011-09-27 Thread Paul Vixie
On Tuesday, September 27, 2011 09:49:03 am Masataka Ohta wrote: Xun wrote: Unicast address of an anycast server is very useful for many diagnostics, however, as DNS queries is sent to the anycast address and the path is decided by routing system, knowing the set of unicast address may not

Re: [DNSOP] A new appoarch for identifying anycast name server instance

2011-09-28 Thread Paul Vixie
On Tue, 27 Sep 2011 22:51:09 +0900 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Paul Vixie wrote: The purpose I see in this proposal, that cannot be handled by the IP layer, is to tell me which anycast instance is seen by some recursive name server. All our current diagnostics

Re: [DNSOP] A new appoarch for identifying anycast name server instance

2011-09-29 Thread Paul Vixie
On Thursday, September 29, 2011 07:34:55 am Masataka Ohta wrote: The problem is that the report is unreliable. As your assumption is: The purpose I see in this proposal, that cannot be handled by the IP layer, is to tell me which anycast instance is seen by some recursive name server.

[DNSOP] word wrapping and respect for standards

2011-09-29 Thread Paul Vixie
On Thursday, September 29, 2011 03:36:26 pm Nicholas Weaver wrote: Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like text lines are at most 72 characters, monospaced which were obsolete two decades ago. And in

Re: [DNSOP] Sanity check

2011-10-27 Thread Paul Vixie
On Thursday, October 27, 2011 10:06:25 Havard Eidnes wrote: I wonder if I could please have someone say whether they agree with me on this one: ... My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic

Re: [DNSOP] Data model and field names for DNS in JSON or XML

2012-01-18 Thread Paul Vixie
On 1/18/2012 7:06 PM, W.C.A. Wijngaards wrote: this sounds very cool; is there an internet draft or tech note describing the protocol so that others may also implement this? It exists to bypass deep inspection firewalls, and it works. The plain DNS format as you would use over TCP, but

Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]

2012-02-11 Thread Paul Vixie
On 2/11/2012 5:25 PM, Paul Hoffman wrote: On Feb 9, 2012, at 1:39 PM, bmann...@vacation.karoshi.com wrote: I think that starting work on such a draft is a great idea -BUT- in the mean time do not let perfect get in the way of good enough. Just to be clear: a good handful of people, me

Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]

2012-02-14 Thread Paul Vixie
On 2/14/2012 5:20 PM, David Conrad wrote: ... I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. +1. there are a lot of important non-root dns servers, and the collected wisdom of all

Re: [DNSOP] Batch Multiple Query Packet

2012-02-27 Thread Paul Vixie
On 2012-02-28 12:27 AM, Edward Lewis wrote: At 13:35 -0500 2/27/12, Hector Santos wrote: If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. One (not the only, Ohta replied with another) of the

Re: [DNSOP] Batch Multiple Query Packet

2012-02-28 Thread Paul Vixie
On 2/28/2012 3:28 AM, Hector Santos wrote: Paul Vixie wrote: ... http://nsa.vix.com/~vixie/edns1.txt. Thanks Paul. Great material. I'm just winging it at this point. First, I was focusing on the batching of related types, i.e. a protocol with new RR type but has an initial default intro

Re: [DNSOP] Batch Multiple Query Packet

2012-02-28 Thread Paul Vixie
On 2/28/2012 5:57 PM, Nicholas Weaver wrote: But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a

Re: [DNSOP] Batch Multiple Query Packet

2012-02-28 Thread Paul Vixie
On 2/28/2012 9:02 AM, Shane Kerr wrote: Paul, (Possibly my answer belongs on dnsex not dnsop, but oh well.) i've heard recently that dns is exy. http://nsa.vix.com/~vixie/edns1.txt. I think we're missing a potential great opportunity here by thinking too small. Rather than mucking about

Re: [DNSOP] 2 internet drafts relevant to DNSOP

2012-03-10 Thread paul vixie
joe, et al, your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the draft and the design are of admirable quality. as a co-author of RFC 2317 i agree that it does not suit the needs of bgp security since it seeks only to provide a method of fully naming hosts, not networks.

Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt

2012-03-30 Thread paul vixie
On 3/30/2012 10:19 AM, Ray Bellis wrote: With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: 192.168.64/18 is 1.0.m.168.192 but

Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item

2012-04-04 Thread Paul Vixie
On 2012-04-04 12:20 PM, William F. Maton Sotomayor wrote: It seems that after delivering my presentation on subsequent AS112 delegations in Quebec City, I hadn't recalled what the group thought about adopting this work as a dnsop item. So, I'm soliciting feedback on this request. I have

Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item

2012-04-04 Thread Paul Vixie
On 2012-04-04 5:05 PM, Tony Finch wrote: Joe Abley joe.ab...@icann.org wrote: On 2012-04-04, at 11:31, Tony Finch wrote: I think BIND treats NXDOMAIN replies with the wrong authority as a FORMERR. Domainers are returning positive replies which BIND does not subject to a SOA sanity check.

Re: [DNSOP] on Negative Trust Anchors

2012-04-13 Thread Paul Vixie
the information economics of this draft are all wrong. with all possible respect for the comcast team who is actually validating signatures for 18 million subscribers and is therefore way ahead of the rest of the industry and is encountering the problems of pioneers... this is not supposed to be

Re: [DNSOP] on Negative Trust Anchors

2012-04-14 Thread Paul Vixie
. an actual security incident. IOW, if we do this, we might as well just abandon DNSSEC altogether. this is what i was alluding to in some text up-thread: On 2012-04-13 5:43 PM, Paul Vixie wrote: ... i'm opposed to negative trust anchors, ... for their security implications if there were secure

Re: [DNSOP] on Negative Trust Anchors

2012-04-15 Thread Paul Vixie
On 2012-04-15 4:09 PM, Patrik Fältström wrote: On 15 apr 2012, at 16:42, Joe Abley wrote: Nobody is talking about creating NTAs. NTAs already exist. The question for this group is whether or not they are worth standardising. Fair. I am the one that extrapolate from standardizing to wide

Re: [DNSOP] on Negative Trust Anchors

2012-04-15 Thread Paul Vixie
On 2012-04-15 4:20 PM, Stephan Lagerholm wrote: ... However, the open resolvers that don't support DNSSEC are a bigger issue since the Service Providers' customer instantly can get what he believes is a better working resolver by switching to one of those. If we could convince 8.8.8.8

Re: [DNSOP] on Negative Trust Anchors

2012-04-15 Thread Paul Vixie
On 2012-04-15 7:04 PM, David Conrad wrote: On Apr 15, 2012, at 9:37 AM, Paul Vixie wrote: i'd tell validator operators who think they need NTA's in order to control the risks posed by zone owner errors, if you can't stand the heat then stay out of the kitchen. Given the benefits provided

Re: [DNSOP] on Negative Trust Anchors

2012-04-15 Thread Paul Vixie
On 2012-04-15 9:07 PM, David Conrad wrote: I guess in the end it boils down to the philosophical question of the role of the IETF. If DNSOP declines to accept this topic, I suspect it merely means each vendor will come up with their own implementation with their own quirks that operators will

Re: [DNSOP] NTA... the new NAT?

2012-04-18 Thread paul vixie
On 4/17/2012 9:51 AM, Shane Kerr wrote: Is it just me, or does the NTA discussion remind anyone else of NAT discussions? And not just because they have the same letters. ;) Operators say, wow, here is a useful tool that can solve real-world problems, maybe it would be helpful to recognize

Re: [DNSOP] NTA... the new NAT?

2012-04-18 Thread paul vixie
On 4/18/2012 6:28 PM, David Conrad wrote: ... Their validator, their rules. ... that would be a fundamental change to the architecture of dnssec. see again: http://www.circleid.com/posts/20121012_dns_policy_is_hop_by_hop_dns_security_is_end_to_end/

Re: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13

2012-04-25 Thread paul vixie
On 4/25/2012 4:58 PM, Alfred � wrote: It has been pointed out that the DNS Referral Response Size Issues I-D should not be left going to final expiry, and I have performed a new review of the last version, draft-ietf-dnsop-respsize-13. I only found a small number of remaining editorial nits

Re: [DNSOP] NTA... the new NAT?

2012-05-01 Thread paul vixie
On 5/1/2012 4:34 PM, Chris Thompson wrote: What would be needed would be a method of finding out about *all* DNSSEC trust anchors being used, both positive and negative. +1. And what about DLV? (sorry, Jim) dlv is probably wrong for this, for two reasons. first, it only engages when

Re: [DNSOP] I-D Action: draft-ietf-dnsop-respsize-14.txt

2012-06-06 Thread paul vixie
On 6/6/2012 12:48 PM, Mark Andrews wrote: ... A properly functioning resolver will request the missing glue from the root servers and named at least will return it in the additional section or set TC=1. Glue isn't supposed to be truncated according to RFC 103[45] as it is not additional

Re: [DNSOP] A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

2012-06-27 Thread Paul Vixie
On 6/27/2012 6:15 PM, Joe Abley wrote: ... Adopt this doc? yes please. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing

2012-08-30 Thread Paul Vixie
On 2012-08-30 9:40 AM, Johan Ihrén wrote: On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document

Re: [DNSOP] new version of IPv6 rDNS for ISPs

2012-11-21 Thread Paul Vixie
On 2012-11-21 4:44 PM, Ted Lemon wrote: ... Aside from this quibble, I think the document is useful and should be published. my quibble is different. ipv6 is bringing some tough love to the consumer-facing edge. the fact that ISP's auto-populated the IPv4 PTR tree made it impossible for mail

Re: [DNSOP] new version of IPv6 rDNS for ISPs

2012-11-21 Thread Paul Vixie
On 2012-11-21 6:44 PM, Andrew Sullivan wrote: On Wed, Nov 21, 2012 at 06:07:23PM +, Paul Vixie wrote: consumer grade and business grade internet connections. since consumer grade connectees should really not be connecting to SMTP servers on other networks I do not accept this premise

Re: [DNSOP] finding the closest delegation

2012-11-23 Thread Paul Vixie
On 2012-11-23 2:34 PM, Mark Andrews wrote: ... There is nothing wrong with using the SOA record from the -ve response. Named has been doing it for about 15 years in nslookup. If it is not there it falls back to stripping a label at a time until it gets the SOA record. indeed not. i think

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

2013-02-22 Thread Paul Vixie
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

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

2013-02-25 Thread Paul Vixie
... Tony Finch wrote: ... Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html paul ___ DNSOP mailing

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

2013-02-25 Thread Paul Vixie
... Paul Vixie wrote: ... Tony Finch wrote: ... Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html that message's pdf attachment appears

[DNSOP] Passive DNS - Common Output Format (draft-dulaunoy-kaplan-passive-dns-cof-01)

2014-01-15 Thread Paul Vixie
speaking for the authors of the draft below, i request adoption by dnsop. --vixie https://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/ Internet Engineering Task Force A. Dulaunoy Internet-Draft

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

2014-02-04 Thread Paul Vixie
Joe Abley wrote: ... ONION is like LOCAL. Neither are like ARPA (or any other TLD). How like LOCAL is ONION? ICANN knows it can't sell .LOCAL, but does ICANN know it can't sell .ONION ? ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS

2014-02-14 Thread Paul Vixie
Zi Hu wrote: We recently posted draft-hzhwm-start-tls-for-dns-00 (Starting TLS over DNS) to explore one proposal to add standard TLS over standard DNS to improve privacy. http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00 This topic may be of interest to DNSOP and PERPASS. Some

Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

2014-02-16 Thread Paul Vixie
Joe Abley wrote: ... If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them. reflection attacks aren't a fact of life. DNS RRL does not require a forklift

Re: [DNSOP] Passive DNS COF

2014-03-07 Thread Paul Vixie
Lawrence Conroy wrote: Hi Chaps, stupid quick question, listening to the stream: How does this work with CDNs (I think you may need to capture the IP address; bailiwick could act as a proxy for that, but ...) this is well described, as follows:

Re: [DNSOP] on the subject of dnse

2014-03-21 Thread Paul Vixie
Phillip Hallam-Baker wrote: This was the use case that originally drove the development of OmniBroker. If we do DNS Encryption right it is going to be very easy for end users to chose their DNS provider and very hard for the authorities to block them. +1. Security is a balance. Going

Re: [DNSOP] port 0 requests leading to errors

2014-03-22 Thread Paul Vixie
bert hubert wrote: ... 43.504115 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa. (38) 45.504152 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa. (38) 49.505124 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa. (38) PowerDNS now

Re: [DNSOP] port 0 requests leading to errors

2014-03-23 Thread Paul Vixie
Christopher Morrow wrote: If I have a patch which makes no sense, will you also add it? nope. not for you anyway. only mark andrews. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS over DTLS (DNSoD)

2014-04-23 Thread Paul Vixie
for reasons well-spoken up-thread, if we're going to add a dns transport, i'd like it to be RFC 6013 style TCP (in which session context can be compressed and retained after FIN for full-window-size restart, and which permits the query to be bundled into the SYN packet), or at a minimum, SCTP.

Re: [DNSOP] call to work on edns-client-subnet

2014-05-07 Thread Paul Vixie
Andrew Sullivan wrote: Dear Uncle Ben, keep it civil, please. On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote: The architectural context of a feature should not be divorced from its specification. RFC is an imprimatur. With great power comes great responsibility. I disagree

Re: [DNSOP] call to work on edns-client-subnet

2014-05-07 Thread Paul Vixie
Nicholas Weaver wrote: On May 7, 2014, at 10:23 AM, P Vixie p...@redbarn.org wrote: Joe... To clarify... Client subnet is not what I an complaining about. It's wide area rdns itself that I think is a bad idea. One reason wide area rdns is a bad idea is that it needs client subnet options.

Re: [DNSOP] call to work on edns-client-subnet

2014-05-08 Thread Paul Vixie
Tony Finch wrote: Barry Margolin pointed out an amusing interaction between two stupid DNS tricks on the bind-users list: https://lists.isc.org/pipermail/bind-users/2014-May/093171.html If you have an authoritative server with ANAME or CNAME flattening support, and the target of the ANAME

Re: [DNSOP] call to work on edns-client-subnet

2014-05-08 Thread Paul Vixie
Ralf Weber wrote: ... There is madness, but the madness is in mixing authoritative and recursive functions in one server and not in using DNS to direct traffic. while i'm on record has holding that view, it turns out that RFC 1035 does describe recursion and authority as co-residing in a

Re: [DNSOP] call to work on edns-client-subnet

2014-05-16 Thread Paul Vixie
On 5/16/14, 8:18 AM, Andrew Sullivan wrote: ... First, if resolvers have expectations about consistency of zones and so on, then they're broken. The DNS has only ever been loosely coherent. You're simply _not allowed_ to make that assumption from any point in the network except inside

Re: [DNSOP] call to work on edns-client-subnet

2014-05-16 Thread Paul Vixie
one of the icann ssac (then secsac) consensus processes i am most proud to have been part of was this, in 2004: http://www.icann.org/en/groups/ssac/report-redirection-com-net-09jul04-en.pdf indeed, this document and the process followed in creating it may still stand today, as ssac's finest

Re: [DNSOP] Extended CNAME (ENAME)

2014-05-16 Thread Paul Vixie
Mark Delany wrote: On 17May14, Mark Andrews allegedly wrote: domain ENAME domain {0|1} [type list of included / excluded types] (0 == include, 1 == exclude) As I recall, the HTTP/2.0 folks have been intermittently talking about supporting SRV. Would encouraging that group

Re: [DNSOP] Extended CNAME (ENAME)

2014-05-19 Thread Paul Vixie
Mark Andrews wrote: ... Everytime I have mentioned SRV records to HTTP folks they say it won't work as the extra lookup takes too long. this sounds strange to me. TTL=0 SRV RR's strike me as precisely what the CDN industry needs, since they can include an (or for back-compatibility, an

Re: [DNSOP] Extended CNAME (ENAME)

2014-05-19 Thread Paul Vixie
Ted Lemon wrote: On May 19, 2014, at 6:12 PM, David C Lawrence t...@akamai.com wrote: Not so much pushing required, at least of Akamai. You have a ready-made [SRV] ally in me, if only clients actually made good use of it. The clients are the real obstacle. Yup. It would be great if we

Re: [DNSOP] Extended CNAME (ENAME)

2014-05-20 Thread Paul Vixie
Mark Delany wrote: one can lookup A, and SRV in parallel and positive answer to SRV, as Paul mentioned, can have additional A and RRs. A downside is that clients has to wait for the SRV query to complete so they can be sure of the presence or not of an SRV. ... in a blast

Re: [DNSOP] Extended CNAME (ENAME)

2014-05-20 Thread Paul Vixie
Masataka Ohta wrote: Mark Andrews wrote: The reason why CNAME is prohibited at a zone apex is described in RFC 1034: If we must change something, isn't it easier to allow CNAME at a zone apex than introducing ENAME? the reasons for prohibiting it, as given in RFC 1034, still apply.

[DNSOP] rssac caucus

2014-05-31 Thread Paul Vixie
. If you would like to volunteer please kindly indicate those intentions known by sending an email to rssac-members...@icann.org. Kind Regards, Kaveh Ranjbar, RSSAC Membership Committee Chair Tripti Sinha, RSSAC Membership Committee Member Paul Vixie, RSSAC Membership Committee Member

Re: [DNSOP] rssac caucus

2014-06-24 Thread Paul Vixie
session at ICANN 50 and it was announced that first face to face caucus meeting will be held during IETF 90 in Toronto. Kind regards, Paul Vixie on behalf of RSSAC Caucus membership committee re: Paul Vixie wrote: Greetings, If you are interested in participating at ICANN's Root Server System

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

2014-06-24 Thread Paul Vixie
Tim Wicinski wrote: ... On 6/24/14 3:57 AM, Paul Hoffman wrote: My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. We as chairs do not have that mind set. My personal feeling is to figure

Re: [DNSOP] please review CGA-TSIG

2014-06-26 Thread Paul Vixie
Hosnieh Rafiee wrote: Hello, We actually put all our efforts to change the document thoroughly and not only consider the IPv4 scenario that was comment of some people in mailinglist but also we expand the DNS privacy section and explained it in more detail (no need to change the protocol.)

[DNSOP] various approaches to dns channel secrecy

2014-07-04 Thread Paul Vixie
i've now seen a number of proposals reaction to the snowden disclosures, seeking channel encryption for dns transactions. i have some thoughts on the matter which are not in response to any specific proposal, but rather, to the problem statement and the context of any solution. first, dns data

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

2014-07-05 Thread Paul Vixie
Joe Abley wrote: Hi Paul, Warren, On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome

Re: [DNSOP] various approaches to dns channel secrecy

2014-07-05 Thread Paul Vixie
Matthäus Wander wrote: * Paul Vixie [7/5/2014 5:04 AM]: datagram level channel secrecy (for example, DTLS or IPSEC) offers a solution which matches the existing datagram level UDP transport used primarily by DNS. however, the all-pervasive middleboxes (small plastic CPE devices installed

Re: [DNSOP] various approaches to dns channel secrecy

2014-07-06 Thread Paul Vixie
Matthäus Wander wrote: * Paul Vixie [7/5/2014 7:47 PM]: Matthäus Wander wrote: DTLS works on top of UDP (among others) and thus can pass CPE devices. no, it cannot. DTLS does not look something that the CPE was programmed to accept; thus in many cases it is silently dropped. DTLS can

  1   2   3   4   5   6   7   8   >