Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message <6.2.5.6.2.20130828044224.06ee3...@resistor.net>, S Moonesamy writes : > Hello, > > It's difficult, some might say impossible, to get agreement on > draft-ietf-spfbis-4408bis. I would like to ask each of you, and > anyone else, to provide your opinion about the following: > > RFC 5507 primarily raises three concerns about TXT records: > >1. The data in TXT is unstructured and subject to > misinterpretation by other >applications. > >2. Wildcard issues. > >3. Size issues. > > The draft addresses (3) by discussing size considerations, and > tangentially addresses (1) in Section 3.4. > > I would like to ask everyone not to turn this into a debate by not > discussing about the opinion stated by someone else. > > Regards, > S. Moonesamy (as document shepherd) I would start by saying that the list of issues identified by RFC 5507 is not complete. RFC 5507 addresses selection of data to be returned by the nameserver. It fails to address the issues of updating data in the server using RFC 2136 + RFC 2845. For prefix, suffix and a new types this is pretty straight forward as you have a tuple that is unique to the application and nameservers have access control mechanisms that are designed to allow / disallow updates at this level so you can hand out the ability to update records without having unintended consequences. When you place selectors inside records which have a shared purpose you lose the ability to hand out selective update without risking unintended consequences or you require nameserver vendors to develop new access control mechanisms which work on the record contents in addition to the tuple. You can't say delete all records of this type at this name then add this replacement set in a single transaction. It becomes read the data at the tuple, workout what to delete, send a update message that selectively deletes then adds records. This introduces race conditions etc. As for wildards. Spf is often used to say that names generated by wildcards do not send email. This essentially precludes the use of a prefix. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Fwd: Re: [dnsext] Deprecating SPF
--- Forwarded Message To: Michael Richardson From: Mark Andrews References: <20130819222037.ga55...@mx1.yitter.info> <20130822184610.2640.qm...@joyce.lan> <20130822212337.b37a838cb...@drugs.dv.isc.org> <5559.1377478...@sandelman.ca> Subject: Re: [dnsext] Deprecating SPF In-reply-to: Your message of "Sun, 25 Aug 2013 20:56:40 -0400." <5559.1377478...@sandelman.ca> Date: Tue, 27 Aug 2013 07:56:55 +1000 In message <5559.1377478...@sandelman.ca>, Michael Richardson writes: > > Mark, I think that the ietf@ietf.org readers (myself included) might be > confused by how your message about lame ccTLD delegations relates to > "Deprecating SPF" Part of the reason the spf wg wants to deprecate SPF is that there are nameservers or nameserver/loadbalancer or nameserver/firewall combinations that drop SPF queries. The failure to respond causes more timeouts in processing than there are with TXT records. These are not traditional lame delegations. The servers still respond the A queries. They sometimes respond to other queries. These two queries were done straight after each other. ; <<>> DiG 9.10.0pre-alpha <<>> cnrs-orleans.fr @admin.cnrs-orleans.fr spf +norec ;; global options: +cmd ;; connection timed out; no servers could be reached ; <<>> DiG 9.10.0pre-alpha <<>> cnrs-orleans.fr @admin.cnrs-orleans.fr a +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64936 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cnrs-orleans.fr. IN A ;; AUTHORITY SECTION: cnrs-orleans.fr.7200IN SOA admin.cnrs-orleans.fr. Postmaster.cnrs-orleans.fr. 2013082001 21600 3600 360 7200 ;; Query time: 413 msec ;; SERVER: 163.9.1.2#53(163.9.1.2) ;; WHEN: Tue Aug 27 07:55:08 EST 2013 ;; MSG SIZE rcvd: 97 Then there are the servers that don't return the correct NS RRset and/or don't return the correct SOA record with negative answers. Testing for NS keeps one withing the RFC 103[45] set of types. Note the correst SOA record should be for 2957.com. I have in the past received email proporting to be from 2957.com which is why it is in my test set. ; <<>> DiG 9.10.0pre-alpha <<>> 2957.com spf @ns1.dsredirection.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5484 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;2957.com. IN SPF ;; AUTHORITY SECTION: com.3600IN SOA ns1.dsredirection.com. hostmaster.oversee.net. 2013060601 43200 7200 1209600 3600 ;; Query time: 238 msec ;; SERVER: 204.13.160.143#53(204.13.160.143) ;; WHEN: Tue Aug 27 07:29:55 EST 2013 ;; MSG SIZE rcvd: 113 they do actually respon to the NS query though the record come from a wildcard delegation. Note the lack for "aa". ; <<>> DiG 9.10.0pre-alpha <<>> +norec 2957.com ns @ns1.dsredirection.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31997 ;; flags: qr; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;2957.com. IN NS ;; ANSWER SECTION: 2957.com. 3600IN NS ns1.dsredirection.com. 2957.com. 3600IN NS ns2.dsredirection.com. ;; ADDITIONAL SECTION: ns2.dsredirection.com. 7200IN A 204.13.161.145 ns1.dsredirection.com. 7200IN A 204.13.160.143 ;; Query time: 183 msec ;; SERVER: 204.13.160.143#53(204.13.160.143) ;; WHEN: Tue Aug 27 07:34:51 EST 2013 ;; MSG SIZE rcvd: 119 Mark > Mark Andrews wrote: > > Part of the question is whether the IETF is going to work with ICANN, > > IANA and the ccTLD to audit delegations for servers that are not RFC > > 103[45] compliant and suspend delegations where the servers are not > > compliant. > > > * no responding to queries based on query type > > * not having a NS rrset at the delegation point > > > Enforcing that ccTLD and ICANN TLD regularly audit delegations and have > > mismatches corrected. This is REQUIRED by RFC 1034 in part to stop the > > sorts of problems we are seeing today. > > > We don't have to put up people putting up misconfigured / broken > > servers. > > > For the non responding servers I have written > > draft-andrews-dns-no-resp
Re: [dnsext] Deprecating SPF
Part of the question is whether the IETF is going to work with ICANN, IANA and the ccTLD to audit delegations for servers that are not RFC 103[45] compliant and suspend delegations where the servers are not compliant. * no responding to queries based on query type * not having a NS rrset at the delegation point Enforcing that ccTLD and ICANN TLD regularly audit delegations and have mismatches corrected. This is REQUIRED by RFC 1034 in part to stop the sorts of problems we are seeing today. We don't have to put up people putting up misconfigured / broken servers. For the non responding servers I have written draft-andrews-dns-no-response-issue to try to capture the issues. It was on the dnsop agenda for Berlin but didn't get covered as time ran out. I would like everyone to read it and comment on it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message <0c3746c3-dac1-471f-bd07-8faf20481...@email.android.com>, Scott Kitterman writes: > > > Mark Andrews wrote: > > > >In message <20130821214832.1c92538c0...@drugs.dv.isc.org>, Mark Andrews > >writes: > >> > It's primarily an issue for applications. To the DNS, it's exactly > >what it > >> > is, a TXT record. > > > >I can hand update of A and records to the machine. > >I can hand update of MX records to the mail adminstrator. > >I can hand update of SPF records to the mail adminstrator. > >I can hand update of TXT records to ?? > > No one because it has multiple uses. This is true whether SPF exists or not. > SPF use of RRTYPE TXT for SPF records mak > es that neither better nor worse. > > You could publish: > > example.com IN TXT v=spf1 redirect=_spf.example.com > _spf.example. com IN TXT v=spf1 [actual content here] > > Then delegate _spf.example.com to the mail administrator. Problem solved. No, it is NOT solved. You have to trust *everyone* with the ability to update TXT not to remove / alter that record. You can't give someone you don't trust the ability to update TXT. With a published SPF record and SPF lookup first stopping on success or lookup failure (SERVFAIL) you can give update control of TXT to someone you don't trust enough to not remove / alter the SPF TXT record. You keep telling us the TXT is just another record in the DNS. Well the DNS is managed at the granuality of the TYPE. 4408bis is forcing sub-type management to be developed and deployed to maintain the status quo. TXT is no longer "just another record in the DNS" with 4408bis as it currently stands. And to Google your motto is "Do No Evil". Publishing a TXT SPF record without publish a SPF SPF record is "Evil" as it encourages other to do the same. Mark > Scott K -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message <20130821214832.1c92538c0...@drugs.dv.isc.org>, Mark Andrews writes: > > It's primarily an issue for applications. To the DNS, it's exactly what it > > is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message <7917527.VmCQD3a6Q3@scott-latitude-e6320>, Scott Kitterman writes:
> On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
> > I object to the removal of the SPF record.
>
> This is not a shock. You were in the rough when we discussed it in the WG
> too.
>
> > Name servers already have access controls down to the granuality
> > of TYPE. If this draft proceeds as currently described it is forcing
> > name server vendors to access controls at the sub TYPE granuality.
>
> It's primarily an issue for applications. To the DNS, it's exactly what it
> is, a TXT record.
No. It isn't. By overloading TXT you prevent thing like this which
existed before SPF was even dreamed up.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net SPF
grant key-two domain example.net ANY
};
or
update-policy {
grant key-one subdomain example.net ANY
grant key-two domain example.net TXT
};
Overloading a type is bad on so many levels which is why it was
argued that SPF needed its own type. TXT is good for prototyping
and that is about all.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net ANY
};
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net TXT!v=spf1
};
> > With SPF lookup first I can specify the SPF policy using SPF and
> > leave TXT free for other uses without having to worry about the
> > records being misinterpeted.
>
> Unless you have some specific reason to be concerned about accidentally
> starting an unrelated TXT record with "v=spf1 ", I can't imagine you don't
> have more important things to worry about. This being a "problem" is a great
> theory, but it just doesn't happen in practice.
It's about being able to hand someone update control and not having to
worry about them stuffing up the SPF records.
> > SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF.
> > This is similar to not proceeding to A/ lookups on MX lookup
> > failures.
>
> Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain
> that has an actual SPF record due to various operational issues. SERVFAIL on
> type SPF doesn't reliably tell you anything about what a type TXT lookup
> would
> produce. So it's similar, but only superficially so.
And the worst that happens is that you let some *additional*
potentially spoofed email through. This WG seems to treat this
as a catastrophic errror when it isn't. This whole debate is
because this working group treats not stopping one additional
forgery as a catastrophic errror.
Note also that it will be the publishing site to blame for having
a non RFC 1034 compliant server (it didn't respond to SPF queries)
or misconfigured zone (returns wrong SOA in the negative response
which can't happen when they have a SPF record).
> > I would also suggest that there be a sunset date published for the
> > use of TXT for SPF.
>
> Do you also suggest creation of an Internet police force to enforce this?
> What would be be mandatory minimum sentence?
You just code the cut off date into the code that does the verification
and stop making TXT queries. You code the date into the code that
checks for missing SPF records and change the complaint.
> Scott K
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
I object to the removal of the SPF record. Name servers already have access controls down to the granuality of TYPE. If this draft proceeds as currently described it is forcing name server vendors to access controls at the sub TYPE granuality. With SPF lookup first I can specify the SPF policy using SPF and leave TXT free for other uses without having to worry about the records being misinterpeted. SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF. This is similar to not proceeding to A/ lookups on MX lookup failures. I would also suggest that there be a sunset date published for the use of TXT for SPF. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] prefixed names, was Last Call:
In message <20130820144548.73129.qm...@joyce.lan>, "John Levine" writes: > Newsgroups: iecc.lists.ietf.ietf > From: John Levine > Subject: Re: [spfbis] prefixed names, was Last Call: is-19.txt> > Summary: > Expires: > References: <5212fcef.80...@dcrocker.net> <55459829-933F-4157-893A-F90552D444 > 1...@frobbit.se> <5213174d.7080...@dcrocker.net> > 0d01...@frobbit.se> > Sender: > Followup-To: > Distribution: > Organization: > Keywords: > Cc: > Cleverness: some > > >The two following MIGHT NOT be in the same zone: > > > >foo.example. IN X RDATAX > >_bar.foo.example. IN TXT RDATAY > > Since prefixed names have never been used for anything other than > providing information about the unprefixed name, what conceivable > operational reason could there be to put a zone cut at the prefix? When you have "_users" and you want to move the users out of the hosts namespace and have whom ever deals with people manage that part of the namespace. > This impresses me as one of those problems where the solution is > "don't do that." There are good reasons to split off administrative control. "don't do that" isn't a answer. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message <20130820022209.ga56...@mx1.yitter.info>, Andrew Sullivan writes: > Again, I'm not the shepherd on this, but I was involved in the > consensus call in the WG when we determined that the WG wanted to > deprecate use of RRTYPE 99. (Note that this "deprecation" means just > that users of SPF stop publishing that record. There's nothing in the > draft to remove the RRTYPE, as that would be absurd.) Recommending that people not publish RRTYPE 99 does not address the problem. You need to forceable stop people using RRTYPE 99 or you need to continue the migration by deploying more software that looks up type SPF then type TXT if SPF is not available. Those are the only solutions to the so called problem of publishers and checkers not interoperating with each other. > On Tue, Aug 20, 2013 at 11:27:25AM +1000, Mark Andrews wrote: > > Deployment is happening. More and more SMTP servers > > are making SPF requests before TXT requests. > > I think those are the two central premises that are up for dispute. > RFC 6686 made the determination about the former claim, and therefore > that premise is not up for debate: deployment appears not to be > happening. If people wish to argue with the conclusions of RFC 6686, > that's fine, but it seems that one at least needs to write an > anti-6686 document in that case. The draft currently up for last call > is relying on the conclusions of RFC 6686 as a premise, and is not > itself arguing whether RRTYPE 99 deployment is or is not happening. When you only do a point measurement and don't have any long term trends the data is meaning less. Lots of zones were setup pre RFC 4408 with no campain to transition them to RFC 4408 status. Similarly it takes several years for new support to make its way into production. You have to write the libraries. You have to integrate the new libraries into the servers. You have to get those servers deployed which is often only done on hardware replacement. > The fact that SPF processors are making SPF queries before TXT queries > is in fact part of the reasoning for why RRTYPE 99 ought to be > deprecated. If many clients make a query and only a tiny number of > zones have that type published (or are likely ever to publish the > type), it's simply wasteful to continue using that type. If this > seems a familiar line of argument, it's because it's one you see in > the spfbis list archives when this issue was decided by the WG. So the solution is to educate. The long term goal is to get to type 99 only. The complaints about delays could be removed with draft-wkumari-dnsop-hammer and addressing the bigger problem of broken nameservers draft-andrews-dns-no-response-issue or have TLD operators actually do what was requested of them in RFC 1034 and periodically CHECK delegations which would address some of misconfiguration issues. > > Note it doesn't help that companies charge extra to support SPF > > over TXT as you well know. > > I'm not sure whether that's supposed to be a swipe at my employer, but > just so we're clear: Dyn (my employer) supports the SPF RRTYPE in its > enterprise-focussed offerings. There's no extra charge. There is a extra charge over basic support which support A, , CNAME, MX, TXT, SRV, NS, LOC, PTR compared to the premium product which supports A, , CERT, CNAME, DHCID, DNAME, DNSKEY, DS, IPSECKEY, KEY, KX, LOC, MX, NAPTR, NS, NSAP, PTR, PX, RP, SOA, SPF, SRV, SSHFP, TXT. http://dyn.com/dns/dns-comparison/ > The front end for the basic DNS service (many people know this as > DynDNS or Dyn's Standard DNS or other such trade names) is intended to > be simple and self-service. It's cheap, and the margins don't allow > us to provide a lot of personalized support. Dyn found that people > who were good candidate customers for that self-service system knew > how to do things with TXT, did not know about or care about the SPF > type, and were confused by having two types for one purpose. For > practical purposes, it was necessary to support SPF over TXT (since > some clients didn't check the SPF type). So, one type it was, and TXT > at that. This all happened long before I worked at Dyn, but I assure > you that the commercial pressure for adding TYPE 99 support to the > basic platform (actually, it's just the front end) is just as > non-existent today as it was when that decision was made. So rather than do what RFC 4408 said to do and support the SHOULD Dyn made it impossible for the non enterprise customer to do RFC 4408 properly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message <20130819214139.gb19...@mx1.yitter.info>, Andrew Sullivan writes: > I'm not going to copy the spfbis WG list on this, because this is part > of the IETF last call. No hat. > > On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote: > > On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker wrote: > > > > From earlier exchanges about this concern, the assertion that I recall is > > > that 7 years is not long enough, to determine whether a feature will be > > > adopted. > > > What is the premise for seven years being "not long enough"? And what does > > constitute "long enough"? And upon what is that last answer based? > > I have two observations about this. First, EDNS0, which is of > significantly greater benefit to DNS operators than the mere addition > of an RRTYPE, took well over 10 years to get widespread adoption. > Second, we all know where IPv6 adoption stands today, and that has > certainly been around longer than 7 years. So I think it _is_ fair to > say that adoption of features in core infrastructure takes a very long > time, and if one wants to add such features one has to be prepared to > wait. > > But, second, I think all of that is irrelevant anyway. The plain fact > is that, once 4408 offered more than one way to publish a record, the > easiest publication approach was going to prevail. That's the > approach that uses a TXT record. Except you are trying to unring a bell. The SPF type exists and is supported in nameservers, resolver libraries and in SPF specific libraries. Support is integrated into SMTP servers. Basically it is all there. Deployment is happening. More and more SMTP servers are making SPF requests before TXT requests. There was no rush to migrate to the new type. Suddenly there is a "oh we have not moved fast enough" so we need to abandon the migration for lots of really spurious reasons. * RFC 4408 allows to publish records that might not be read by a client. This isn't actually bad. At some point you have to drop support for legacy users. RFC 4408 *allows* this to happen. The worst that happens is a forgery isn't detected but we don't guarentee to stop all forgeries. * SPF and TXT records may get out of sync. If we really need to do something about this we can request that nameserver vendors keep these records in sync but in reality the SPF record will be the one that get used more and more and TXT record will not be looked up at all if we just let the migration continue. * SPF lookups fail or are slow. So do TXT lookups. Most of these are due to misconfigured nameservers that return the wrong SOA record as they are configured to server a parent zone rather than the delegated zone or load balancers which are not RFC 1034 compliant as they don't respond to anything other than a limited set of types. * Nameservers don't support SPF. Most currently shipping nameservers do support SPF and have for years. Some OS vendors are slow to pickup new nameservers which doesn't help. Of those that don't support SPF moving from experimental to standard will/should help with getting the support added. * Resolver libraries don't support SPF lookups. Such libraries are not RFC 1034 compliant as support for lookups of unknown types is a explictly listed requirement. Most resolver libraries are capable of looking up unknown types though they can only present them as a blob of data. * Registrars don't support type SPF records. Shop around there are those that do. TXT was described as legacy in RFC 4408. The spf specific libraries look for SPF first then TXT if a SPF RR is not present which is exactly what you would expect when TXT is described as legacy. You also have a problem that "SPF record" means two things if we stop the migration. The TXT record with "v=spf1" at the start and the type SPF record that is deprecated. There are other problems like undoing all the changes to support type SPF. You need to modify all the servers that now support SPF to warn / fail to load if they see a SPF record in a zone. Note it doesn't help that companies charge extra to support SPF over TXT as you well know. RFC 4408 treated the SPF type as a foot note. All the examples were done using TXT not SPF with the exception of the single example showing identical TXT and SPF records. When all the examples are done with TXT how do you expect people to know that they should be using type SPF? Lots of people were not aware of the SPF type. Named now warns when both TXT and SPF versions of SPF records are not present and it could be made into a failure unless the test is explicitly downgraded to a warning or disabled. The code could also be extended to enforce consistancy between the two types of records when
Re: Faraday cages...
In message , George Michaelson writes: > > When next you walk into a target or big W, ask to see the conditions of > entry. Along with implied consent to have your bags checked at any time, > you have probably given consent to be video'ed and tracked at their behest. > The poster is on the wall somewhere usually. Your statutory rights cannot > be abrogated but equally, the grey areas have been 'informed'. You expect to video'ed and bag checked for stock loss prevention. There is no implied consent for anything else. You don't need to track mobile phones for stock loss prevention. > BT tracking inside the store is passive collection of data you are > radiating. The store's use of the BT location and timing of presence > against shelves is private information of immense value to them. They share > it for mutual benefit with suppliers, or for money. I doubt they give much > away. > > The large international scroogle rhyming company was compiling third party > uses of the data to inform location as a service, and were not solely > collecting information inside their own physical territory you entered, > with implied consent: they were harvesting data in the public space and > then providing insight into that data into the public space. > > They relate because its harvesting RF. They don't relate in much else to my > mind. The main difference is the levels of encryption used in the two standards. For WiFi there are still a large percentage of networks sending in the clear. For BlueTooth there were no non-encrypted channels in the base spec (1.0) support for them was added in 1.1 [1]. With BlueTooth you get presence. With WiFi you get presence + data Mark [1] http://en.wikipedia.org/wiki/Bluetooth#Bluetooth_v1.1 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Bringing back Internet transparency
In message <20130801191438.c027718c...@mercury.lcs.mit.edu>, Noel Chiappa write s: > > From: Phillip Hallam-Baker > > > The ISPs had a clear interest in killing of NAT which threatened the > > ISP business model. > > So this is rather amusing: you're trying to tell me that ISPs wanted to kill > NAT, and I have other people telling me NAT was an intergral part of ISPs' > master plan to take over the universe. > > Clearly you all both can't be right. They want the extra dollars for extra address but the don't want the support costs that would bring. They sit at different points for different sets of customers. > Noel -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The case of dotless domains
In message <20130716150721.gg29...@mip.a.org>, Ofer Inbar writes: > > >>What this brings to mind is that we used to have implicit DNS domain > > >>search in the early days of DNS. When edu.com accidentally hijacked > > >>a huge chunk of the Internet, most of the net very quickly got rid of > > >>implicit search, and we got the explicit DNS search feature that many > > >>people are discussing now. > > > > > >Yes. > > > > Can you (or Ofer) define how you're using the terms "explicit" and > > "implicit" in terms of DNS search, and what their relevance is to the > > topic of dotless domains? And no, I'm not being snarky, I think part of > > the problem here is a fundamental misunderstanding of how the vast > > majority of hosts are configured currently. > > You're not being snarky, but that indicates that you seem to have > missed my point, which is not about the technical details of how > domain search got changed after the edu.com disaster. My point is > not to make a direct parallel between how domain search changed, and > dotless domains, and you seem to be looking at it in that light. > > What this brings to mind is that we had a DNS system that was > vulnerable to the addition of something to the DNS that people had > expected nobody would make the mistake of doing, but it happened and > caused damage, and the net reacted by altering how DNS software works > in order to protect against that damage. At the time, the obvious > defensive change was "don't do implicit domain search". If dotless > domains cause damage as many people here predict, what I'm saying is > that I think we'll react similarly, and that I guess the defensive > change people will widely deploy is to reject A//MX records at > the top level. > > You really do not need to drill into the specifics of the change from > implicit to explicit domain search in reaction to edu.com, in this > context. So it sounds to me like you have something quite different > in mind. I don't know what you think I was trying to say - it's not > anything I said explicitly, so perhaps you think I was trying to > subtly say something between the lines. To be clear: I wasn't. > -- Cos It was more than implicit to explicit. It was also trying domains with dots "as is" first. Domains with perids were treated as fully qualified until proved otherwise. Unqualified domains were qualified then tried "as is" if a match was not found. It is bad to treat domains with periods as partially qualified. It is bad to treat domains without periods as qualified. Note it is also more than A, AAAA and MX record at the tld label. It is also SRV records where they are used with a base name in a host context. _http._tcp.tld/SRV is equally bad as tld/A where as _whois._tcp.tld/SRV would not be a issue as it would point to the whois service for names that end in .tld. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Last Call: (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
In message , Randy Bush writes: > > Given that this document was revved twice and had it's requested status > > change during IETF last call in response to discussion criticism and new > > contribution I am going to rerun the last call. > > the recent changes resolved my issue. thanks joe and joel. > > randy I have read -05 and in my opinion it is good to go.o Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Content-free Last Call comments
In message <8d23d4052abe7a4490e77b1a012b6307751cf...@mbx-01.win.nominum.com>, T ed Lemon writes: > On Jun 10, 2013, at 7:21 PM, SM wrote: > > I agree that one-line statements are not of much use. It's more tedious = > to write a statement to support a proposal than an objection to it. Non-si= > lent Last Calls usually draw objections. It's going to be difficult to bal= > ance that if one-line statements of support (or objections) are not conside= > red in a determination of consensus. > > Determining consensus in an IETF last call is a bit more complicated than t= > hat. It's not a working group last call. If someone objects to publicat= > ion during IETF last call, and their objection has already been discussed a= > nd addressed in the working group, the objection in IETF last call doesn't = > break that consensus. Which breaks some of the reasons why we do IETF last calls. WGs do get too focused on a problem and do fail to do a balance response to problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Hugh Daniel has passed away
In message , =?iso-8859-1?Q?Pa trik_F=E4ltstr=F6m?= writes: > Oh... > > What to say, what to add? > > Patrik -- sad Sad indeed. Just used one of those key chain lights the other day. Mark > On 5 jun 2013, at 00:32, Paul Wouters wrote: > > >=20 > > Hugh Daniel passed away on June 3rd after what appears to have been a = > heart attack. > >=20 > > https://nohats.ca/hugh-of-borg.jpg > >=20 > >=20 > > Those who met him, know him. Principled to the core, and very present = > in > > any room, he compelled people to listen to him - both by what he said, > > and how loud he said it. > >=20 > > He has made many contributions during the early days of IPsec and > > DNSSEC. He was a manager of the FreeS/WAN Project for many years and > > co-founder of The Openswan Project and recently The Libreswan Project, > > although his health prevented him from being as active and he wanted = > to > > be in the last two years. > >=20 > > I met him for the first time at the CCC summer conference in 1999. Our > > car had broken down, and everyone around me suggested to find Hugh = > Daniel > > for help. He shone his freeswan photon light under the car, diagnosed > > the problem, and put in a quick fix we could carefully drive to a = > repair > > shop at 5km/h where we could tell the mechanic what to fix. We started > > talking about Linux, crypto and he recruited me for the FreeS/WAN and > > the goal to make the default mode of the internet encrypted. It is = > what > > started me on IPsec, Opportunistic Encryption and DNS(SEC). In 2003, > > he brought me to my first IETF in Vienna. > >=20 > > Hugh, you are still causing a difference and we will raise a = > non-aloholic > > drink in your honour when we have reached the universal deployment > > of encrypted communication for everything. > >=20 > >=20 > >=20 > > "When you're NAT on the net, you're NOT on the net" -- Hugh = > Daniel > >=20 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IETF Meeting in South America
In message <51a4e625.3020...@gmail.com>, Melinda Shore writes: > On 5/28/13 6:20 AM, Christian O'Flaherty wrote: > > Probably, this lack of social interaction in our region is one of > > the main reasons for low participation. Most of latin american > > IETFers are currently living outside the region and they engaged in > > the IETF when living in the US or Europe. It's difficult to be > > involved when no one else around is working in it or think it doesn't > > fit well in their current work. A physical meeting will help to > > "demystify" the IETF, making it "accesible" from a professional > > perspective. > > Any sense of why that didn't happen with Australians after > the Adelaide meeting? Adelaide is a small city. If you were picking Australian cities to promote local interaction Adelaide would be the 4th-6th city you would choose. Melboure, Sydney and Brisbane are the top 3 with some debate about the order. > I'm not opposed to meeting in South America but there have > been an awful lot of assertions about this or that happening > if we do, without a lot of supporting evidence. History, > unfortunately, doesn't support many of these assertions, and > I think beating the meeting location question to death is > at least some small distraction from trying to get at the core > issues. > > For whatever it's worth, I was participating on IETF mailing lists > well before attending a meeting. Granted, I'm a native English > speaker and wasn't dealing with that as an issue but probably > more to the point was that there was work going on in the IETF > that directly impacted work I was doing myself. > > Melinda -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
In message <9506594e9e3cb989afbc0...@jck-hp8200.jck.com>, John C Klensin writes: > > > --On Wednesday, May 22, 2013 12:29 + Yoav Nir > wrote: > > >> Occasional fantasies about IETF enforcement power and the > >> Protocol Police notwithstanding, it seems to me that, if one > >> wanted to require standards-conforming nameservers, the most > >> (and maybe only) effective way to do that would be > >> requirements in the contractual agreements between TLD > >> registries and their registrants. Recursively applying > >> requirements down the tree is not a new idea; RFC 1591 uses > >> that language more than once. > > > > We should be careful about requiring things like this (for > > whatever value of "we"). Recursively applying requirements > > means that "we" are requiring service providers (in this case > > registries) to pick fights with their customers. So instead of > > having an IETF protocol police, "we" expect service providers > > to act as local sheriffs. > >... > > Seems like a tough sell to me. > > Actually, I was thinking about something a little different (and > should have been more explicit). > > I wouldn't suggest trying to mandate anything top-down. If > nothing else, ICANN's track record for being able to enforce its > mandates is very poor (and that is arguably a good thing). Asking people to run a nameserver which "responds" to queries isn't unreasonable by any stretch of the imagination regardless of their economic circumstances. The nameservers that people used in the 1980's did this correctly. The default nameservers on general purpose OS as shipped for the last 2 decades have done this correctly. This includes free and commercial operating systems. The one exception I am aware of is a Windows release where the server responds to the first EDNS query but not to subsequent EDNS queries. This only becomes a issue when the first response is lost or multiple recursive servers share the same IP address. Microsoft has fixed this issue in later releases. I am not sure if there is a service pack that fixes this. Requiring vendors to supply fixes to code that was never "fit for purpose" regardless of its age is also reasonable. > On > the other, we talk a lot about reputations and the advantages of > end sites being able to base policies on them. If whatever the > actual restrictions that, according to Stephane, forbid TLDs > from imposing "we require you to have a competent nameserver and > will test" were removed then, especially with the coming huge > increase in TLDs, it would make it possible for registries to > compete on the degree to which they wanted to offer assurances > of quality DNS servers and services in subsidiary zones. > Would-be registrants who didn't want to play would have the > option of finding TLDs who did not have those restrictions. > That would create a new opportunity for enhanced competition and > differentiation among TLDs (which ICANN presumably favors along > with favoring security and stability) and would create a basis > for some DNS server certification activities (and even a > business model for them). > > No mandate from the top, just elimination of whatever > restrictions now prevent registries from insisting on quality > operations in registrants if they wanted to. > > It wouldn't get us to "everyone has to run a conforming server" > --which I consider impossible as long as producing > non-conforming servers is legal with governments enforcing the > rules if servers don't conform (and I really don't think we > want to go there)-- but it would at least give a resolver an > indication of where conforming ones were guarantees and what > responses or non-responses they couldn't trust. > > john > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
In message <6.2.5.6.2.20130522123025.0b3ef...@resistor.net>, SM writes: > At 05:56 22-05-2013, Moriarty, Kathleen wrote: > >providers. While tying this to contracts seems like a good idea, > >that is out of our hands at the IETF. If we went down the path of > >enforcement through contracts, I wouldn't view this as picking > >fights, but rather a proactive service to 'help' customers. Having > > said that, I think if we can improve the applications that > > generate their DNS files, it would be more effective long > > term. While some teams are technical enough to validate their own > > DNS, others prefer more full service applications. > > > >Maybe a review of existing applications would be helpful for the > >community? I just see the following on Wikipedia: > >http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software > >and > >http://en.wikipedia.org/wiki/DNS_management_software > > > >How about adding a column for compliance to RFCs? Or a description > >that makes people > > RFC 1035 is updated by 24 RFCs. There are a few errata which has > been filed. The topic says "standards complaint". Which standard(s) > does that refer to? I read "compliance to RFCs", which RFCs does the > implementation have to comply with? RFC 1034 and RFC 1035 I've tried to capture the reason why I started this thread in: http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-01 Basically nameservers are supposed to reply to queries directed at them. RFC 1034 and RFC 1035 have enough error codes that you should be able to reply to every query sent to them. You don't have to return the data. You don't even have to understand the query. You do have to respond. So if the message is 12 octets or bigger and the QR bit is set to 1 you should be able to respond. RFC 1034 and RFC 1035 have a response code for *every* possible message you receive. > It has been mentioned [1] on this mailing list that: > >"But there was no energy to get the work done and the drafts languished > for months without any changes. It still seems a worthwhile project, > but there is no evidence that we have a population interested enough > to do the work." > > If the IETF discusses about contracts the discussion will evolve into > turf wars (an acrimonious dispute between rival groups over territory > or a particular sphere of influence). The interesting point in the > message (quoted above) is about providing information so that people > can assess what's good or bad. In my opinion it's doable (note that > I am leaving out a few minor details :-)). > > At 07:00 22-05-2013, John C Klensin wrote: > >I wouldn't suggest trying to mandate anything top-down. If > >nothing else, ICANN's track record for being able to enforce its > >mandates is very poor (and that is arguably a good thing). On > > :-) > > >the other, we talk a lot about reputations and the advantages of > >end sites being able to base policies on them. If whatever the > >actual restrictions that, according to Stephane, forbid TLDs > >from imposing "we require you to have a competent nameserver and > >will test" were removed then, especially with the coming huge > >increase in TLDs, it would make it possible for registries to > >compete on the degree to which they wanted to offer assurances > >of quality DNS servers and services in subsidiary zones. > > Yes. I gather that domain name are registered to advertise services > and that these services rely on working nameservers. > > I was reading the following [2] (the reader is cautioned against > drawing hasty conclusions): > >"AFNIC (The sole registrar of .fr domains) does not follow the > ICANN policies > for name server queries." > > Here's a gem: > >"Other registrars are fully able to query our name servers on TCP port 43 >(the ICANN required port)." > > Nameservers hosting Icelandic domains (.IS domains) must comply with > requirements [3]. > > More reading [4]: > >"The .DE registry has certain requirements for nameservers that > can be applied > to .DE domains. Some of those requirements are that the > nameserver IP addresses > must be in separate class C networks, and that the nameserver > must provide SOA." > > For .NL domains, the nameservers must comply with the registry > requirements [5]. > > People put more effort and money in trademarking strings than making > the strings work. > > Regards, > -sm > > 1. http://www.ietf.org/mail-archive/web/ietf/current/msg79409.html > 2. https://my.bluehost.com/cgi/help/536 > 3. http://www.isnic.is/en/host/req > 4. http://www.namecheap.com/support/knowledgebase/article.aspx/294/ > 5. http://www.opensrs.com/docs/opensrsrwi/nl_dns_requirements.htm > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
In message <20130521090727.gb17...@nic.fr>, Stephane Bortzmeyer writes: > On Tue, May 21, 2013 at 10:26:39AM +1000, > Mark Andrews wrote > a message of 52 lines which said: > > > I'm not sure what the solution should be but regular audits of > > delegated nameservers by infrastructure operator and removal of > > delegations after a grace period > > Let's not reinvent the wheel: I suggest to first study the experience > of the TLD which did exactly that. .fr had mandatory technical tests > of the name servers almost from its inception, until december > 2012. The tool used for the tests was Zonecheck > <http://www.zonecheck.fr/> > > Although these tests certainly contributed to the good technical > quality of the name servers, they were removed both for commercial > reasons (a registry has to make money to pay its employees) and > because it was easier to have the same rules for ccTLDs and gTLDs (and > ICANN forbids these technical tests in gTLDs). Which is one of the reasons I wanted to IESG to bring ICANN into the discussions. It need to be a level playing field applied to everyone. Not also this is not checking the delegation. It is checking to nameserver implementation. All ICANN documents I have read presume that a RFC compliant nameservers are being deployed. Nameservers that fail to respond are not RFC compliant. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
Keith asked for a ID. Filename:draft-andrews-dns-no-response-issue Revision:00 Title: A Common Operational Problem in DNS Servers - Failure To Respond. Creation date: 2013-05-21 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-andrews-dns-no-response-issue-00.txt Status: http://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue Htmlized: http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-00 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
In message <519ad17d.8040...@network-heretics.com>, Keith Moore writes: > It seems like a first step might be to set up a web page and/or write up > an I-D with > > a) a description of the problem > b) documentation a procedure and/or code that can be used to test name > server software for compliance > c) recommendations for zone operators that delegate to other zones > > The next step might be for TLD operators to encourage the TLD registrars > to (a) inform their customers of this issue, (b) test their customers' > servers, and report the test results to their customers. Ideally those > registrars would be able to refer their customers to updated or improved > servers. Ack. > Longer term it might be appropriate to do some other things, like > a) define standard tests for compliance > b) define a mechanism by which a server could be queried to find out its > implementation name, version, etc. > > Keith > > p.s. I wonder if the problem you describe might at least partially be > caused by DNS proxies and interception proxies, including but not > limited to those incorporated in consumer-grade routers. When the problems exist on the nameservers of Fortune 500 companies nameservers it isn't consumer-grade routers. It is badly designed nameservers or their load distributing front ends. This is similar to the name error issue a nameserver vendor had when responding to unknown types (e.g. ) in the past. The BBC's nameservers were a prime example at the time (now fixed). They returned name error for a existing name (www.bbc.co.uk from memory). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
In message <7e5b1b3d-8af1-4ffe-bda2-47efb6d35...@vpnc.org>, Paul Hoffman writes: > On May 20, 2013, at 6:23 PM, Mark Andrews wrote: > > > > > In message <6a13ceb4-8906-4ec5-9210-571d5474e...@isi.edu>, manning bill > writes: > >> I believe that there are a couple of problems with this plea. > >> > >> 1) - The IETF has -never- tested for or assured compliance with their > >> document series. > > > > Which has what to do with requesting that a known problem get fixed? > > One has to test for compliance in order to determine if the problem > exists in a particular implementation. It doesn't have to be the IETF that does the testing. In fact the IETF doesn't have access to the list of servers that need to be tested however the operators of the parent zones do. Alternatively it can be done on a piecemeal basis by examine logs and then looking up whois entries and complaining that the nameservers are causing operational problems to the operators, the complaining to the parent zone, then complaining to the courts when the parent zone operators fail to take action as directed by RFC 1034. > > One that is clearly caused by nameservers operating outside the > > expected behaviour of nameservers. > > No offense, but your view of "clearly" and "expected" have sometimes been > at odds with other folks in the DNS protocol community. Your request that > the IETF do conformance testing might first be based on assurance that > the DNS protocol community agrees on those. After that, "someone" can > probably do testing. And after that, "someone" might be able to get > people to take action against non-conformant implementations. RFC 1034 describes how to answer a query. It clearly states that new query types are expected. "However, the domain system is intentionally extensible. Researchers are continuously proposing, implementing and experimenting with new data types, query types, classes, functions, etc. Thus while the components of the official protocol are expected to stay essentially unchanged and operate as a production service, experimental behavior should always be expected in extensions beyond the official protocol. Experimental or obsolete features are clearly marked in these RFCs, and such information should be used with caution." It also states how to constuct a response and it doesn't state "only known types". 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. The DNS also has response codes to say that a nameserver doesn't implement a part if the specification, that it don't want to answer a particular query, that a internal error occured, that you don't understand or can parse the query. These response codes cover just about any conceivable error condition. It is a query/response protocol and a response is expected except under exceptional circumstances. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deployment of standards compliant nameservers
In message <6a13ceb4-8906-4ec5-9210-571d5474e...@isi.edu>, manning bill writes: > I believe that there are a couple of problems with this plea. > > 1) - The IETF has -never- tested for or assured compliance with their > document series. Which has what to do with requesting that a known problem get fixed? One that is clearly caused by nameservers operating outside the expected behaviour of nameservers. > 2) - The only DNS test suite I am aware of is the older TAHI test suite > from http://www.tahi.org/ - which was focused on IPv6 development and is > now closed. Well I didn't ask for a complete compliance test to be run. I ask for a specific test for a known problematic issue to be run. > 3) - The full DNS standards fail to include the RFC 2026 language that > would suggest mandatory capabilities. And this has what to do with the issue? Yes older RFCs don't all use the formal language of RFC 2026. That doesn't mean that the intent was not clear or that one should not address operational issues that arise. > So, while a nice idea, it is hardly practical from an IETF (or any > top-down) perspective. > > /bill > > On 20May2013Monday, at 17:26, Mark Andrews wrote: > > > > > I call upon the IESG to discuss with IANA, the RIRs, ICANN > > and TLD operators how to deal with the problems caused by the > > deployment of non standards compliant nameservers. > > > > For a long time there have been operational problems > > cause by the deployment of non standards compliant nameservers that > > fail to respond to DNS queries directed at them or respond incorrectly. > > > > The biggest problem with respect to deployment of new > > types is nameservers that fail to respond to types they don't > > understand. RFC 1034 allows for several different responses: > > > > * name error > > * no error no data > > * not implemented > > * refused > > * formerr > > > > "Name error" and "no error no data" are the expected responses for > > queries with unknown types. This is reinforced by RFC 3597. But > > any of the other responses is acceptable. Failure to respond however > > is not acceptable. It introduces systematic timeouts which are > > indistinguishable from network errors without extended analysis of > > query response behaviour. > > > > While the percentage of nameservers misbehaving like this are > > relatively small they have a disproportionate effect on protocol > > development. They are also easily identifiable when looked for by > > querying for a know type at a name that is know to exist, the zone > > apex, that is supported by virtually all nameservers (e.g. A) and > > querying for a random unallocated type, then querying again for the > > original type. If you get a answer, no response, answer then the > > nameserver in question almost certainly has this issue and you are > > not looking at a dead server or network congestion issue. > > > > I'm not sure what the solution should be but regular audits of > > delegated nameservers by infrastructure operator and removal of > > delegations after a grace period to correct the faulty nameserver > > and checking of nameserver behaviour at registration time would go > > a long way to addressing the problem. > > > > Removal of the delegation is one of the suggested remediations > > identified in RFC 1034 for nameservers that are causing operational > > problems. It is not the first step by it is a step in the process. > > > > Mark > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Deployment of standards compliant nameservers
I call upon the IESG to discuss with IANA, the RIRs, ICANN and TLD operators how to deal with the problems caused by the deployment of non standards compliant nameservers. For a long time there have been operational problems cause by the deployment of non standards compliant nameservers that fail to respond to DNS queries directed at them or respond incorrectly. The biggest problem with respect to deployment of new types is nameservers that fail to respond to types they don't understand. RFC 1034 allows for several different responses: * name error * no error no data * not implemented * refused * formerr "Name error" and "no error no data" are the expected responses for queries with unknown types. This is reinforced by RFC 3597. But any of the other responses is acceptable. Failure to respond however is not acceptable. It introduces systematic timeouts which are indistinguishable from network errors without extended analysis of query response behaviour. While the percentage of nameservers misbehaving like this are relatively small they have a disproportionate effect on protocol development. They are also easily identifiable when looked for by querying for a know type at a name that is know to exist, the zone apex, that is supported by virtually all nameservers (e.g. A) and querying for a random unallocated type, then querying again for the original type. If you get a answer, no response, answer then the nameserver in question almost certainly has this issue and you are not looking at a dead server or network congestion issue. I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period to correct the faulty nameserver and checking of nameserver behaviour at registration time would go a long way to addressing the problem. Removal of the delegation is one of the suggested remediations identified in RFC 1034 for nameservers that are causing operational problems. It is not the first step by it is a step in the process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Language editing
You missed the point RFC 5321 SMTP clients have to operate with RFC 2821 SMTP servers when sending address literal in the HELO/EHLO. Code doesn't magically get updated when the spec is updated. It takes years for changes to trickle through. The code has to be written, then it has to be deployed. [The who SPF issue is about a WG that is too impatient to wait for the updated code, that has been written, to be deployed. That will happen as OS's get update / replaced.] While RFC 4291 relaxed the address syntax, RFC 5321 didn't because to do so would break interoperability. RFC 5321's address literals are a subset of RFC 4291's permittable address formats. So there is nothing wrong with referencing RFC 4291. Mark In message <20130507012924.GX23227@verdi>, John Leslie writes: > Mark Andrews wrote: > > > > Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0] > > is not legal according to both RFC 5321 and RFC 2821 which is all > > that applies here. > >I was until today unaware how strong the feelings are on this > "one-or-more" vs. "two-or-more" issue. I do not expect to change > anybody's mind. :^( > >But I do object to calling that EHLO string "not legal". > >The 5321 reference names RFC 4291 as the source of address syntax > (even if it gives BNF which says "two or more" if you delve deeply > enough). > >RFC 4921 is clear about saying "one or more". The Errata posted > against it claiming it should say "two or more" have been rejected. > It is silly to argue under these conditions that Apple's EHLO string > is "not legal". > >BTW, RFC 5321 still contains the language about > " if the verification fails, the server MUST NOT refuse to accept a > " message on that basis. > > so IMHO enforcing any particular interpretation of what an IPv6 > address literal should look like is double-plus-ungood. > > > >To the casual observer, it looks as if RFC 4291 relaxed a previous > "two or more" requirement, but there are folks who don't want to > accept that relaxing. > >One can accept the idea that this relaxing has failed, yet still > observe "liberal in what you accept" as trumping it. I truly wish the > folks in the "two or more" camp would do so! > > -- > John Leslie -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Language editing
In message <51881140.5070...@gmail.com>, Brian E Carpenter writes: > On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote: > > http://labs.apnic.net/blabs/?p=309 > > > > an excellent detective story on badly-written, poorly edited, standards > > track RFCs leading to interop pro > blems. Enjoy. > > I don't that is quite right. The problem in this case is not to do > with linguistic quality. It's due to a lack of formal verification > among a set of interacting and cross-area RFCs. (And the problem > is wider, because there are two distinct places in IETF standards > where ABNF for the text representation of IPv6 addresses can be > found.) This is a case where no amount of language editing would > have helped. Actually I used it a couple of months ago in a > discussion with some experts on formal verification, and they rather > liked it as a poster child for the need for formal methods in SDOs. > > Brian Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0] is not legal according to both RFC 5321 and RFC 2821 which is all that applies here. RFC 2821 was consistent with RFC 2373 and the SMTP literal spec has remained frozen since then which you want when you are trying to promote long term interoperability. Now one could update RFC 5321 to accept the above :: instead of a single :0: but you could never legally send it. Note for IPv4 [070.0.0.0] is 70.0.0.0 not 56.0.0.0 despite the fact that many system will take 070.0.0.0 and send to 56.0.0.0. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A note about draft-ietf-spfbis-4408bis
And if one is worried about keeping automatically generated records in sync add "auto=yes" as the first modifier to the automatically generated record. The two records will remain semantically identical. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A note about draft-ietf-spfbis-4408bis
In message <1962766.G247B9R6HU@scott-latitude-e6320>, Scott Kitterman writes:
> On Monday, May 06, 2013 10:10:40 AM Mark Andrews wrote:
> > In message <42523d2d-85c6-4e6d-b2a7-6791a0e5d...@email.android.com>, Scott
> > Kitterman writes:
> > > Mark Andrews wrote:
> > > >In message <6.2.5.6.2.20130505082013.0adbb...@elandnews.com>, S
> > > >Moonesamy write
> > > >
> > > >s:
> > > >> Hi Mark,
> > > >>
> > > >> At 15:57 04-05-2013, Mark Andrews wrote:
> > > >> >The publisher can choose to interoperate with everyone by publishing
> > > >> >both.
> > > >> >
> > > >> >The client side can choose to interoperate with everyone by looking
> > > >> >for both.
> > > >> >
> > > >> >Both side can choose their level of interoperability. There is no
> > > >> >bug.
> > > >>
> > > >> Thanks for the feedback.
> > > >>
> > > >> Based on the quoted text I would write the text as:
> > > >>(i) you must have X and Y where X and Y are identical.
> > > >>
> > > >>(ii) I ask you for both X and Y (see [1] for example).
> > > >>
> > > >> Item (i) is a combination of the previous items (a) and (c). Item
> > > >> (ii) is the last part of previous item (d).
> > > >
> > > >That was not the intent. Having choice here is very important here.
> > > >In fact it is essential to reach the end goal of Y only when starting
> > > >with X only.
> > > >
> > > >There is nothing wrong with failing to catch every possible forgery
> > > >possible if both sides are using SPF. Unfortunately the SPF WG
> > > >seem to think that unless the RFC does catch every possible forgery
> > > >that it is broken. The SPF WG appears to not want to allow operators
> > > >to have the choice. This is the case "pefect" being the enemy of
> > > >"good enough". We need "good enough" here not "perfect".
> > > >
> > > >Mark
> > >
> > > If we publish a 4408bis that suggests the normal way to publish an SPF
> > > record is in type SPF, then it'll get about 98% less effective based on
> > > the data we've collected. What you are suggesting is more like 'ignore
> > > the deployed base and start over'. That's not wgat the WG was chartered
> > > to do.
> >
> > No one said "ignore deployed base". Firstly normal != only.
> >
> > Secondly one could quite easly add "fixup SPF" functionality to
> > nameservers/zone signers by having the master server/signers add
> > type SPF records if they are not present when there are v=spf1 TXT
> > records. This would also require fixing some DNSSEC records but
> > it is doable.
> >
> > Name servers/signers fixup DNSSEC records all the time. Adding
> > another type of record to fixup is a relatively trivial change.
> >
> > For unsigned zones one could do this on slave servers as well.
> >
> > You have already mentions you have a script that does it. A script
> > needs someone to install it and run it so it is not comparable,
> > other than a proof of concept that it can be done, to getting
> > nameservers to do the fixup. This get done installed and run
> > automatically. Installation happens as part of OS upgrades / new
> > server installs. It gets run as it is part of the default behaviour.
>
> None of this happened in 8 years. There's no basis for the next 8 years
> being
> any different.
Sorry that mantra doesn't cut it.
Add words to say "Namesservers SHOULD add SPF records if they
discover v=spf1 TXT records without SPF records." and it gets dead
easy to add code like this below which does it for dnssec-signzone.
The nameserver is a little more complicated but not much more. Add
some code to UPDATE processing. Add some code when a master zone
gets loaded.
diff --git a/bin/dnssec/dnssec-signzone.c b/bin/dnssec/dnssec-signzone.c
index 5be654d..cfb3f8c 100644
--- a/bin/dnssec/dnssec-signzone.c
+++ b/bin/dnssec/dnssec-signzone.c
@@ -1677,6 +1677,67 @@ remove_sigs(dns_dbnode_t *node, dns_rdatatype_t which) {
dns_rdatasetiter_destroy(&rdsiter);
}
+static isc_result_t
+spfify(dns_db_t *db, dns_db_t *version, dns_dbnode_t *node) {
+ dns_rdata_t rdata = DNS_RDATA_INIT;
+ dns_rdataset_t rdataset;
+ isc_boolean_t h
Re: A note about draft-ietf-spfbis-4408bis
In message <42523d2d-85c6-4e6d-b2a7-6791a0e5d...@email.android.com>, Scott Kitt erman writes: > > > Mark Andrews wrote: > > > > >In message <6.2.5.6.2.20130505082013.0adbb...@elandnews.com>, S > >Moonesamy write > >s: > >> Hi Mark, > >> At 15:57 04-05-2013, Mark Andrews wrote: > >> >The publisher can choose to interoperate with everyone by publishing > >> >both. > >> > > >> >The client side can choose to interoperate with everyone by looking > >> >for both. > >> > > >> >Both side can choose their level of interoperability. There is no > >> >bug. > >> > >> Thanks for the feedback. > >> > >> Based on the quoted text I would write the text as: > >> > >>(i) you must have X and Y where X and Y are identical. > >> > >>(ii) I ask you for both X and Y (see [1] for example). > >> > >> Item (i) is a combination of the previous items (a) and (c). Item > >> (ii) is the last part of previous item (d). > > > >That was not the intent. Having choice here is very important here. > >In fact it is essential to reach the end goal of Y only when starting > >with X only. > > > >There is nothing wrong with failing to catch every possible forgery > >possible if both sides are using SPF. Unfortunately the SPF WG > >seem to think that unless the RFC does catch every possible forgery > >that it is broken. The SPF WG appears to not want to allow operators > >to have the choice. This is the case "pefect" being the enemy of > >"good enough". We need "good enough" here not "perfect". > > > >Mark > > If we publish a 4408bis that suggests the normal way to publish an SPF > record is in type SPF, then it'll get about 98% less effective based on > the data we've collected. What you are suggesting is more like 'ignore > the deployed base and start over'. That's not wgat the WG was chartered > to do. No one said "ignore deployed base". Firstly normal != only. Secondly one could quite easly add "fixup SPF" functionality to nameservers/zone signers by having the master server/signers add type SPF records if they are not present when there are v=spf1 TXT records. This would also require fixing some DNSSEC records but it is doable. Name servers/signers fixup DNSSEC records all the time. Adding another type of record to fixup is a relatively trivial change. For unsigned zones one could do this on slave servers as well. You have already mentions you have a script that does it. A script needs someone to install it and run it so it is not comparable, other than a proof of concept that it can be done, to getting nameservers to do the fixup. This get done installed and run automatically. Installation happens as part of OS upgrades / new server installs. It gets run as it is part of the default behaviour. > Additionally, I'm personally against publishing documents that require > special external knowledge (if 4408bis prefers SPF over TXT deployers > will have know to ignore that part of the RFC if they actually want the > protocol to be useful. To promote interoperability there has to be a MUST > publish and a MUST check format in common. Given the lack of type SPF > deployment, it's crazy to suggest that it should be the required type. What external knowledge. 4408 already effectly says that you need to publish SPF records. TXT records are described as "for backwards i compatibilty". It says you SHOULD publish both. You are worrying about it not been "perfect" when it was in fact what was in 4088 was "good enough". Mark > Scott K > > >> At 16:26 04-05-2013, Mark Andrews wrote: > >> >Additionally it supports all implementions from pre RFC 4088 through > >> >to the desired end state of type SPF only. > >> > > >> >B.T.W. the next point releases of named (at rc2 now) warns if SHOULD > >> >have both is not being done. > >> > >> Noted. > >> > >> Regards, > >> S. Moonesamy > >> > >> 1. http://www.ietf.org/mail-archive/web/ietf/current/msg79114.html > >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A note about draft-ietf-spfbis-4408bis
In message <6.2.5.6.2.20130505082013.0adbb...@elandnews.com>, S Moonesamy write s: > Hi Mark, > At 15:57 04-05-2013, Mark Andrews wrote: > >The publisher can choose to interoperate with everyone by publishing > >both. > > > >The client side can choose to interoperate with everyone by looking > >for both. > > > >Both side can choose their level of interoperability. There is no > >bug. > > Thanks for the feedback. > > Based on the quoted text I would write the text as: > >(i) you must have X and Y where X and Y are identical. > >(ii) I ask you for both X and Y (see [1] for example). > > Item (i) is a combination of the previous items (a) and (c). Item > (ii) is the last part of previous item (d). That was not the intent. Having choice here is very important here. In fact it is essential to reach the end goal of Y only when starting with X only. There is nothing wrong with failing to catch every possible forgery possible if both sides are using SPF. Unfortunately the SPF WG seem to think that unless the RFC does catch every possible forgery that it is broken. The SPF WG appears to not want to allow operators to have the choice. This is the case "pefect" being the enemy of "good enough". We need "good enough" here not "perfect". Mark > At 16:26 04-05-2013, Mark Andrews wrote: > >Additionally it supports all implementions from pre RFC 4088 through > >to the desired end state of type SPF only. > > > >B.T.W. the next point releases of named (at rc2 now) warns if SHOULD > >have both is not being done. > > Noted. > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/ietf/current/msg79114.html > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A note about draft-ietf-spfbis-4408bis
In message <20130504225748.68de733e7...@drugs.dv.isc.org>, Mark Andrews writes: > > In message <20130504221332.5e8de33e7...@drugs.dv.isc.org>, Mark Andrews > writes: > > > > In message <6.2.5.6.2.20130504095840.0d4a9...@resistor.net>, S Moonesamy > > writes: > > > Hi Doug, > > > At 16:19 03-05-2013, Doug Barton wrote: > > > >I am not saying that the WG members (or chairs) should be given the > > > >wet-noodle treatment over having reached a bad decision, but what is > > > >cross-area review for if not to catch cases where the WG echo > > > >chamber/tunnel vision/what have you -- resulted in a bad outcome? > > > > > > I'll try explain the problem as I saw it. > > > > > > (a) You should have both X and Y > > > > > > (b) You must have either X or Y > > > > > > (c) If you have X and Y they must be identical > > > > > > (d) I can ask you for either X or Y, or for both X and Y > > (e) X is only for backwards compatibility. > > > > > > > Regards, > > > S. Moonesamy > > The publisher can choose to interoperate with everyone by publishing > both. > > The client side can choose to interoperate with everyone by looking > for both. > > Both side can choose their level of interoperability. There is no > bug. Additionally it supports all implementions from pre RFC 4088 through to the desired end state of type SPF only. B.T.W. the next point releases of named (at rc2 now) warns if SHOULD have both is not being done. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A note about draft-ietf-spfbis-4408bis
In message <20130504221332.5e8de33e7...@drugs.dv.isc.org>, Mark Andrews writes: > > In message <6.2.5.6.2.20130504095840.0d4a9...@resistor.net>, S Moonesamy > writes: > > Hi Doug, > > At 16:19 03-05-2013, Doug Barton wrote: > > >I am not saying that the WG members (or chairs) should be given the > > >wet-noodle treatment over having reached a bad decision, but what is > > >cross-area review for if not to catch cases where the WG echo > > >chamber/tunnel vision/what have you -- resulted in a bad outcome? > > > > I'll try explain the problem as I saw it. > > > > (a) You should have both X and Y > > > > (b) You must have either X or Y > > > > (c) If you have X and Y they must be identical > > > > (d) I can ask you for either X or Y, or for both X and Y (e) X is only for backwards compatibility. > > > > Regards, > > S. Moonesamy The publisher can choose to interoperate with everyone by publishing both. The client side can choose to interoperate with everyone by looking for both. Both side can choose their level of interoperability. There is no bug. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A note about draft-ietf-spfbis-4408bis
In message <6.2.5.6.2.20130504095840.0d4a9...@resistor.net>, S Moonesamy writes: > Hi Doug, > At 16:19 03-05-2013, Doug Barton wrote: > >I am not saying that the WG members (or chairs) should be given the > >wet-noodle treatment over having reached a bad decision, but what is > >cross-area review for if not to catch cases where the WG echo > >chamber/tunnel vision/what have you -- resulted in a bad outcome? > > I'll try explain the problem as I saw it. > > (a) You should have both X and Y > > (b) You must have either X or Y > > (c) If you have X and Y they must be identical > > (d) I can ask you for either X or Y, or for both X and Y > > Regards, > S. Moonesamy > The DNS does not guarentee that the result of 2 consecutive queries for the same data will be the same even to the same server (cache or authoritative). RFC 4408 says that *data* MUST be the same if both records are present in the zone. It the operator breaks that MUST then you get inconsistent results. Note this is no different to changing the contents of the record. You will get inconsistent result while the record are in transition. For the client side you assume the MUST is being honoured as there is no way (other than to ask a * query directly to the authoritative servers) to check that this is so. You take the first result which returns *data* and use it. This was never a real problem. Not all MUSTs need to be checked. Note DNSSEC also has MUSTs about what the server side need to do which the client side cannot check. This is the nature of DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [IETF] Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)
In message <86172038-8f62-4508-8199-be4c16906...@kumari.net>, Warren Kumari writes: > > On May 2, 2013, at 9:56 PM, Mark Andrews wrote: > > > > > In message <5182828c.3040...@isdg.net>, Hector Santos writes: > >> Mr. Resnick, for the record, I wasn't upset. Believe it or not, I was > >> actually applying an suggestion posted last month or so here with the > >> IETF diversity talks to help get a major WG issue resolved, one with a > >> near surety of an appeal, resolved and addressed much faster and hence > >> avoid a waste of time on the behalf of all. > >> > >> How appropo, that a topic of "balancing of process" as being > considered. > >> It is one thing I believe the IETF needs and can be actually apply > >> today. Yes, I don't agree with the negative tone taken in SPFBIS where > >> in effect, an attempt to shut down communications and indirectly > >> personally attack posters occurred and the advocates of the SPF RRTYPE > >> removal (incidentally, a SPEC change which I believe was prohibited by > >> the charter), basically blowing off advocates of a RFC4408 status quo. > >> If you believe that was proper, I think we have a WG problem. > >> > >> Overall, I believe this (keep the migration path) is the proper > >> compromise to resolve the issue, and I believe that this particular > >> issue is industry-wide important to resolve with across the board > >> engineering input. It *SHOULD NOT* be reserved only to the > applications > >> SPFBIS group especially when we know what the DNS community will say > >> about this and has said so since MARID 2003 and again last year in > IETF > >> and DNSOPs. I was simply hoping to help "Balance the process" then as > I > >> was attempted to do again. If I was in error for trying to get a > >> serious issue resolve, then please accept my apology. > >> > >> Sincerely, > >> > >> Hector Santos > > > > One of the questions is how to deal with vendors that claim to ship > > a product which is in compliance with the protcol when they are > > not. > > > > The DNS protocol has a error code for when you do not understand a > > query, FORMERR. It also has a error code for when you do not > > implement part of the protocol, NOTIMP. > > > > With RFC 103[45] you have three choices as a developer when you get > > a query type you don't know about. > > > > 1. Treat it as a FORMERR. > > 2. Treat it as a NOTIMP. > > 3. Treat it as a opaque data. > > > > Now in my book it isn't a FORMERR as you can understand the question > > even if you can't deal with it. NOTIMP is a reasonable response > > though I believe the intent in RFC 103[45] was to treat it as opaque > > data query which is what RFC 3597 says to do. > > > > Nowhere in RFC 103[45] does it say DO NOT RESPOND to the query yet > > we have DNS vendors that ship products that do just that and are > > claiming that they conform to the protocol. > > > > For a example of a set of servers that does this see earthlink.net's > > servers. > > > > Query for HINFO/earthlink.net at the authoritative servers for > > earthlink.net (itchy.earthlink.net and scratchy.earthlink.net) and > > you will not get a response. A RFC 103[45] compliant server should > > know about HINFO. It should also be capable of returning a NOERROR > > NODATA response for that query and it fact will if you ask for a > > non-existent TXT record at a name it serves. > > > > How do we deal with sites? > > How do we deal with vendors that ship such product? > > Unless the caffeine just hasn't sunk in yet, it works for me: > > wmbt-macbookair:Preferences wkumari$ dig HINFO earthlink.net > @scratchy.earthlink.net > > ; <<>> DiG 9.8.3-P1 <<>> HINFO earthlink.net @scratchy.earthlink.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1906 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;earthlink.net. IN HINFO > > ;; AUTHORITY SECTION: > earthlink.net.1800IN SOA itchy.earthlink.net. > hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800 > > ;; Query time: 51 msec > ;; SERVER: 207.69.188.197#53(207.69.188.197) > ;; WHEN: Fri May 3 12:59:50 2013 > ;; MSG SIZE rcvd: 84 > > So,
Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)
In message <8d23d4052abe7a4490e77b1a012b63077516d...@mbx-01.win.nominum.com>, Ted Lemon writes: > On May 2, 2013, at 9:56 PM, Mark Andrews wrote: > > How do we deal with sites? > > How do we deal with vendors that ship such product? > > I say we punch 'em. > > Seriously, the IETF doesn't have an enforcement arm. It's up to buyers > to check to see that what they are buying is protocol compliant, and > often they either fail to even try, or don't really know how. When the literature says it is a DNS server how is the buyer to know it isn't a complete DNS server? And even if they know it is not a complete DNS server would they know the impact of deploying it? > What you can do as a DNS vendor, if you want to beat up other vendors > with non-compliant products, is to produce a validation test suite and > start promoting it. Is there a vendor that does this now? If so, you > could just use theirs, assuming it's free. Start boasting in your > advertising that your product is standards compliant. Which just adds more noise. Now if a recognised standards body was to do the tests then it might have some effect. Should we be using RFC 1033's complaint's procedures? How can we get TLDs to do step 5 when steps 1 though 4 fail? COMPLAINTS These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server: 1. Complain privately to the responsible person for the domain. You can find their mailing address in the SOA record for the domain. 2. Complain publicly to the responsible person for the domain. 3. Ask the NIC for the administrative person responsible for the domain. Complain. You can also find domain contacts on the NIC in the file NETINFO:DOMAIN-CONTACTS.TXT 4. Complain to the parent domain authorities. 5. Ask the parent authorities to excommunicate the domain. > Now that you're done with that, get started on all the middleboxes that > are made by vendors who are not "DNS vendors". Middle boxes are a little easier to deal with as they are usually at the client end not the server end. > The good news is that the ocean is warmer than it was even ten years ago, > so boiling it is somewhat less work than it used to be. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)
In message <5182828c.3040...@isdg.net>, Hector Santos writes: > Mr. Resnick, for the record, I wasn't upset. Believe it or not, I was > actually applying an suggestion posted last month or so here with the > IETF diversity talks to help get a major WG issue resolved, one with a > near surety of an appeal, resolved and addressed much faster and hence > avoid a waste of time on the behalf of all. > > How appropo, that a topic of "balancing of process" as being considered. >It is one thing I believe the IETF needs and can be actually apply > today. Yes, I don't agree with the negative tone taken in SPFBIS where > in effect, an attempt to shut down communications and indirectly > personally attack posters occurred and the advocates of the SPF RRTYPE > removal (incidentally, a SPEC change which I believe was prohibited by > the charter), basically blowing off advocates of a RFC4408 status quo. > If you believe that was proper, I think we have a WG problem. > > Overall, I believe this (keep the migration path) is the proper > compromise to resolve the issue, and I believe that this particular > issue is industry-wide important to resolve with across the board > engineering input. It *SHOULD NOT* be reserved only to the applications > SPFBIS group especially when we know what the DNS community will say > about this and has said so since MARID 2003 and again last year in IETF > and DNSOPs. I was simply hoping to help "Balance the process" then as I > was attempted to do again. If I was in error for trying to get a > serious issue resolve, then please accept my apology. > > Sincerely, > > Hector Santos One of the questions is how to deal with vendors that claim to ship a product which is in compliance with the protcol when they are not. The DNS protocol has a error code for when you do not understand a query, FORMERR. It also has a error code for when you do not implement part of the protocol, NOTIMP. With RFC 103[45] you have three choices as a developer when you get a query type you don't know about. 1. Treat it as a FORMERR. 2. Treat it as a NOTIMP. 3. Treat it as a opaque data. Now in my book it isn't a FORMERR as you can understand the question even if you can't deal with it. NOTIMP is a reasonable response though I believe the intent in RFC 103[45] was to treat it as opaque data query which is what RFC 3597 says to do. Nowhere in RFC 103[45] does it say DO NOT RESPOND to the query yet we have DNS vendors that ship products that do just that and are claiming that they conform to the protocol. For a example of a set of servers that does this see earthlink.net's servers. Query for HINFO/earthlink.net at the authoritative servers for earthlink.net (itchy.earthlink.net and scratchy.earthlink.net) and you will not get a response. A RFC 103[45] compliant server should know about HINFO. It should also be capable of returning a NOERROR NODATA response for that query and it fact will if you ask for a non-existent TXT record at a name it serves. How do we deal with sites? How do we deal with vendors that ship such product? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
In message <517ffb33.30...@dougbarton.us>, Doug Barton writes:
> On 04/30/2013 09:28 AM, Alessandro Vesely wrote:
> > While it's too late for SPF, we can learn this lesson.
>
> As has been repeatedly pointed out in the discussion on both dnsext and
> spfbis, it is NOT too late for SPF. The way forward is simple:
>
> 1. Publish the bis draft which says for senders to publish both SPF and
> TXT versions, and receivers to query first for the SPF RRtype.
>
> 2. Update the HOW-TO docs to reflect this change.
>
> 3. Update the software to query SPF first (Note, Perl's NET::SPF, used
> by SpamAssassin, already made this change).
As has libspf2.
> 4. Let time pass.
>
> 5. When the next version of the SPF protocol (v=spf{>1}) comes out make
> it SPF/99 only.
>
> The discussion about this on the spfbis list all revolved around the
> fact that TXT is widespread, SPF/99 is rarely used, so let's just stick
> with TXT. In a pre-3597 world there _were_ problems with querying for
> SPF first, so the fact that historically querying for SPF/99 first was
> painful is a valid data point. However the problems encountered in the
> early days of SPF deployment with servers not handing unknown types
> gracefully haven't been relevant for many years now. Yet, the SPF
> community has continued to push TXT only, in spite of the advice of
> 4408. Almost like a self-fulfilling prophecy ...
>
> The reasons brought forward by participants in the spfbis group to not
> make this change all revolve around the fact that it would involve
> additional work. Personally I don't find those arguments compelling.
> First, some of the arguments about the extra work are just plain silly
> (ala, "cut and paste of the same data for 2 RRtypes is too difficult").
> Second, there are not that many implementations that query SPF, and the
> change is not difficult. Third, most of the "work" to be done is to wait
> for time to pass and for people to upgrade to the new versions of
> software. This is a bog-simple "long tail" problem that we deal with in
> the DNS world all the time.
>
> There was one objection that made some sense, which is that right now,
> because the SPF world has steadfastly distributed the advice to use TXT
> only, querying for SPF/99 first gives you what is likely to be 1
> spurious DNS lookup per e-mail message. The obvious answer to that is to
> do a better job of encouraging folks to publish SPF records. Meanwhile,
> I have a fairly traditional mail server implementation that does a
> variety of anti-spam checks. By rough count it generates about 8 DNS
> queries for every message already. Generating 1 more is "in the noise"
> in the short term, and as shown above goes away in the long term.
>
> Not only is this a case where doing the right thing is good for SPF, the
> SPF example of "let's just go with TXT because using a new RRtype is
> hard" has spread like wildfire, especially in the mail authentication
> world (DKIM, DMARC, etc.). The slippery slope has been well-greased at
> this point, and it would be nice to move things back in the right
> direction (see 5507 for example).
>
> To be fair, there was one other objection raised, which is that DNS
> provisioning systems haven't caught up with the need for new RRtypes. So
> some can't go to their registrar's/web hoster's/etc. web interface and
> enter a proper SPF record. That's a problem, sure. But it's a problem
> that has to be solved, assuming we're actually going to take the advice
> in 5507 seriously. Personally I'm not willing to allow all progress
> forward in DNS to be stymied by those unwilling to make an investment in
> their own infrastructure.
>
> In case Dave is still wondering what all the fuss is about, and because
> the folks in spfbis seem completely unwilling to deal with this issue in
> the group, consider this my first draft of an IETF last call objection
> to the fact that 4408bis wants to deprecate use of the SPF RRtype.
>
> Doug
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
In message <517ff144.5040...@tana.it>, Alessandro Vesely writes: > On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote: > > > > The really annoying thing is that SPF is techically superior > > to TXT is lots of ways. > > > > 1. It uniquely identifies the roll of the record. > > > > 2. As SPF records are singletons you don't need to identify > >and remove the old record when updating. You can just > >remove all SPF record and add the replacement. > > > >For TXT you need to lookup the existing RRset, extract > >the v=spf1 record from it. You then need to create a > >UPDATE message to delete just that record as well as add > >the new TXT record. You then have to hope that no one > >else is performing a simultanious update as you may get > >two TXT v=spf1 records in the RRset. > > That's true, except that one has TXT records anyway. nsupdate update del example.com SPF update add example.com 3600 SPF v=spf1 send txt=`dig +short example.com TXT | \ sed -n -e '/^"v=spf1 /s/^/update del example.com TXT /p' \ -e '/^"v=spf1"$/^/update del example.com TXT /p'` nsupdate << EOF $txt update add example.com 3600 TXT v=spf1 send EOF But that doesn't work for 'example.com TXT "v" "=" "s" "p" "f" "1"' which is a perfectly legal SPF record. sed -n -e '/^"v=spf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=spf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "spf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "pf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "p" "f1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "p" "f" "1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "p" "f" "1" " /s/^/update del example.com TXT /p' \ -e '/^"v=spf1"$/^/update del example.com TXT /p'` And keep going because the delete needs the rdata to be a perfect match to identify the record to be removed. I'm sure I could come up with a more compact way of identifying a spf record but it wouldn't be needed if people published type SPF. > > The complains about using SPF is that there are broken >p >firewalls and some servers drop queries for it, some registars > > don't support it. > > Nits, as explained below. The basic fact that killed the SPF type is > the ability to use TXT as a replacement. There must be an analogous > of Gresham's law: "Bad types drive out good ones." > > > For firewalls, fix/replace the firewall if you intend to > > deploy SPF and it doesn't support it. It is total !@##@# > > that firewall are incapable of handling new DNS record > > types. New records we exected to occur from the very > > beginning and have been coming out regularly ever since the > > DNS was invented. Firewall vendors that are incapable of > > handling new DNS types are incompetent and do not deserve > > repeat business. > > > > For servers than drop SPF queries they really are at the > > noise level. When you identify one you complain to the > > owners of it. Yes, that does work. We needed to do that > > for records. > > > > For registrars, change registrar to one that does. > > While it's too late for SPF, we can learn this lesson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
In message <51802793.3010...@dcrocker.net>, Dave Crocker writes: > On 4/30/2013 12:54 PM, David Conrad wrote: > > On Apr 30, 2013, at 11:12 AM, Dave Crocker wrote: > >>> What is the IETF-approved timeframe in which "the market" is allowed to a > ccept/reject a particular technology? > >> I've no idea what the lower limit is or should be, but I'm quite sure that > 7 years exceeds it by a very comfortable margin. > > > > By that logic we should abandon IPv6, DNSSEC, EDNS0, etc. > > > Gosh, David. I guess you win. When just about none of the documentation mentions the SPF record type nor has examples with both SPF and TXT records it isn't the "market" choosing. You can't choose of you really havn't been informed. BEWARE OF THE LEOPARD "But Mr Dent, the plans have been available in the local planning office for the last nine months." "Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn't exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything." "But the plans were on display ..." "On display? I eventually had to go down to the cellar to find them." "That's the display department." "With a flashlight." "Ah, well the lights had probably gone." "So had the stairs." "But look, you found the notice didn't you?" "Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'." The Hitchhikerâs Guide to the Galaxy Douglas Adams Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
The really annoying thing is that SPF is techically superior
to TXT is lots of ways.
1. It uniquely identifies the roll of the record.
2. As SPF records are singletons you don't need to identify
and remove the old record when updating. You can just
remove all SPF record and add the replacement.
For TXT you need to lookup the existing RRset, extract
the v=spf1 record from it. You then need to create a
UPDATE message to delete just that record as well as add
the new TXT record. You then have to hope that no one
else is performing a simultanious update as you may get
two TXT v=spf1 records in the RRset.
The complains about using SPF is that there are broken
firewalls and some servers drop queries for it, some registars
don't support it.
For firewalls, fix/replace the firewall if you intend to
deploy SPF and it doesn't support it. It is total !@##@#
that firewall are incapable of handling new DNS record
types. New records we exected to occur from the very
beginning and have been coming out regularly ever since the
DNS was invented. Firewall vendors that are incapable of
handling new DNS types are incompetent and do not deserve
repeat business.
For servers than drop SPF queries they really are at the
noise level. When you identify one you complain to the
owners of it. Yes, that does work. We needed to do that
for records.
For registrars, change registrar to one that does.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Internet Draft Final Submission Cut-Off Today
In message <20130227054857.gd7...@mx1.yitter.info>, Andrew Sullivan writes: > On Tue, Feb 26, 2013 at 01:31:12PM -0900, Melinda Shore wrote: > > it's 23:59 + 1 minute, which is clear. But I really > > think "24:00" is confusing. 0:00 is clearer. I'm > > wondering if they're trying to work around some ferkakte > > piece of software. > > I don't think so. ISO (ISO 8601) seems to think that "24:00" refers > to the very end of the day, and "00:00" refers to the very beginning > of the next day. So there's a conceptual distinction involved. > > A And to avoid confusion many places use 23:59:59 as end of trading day. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Bonjour-dev Digest, Vol 10, Issue 19
In message <3e07105e-58dc-4e08-ac9f-d259a0a4b...@me.com>, Sabahattin Gucukoglu writes: > (Because this was brought up very, very recently.) > > On 21 Feb 2013, at 20:28, Rick Mann wrote: > > On Feb 21, 2013, at 12:24 , David Brower > wrote: > >> It depends on the records. If you phrase it like you that, you will > >> probably get the blank stare answer. When you start talking about the > >> PTR, SRV and TXT records specifically, then you'll have a case -- but it > >> isn't really Bonjour that is the proximate force, because those were > >> issues against interpretations of the previous RFCs. > >> > >> Now, the legalistic point I'm debating at the moment is whether it is > >> proper and/or legal to have the SRV record use as the target name the > >> string version of an ip4 address, eg: "192.169.0.145". That's a > >> perfectly legal and representable set of characters for a hostname, so > >> maybe OK. Actually it isn't a legal hostname if it is supposed to be a fully qualified host name as all digit tlds are prohibited in valid host names. RFC 1123 > >> How about for an ip6 address with colons, which aren't allowed in > >> hostnames? > > > > All I know is that a couple years ago, I tried and failed with both > > DynDNS and DNSMadeEasy to get them to allow me to put spaces in TXT > > records. I cited all relevant material I could find, but they kept going > > back to the original DNS specifications saying those didn't allow spaces. RFC 1035 permits spaces in TXT records. RFC 1035 permits spaces in domain names. You either using a " delimited string or \032 to represent a space. RFC 1035: is expressed in one or two ways: as a contiguous set of characters without interior spaces, or as a string beginning with a " and ending with a ". Inside a " delimited string any character can occur, except for a " itself, which must be quoted using \ (back slash). \DDDwhere each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. DynDNS and DNSMadeEasy are wrong in this respect. > RFC 1035, 2.3.1, wisely advises the use of compatible constraints on > labels in host names. I am aware that DNS is binary transparent, and > mDNS/DNS-SD make use of that feature to be useful, but I can well > understand the scepticism of your DNS hosts. Perhaps this is a > legitimate call to relax the restrictions, *if* the operator/user is > aware of the potential consequences. > > Cheers, > Sabahattin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Just so I'm clear
In message , Margaret Wass erman writes: > > On Oct 24, 2012, at 1:01 AM, Doug Barton wrote: > > I get what you're saying, but this is one of those times where (arguably > > for the better) we've created a difficult procedure that should be > > infrequently exercised. We should follow the procedure because it _is_ > > the procedure. And then use the opportunity to improve it. > > The existence of the recall procedure does not imply that there isn't any > other way for a seat to become vacant. For example, a seat can become > vacant when an I* member resigns or dies, and there is no need for a > recall in those cases. > > I think it is reasonable for the IAOC to set it's own (reasonable, > consistent) bar for deciding that a sitting member has vacated his/her > seat through lack of attendance and lack of response. No recall should > be needed in that case to replace the missing member, any more than if > the person had explicitly resigned. The IAOC sent a long list of things > that they have done to contact Marshall, and he has not responded. It > seems impossible that he has not received any of those contacts, so his > lack of response is indicative, IMO, that he has indeed vacated his seat. But we don't have rules that say, "failure to attend for X period, without permission, will result in the position being declared vacant". I we did this would be simple. I don't think we have any choice from a proceedural point of view other than to start recall proceedings. > I share the hope of the IAOC and others that Marshall is okay, and that > he will return to the IETF when he can. I appreciate his contributions > throughout the years, and I would be happy to see him return to continue > making those contributions. For now, though, he has vacated his IAOC > seat and should be replaced. > > Margaret -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
In message <506dbe9b.3070...@ogud.com>, Olafur Gudmundsson writes: > On 02/10/2012 21:15, Mark Andrews wrote: > >> Labels only work when all the severs for a zone that has a new label type, > >> in ADDITION sufficient fraction servers in all zones above that zone > >> MUST understand the new > >> label type. > > > > Not true. Binary labels could have been made to work by removing > > the left hand label until the remaining suffix consisted of only > > RFC 1035 labels, looking up the servers for that domain, then > > resuming query processing using those servers similar to what we > > do with DS lookups. > > > > Such processing would be required for any new label type used in a > > QNAME and would be a significant change to the standard query logic. > > > > Mark > > > > Mark, > > This will only work if all the recursive resolvers that "consumers" for > this new label types have been updated AND the new label type is the > left most label(s) in the name. This works regardless of the position of the label. If a TLD label is a binary label then you strip back the labels until you reach the root. Resolvers involved in the lookup need to be updated and I didn't dispute that. > Olafur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
> Labels only work when all the severs for a zone that has a new label type, > in ADDITION sufficient fraction servers in all zones above that zone > MUST understand the new > label type. Not true. Binary labels could have been made to work by removing the left hand label until the remaining suffix consisted of only RFC 1035 labels, looking up the servers for that domain, then resuming query processing using those servers similar to what we do with DS lookups. Such processing would be required for any new label type used in a QNAME and would be a significant change to the standard query logic. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
Closing the registry is not irreversable if it needs to be reversed. It's not like we can forget that there were assigned code points and anything that attempted to use those code points would have to consider the fact that they were used at one time. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
d possibilities > before deciding to deprecate extended label types entirely? If > so, why aren't those considerations described in the document? > We don't have a lot of codes left in the RFC 1035 space on which > other label type models might be constructed. > > (2) Is there strong justification for deprecating extended label > types, e.g., evidence that they would cause harm? > > (3) If the answer to either of both of the above questions is > "no", wouldn't it be wiser to simply deprecate the use of binary > labels, urge great caution in allocating and using other label > types, and then move on rather than eliminating the facility? > > thanks, > john I don't think we need to do this in label types. An EDNS option would be sufficient to specify alternate normalisation rules should be applied to the QNAME when looking for data and when normalising the owner names when performing DNSSEC validation. > ___ > dnsext mailing list > dns...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
In message , Vinayak Hegde writes: > On Wed, Sep 5, 2012 at 3:49 AM, John Levine wrote: > >> This discussion of DMCA is useful to me as a non-US resident. > >> > >> Are we sure that the boilerplate included in I-Ds does not constitute a > >> statement by the authors that they have not, as far as they are aware, > >> infringed any copyright? In other words, isn't the boilerplate a > >> pre-emptive counternotice? > > > > It's not, and even if it were, would you want to find out > > retroactively that you've agreed to pay the IETF's legal expenses if > > someone sues about an I-D you posted?. For more information, please > > see this link in the message you just sent. > > > >>> (http://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limita$ > > > > I agree with Elliott that we need a reasonable DMCA policy, keeping in > > mind that it's pretty rare for a document, particularly a non-archival > > one, to be worth the hassle of fighting a DMCA notice. Fighting the > > TZ takedown was absolutely worth it, but it was unusual in the > > material attacked was of high value, and the basis for the notice was > > unusually bogus. Even so, someone had to pay for lawyers to prepare > > the briefs and appear in court, and I wouldn't want the IETF to > > promise to do that casually. > > Also it might be useful for the submitter to sign (rather tick a > tickbox/radio button) an indemnification clause for the IETF before > submitting an I-D. We may as well close up shop if we have to start doing that. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IETF 92 in Dallas!
In message <502c81d2.3020...@bogus.com>, joel jaeggli writes: > On 8/15/12 9:49 PM, Alejandro Acosta wrote: > > Hi All, > >In my humble opinion I totally agree with Arturo. So far I do know > > several cities in Latin America and I believe Sao Paulo (Brazil) or > > Cancun (Mexico) might be a good options. Of course there are many more > > good cities, those ware the first two that came to my mind. > >I hope IETF 100 can be done over there. > Notably Sao Paulo gets a train line from GRU in time for the worldcup in > theory, which would be a substantial accessibility improvement. > > Some locations in the southern hemisphere where attendees hail from have > even more painful routing than normal to GRU e.g. syd. The observation > would be that it's a long-haul for all but a handful of attendees. And it would be ~$1000 (AUD) more than Vancouver was from Sydney. SYD -> SCL -> GRU 21:40 GRU -> SLC -> SYD 24:30 > > See you, > > > > Alejandro, > > > > > > > > On 8/15/12, Arturo Servin wrote: > >>So "Americas" was actually "North America". > >> > >>Well, it went the possibility to have one in central or south america, > what > >> at shame. At least until IETF 98 in March 2017 no IETF down the south of R > io > >> Grande. > >> > >>May I ask the IAOC, what are the impediments to have one IETF in Latin > >> America? > >> > >> Regards, > >> as > >> > >> On 15 Aug 2012, at 14:04, IETF Administrative Director wrote: > >> > >>> The IAOC is pleased to announce Dallas, TX, USA as the site for IETF 92 > >>> from March 22-27, > >>> 2015. The IETF was last in Dallas for IETF 65 in 2006. IETF 92 will be > >>> at a different venue in > >>> the Dallas Arts District. > >>> > >>> Those who may be interested in hosting or sponsoring this or any future > >>> meeting are invited to > >>> contact Drew Dvorshak at dvors...@isoc.org. See Host opportunities > >>> below. > >>> > >>> Ray Pelletier > >>> IETF Administrative Director > >>> > >>> IETF Meeting Schedule: > >>> > >>> 2012 > >>> IETF 85 Atlanta 4 - 9 November Host: North American Cable Industry > >>> > >>> 2013 > >>> IETF 86 Orlando 10 - 15 March (Back-to-back with IEEE 802) Comcast & > >>> NBC Universal > >>> IETF 87 Berlin 28 July - 2 Aug Host and Sponsors Sought > >>> IETF 88 Vancouver 3 - 8 November Host Sought > >>> > >>> 2014 - Hosts sought > >>> IETF 89 London > >>> IETF 90 Toronto > >>> IETF 91 Honolulu > >>> > >>> 2015 - Hosts sought > >>> IETF 92 Dallas > >>> IETF 93 Europe > >>> IETF 94 Yokohama WIDE > >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ITU-T Dubai Meeting
In message <5021742a.70...@dougbarton.us>, Doug Barton writes: > On 08/07/2012 00:46, Martin Rex wrote: > > IPv6 PA prefixes result in that awkward renumbering. > > Avoiding the renumbering implies provider independent > > network prefix. > > ULA on the inside + https://tools.ietf.org/html/rfc6296 If you are changing your external connection you may as well just use ULA + PA. The DNS needs to be updated in either case, the firewall needs to be updated in either case. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ITU-T Dubai Meeting
In message , Daniel Karrenberg w rites: > > On 02.08.2012, at 22:41, Phillip Hallam-Baker wrote: > > > ... That depends on whether the registry in question is dealing with a > > scarce resource or a plentiful one. Having two registries handing out > > IPv4 addresses at this point would be very very bad. Having more than > > one place you can get an IPv6 from would not worry me at all. ... > > IPv4 addresses used to be regarded as non-scarce not so long ago. I don't know what planet you have been living on but it was clear IPv4 addresses were a scarce resource 2+ decades ago longer than some IETF attendees have been alive. IPv6 was started because they were a scarce resource that would run out in the foreseeable future. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [v6ops] Last Call: (Basic Requirements for IPv6 Customer Edge Routers) to Informational RFC
In message , Randy Bush writes: > > - 'Basic Requirements for IPv6 Customer Edge Routers' > >as Informational RFC > > this document persists in confusing routing and forwarding. > > there are no routing protocols, a la 1812, here. there is confused text > such as > > 4.1. General Requirements > >The IPv6 CE router is responsible for implementing IPv6 routing; that >is, the IPv6 CE router must look up the IPv6 destination address in >its routing table to decide to which interface it should send the >packet. > > which i thought was forwarding, not routing. It's static routing. And if there is down stream PD there will be next hop routers as well as interfaces in the table. > RA/RD doeth not a router make. > > randy > ___ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [dnsext] Last Call: (Clarifications and Implementation Notes for DNSSECbis) to Proposed Standard
I am repeating what I have said earlier during WGLS that Section 5.9., Always set the CD bit on Queries, contains bad advice on how to set the CD bit. The setting of CD make little difference if all the machines involved are being correctly managed. In that case all responses will successfully validate. However if there is a off path attacker or one or more of the authorititive sources is returning stale records the setting of CD is critical to ensuring that the ultimate client can get the necessary records to ensure that the responses it gets validate. When there is a non-validating stub resolver all queries from that client come in with CD=0 and a validating recursive server try multiple authoritative servers until it gets a answer which validates as secure or insecure, in other words it rejects answers from attackers or from authoritative servers that return stale data. Now take a validating validating stub resolver, if all queries from that client come in the CD=1, them the recursive server returns the answer from upstream immediately without filtering out bad responses. If there is a off path attacker or if there is a stale authoritative server then there is no way to ensure that the stub client will ever get a answer that will validate. It can continue to re-query forever but there is no requirement for the recursive server to try a different authoritative source or to wait for a valid response from a authoritive source. A similar problem arises when a recursive server is talking through a second recursive server. The server is no longer talking to the authoritative servers directly and can't recover from getting answers that do not validate. Now sending CD=0 has its own set of problems caused by stale trust anchors and clocks being out of sync so I am not suggesting that we always send CD=0 queries either when incoming queries are sent with CD=0. Stub resolvers and recursive servers talking through other recursive servers need to be prepared to ask queries with both CD=0 and CD=1. CD=1 when talking to authoritative servers, CD=0 when talking to recursive servers falling back to CD=1 on SERVFAIL to handle stale trust anchors and out of sync clocks unless the incoming query was received with CD=1 in which case you MUST make CD=1 upstream queries. Now if the recursive server is not validating, validating down stream clients are vulnerable to all the failure modes caused by sending CD=1 queries. Fixing this will require protocol extensions to pass trust anchors, and maybe current time, along with the query and having on demand validation performed using those values in the recursive server for this client. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Last Call: (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC
In good faith that you believe, or potentially believe, that In message <4fab2563.3090...@qualcomm.com>, Pete Resnick writes: > On 5/9/12 6:40 PM, Fred Baker wrote: > > >> I don't want participants to think that they can't bring up the issue of v > iolation without some sort of "burden of proof". > >> > > Hmm. > > > > I'm concerned about people bringing baseless accusations, as yet another wa > y to DOS a WG with IPR. If a person believes that there is a violation that i > s worthy of the name, they should probably see to it that it gets discussed, > but I don't see how they make that determination without having at least some > data or report that can be verified. If someone in my working group brings s > uch an accusation to me, trust me, the first question I am going to ask is "w > hy do you believe that". If the answer is "can't you see they have shifty eye > s", it will end there. I'm looking for at minimum that a named party has evid > ence to support it. > > I completely agree. That's why I asked that we figure out some text that > does both things: Indicate that it's OK to say that you believe someone > crossed the line and explain your reasons for that belief, but not > require that it be a proven fact before you can even broach the subject. > I can see how the current text might be too lax, but I thought Brian's > text was too stringent. Looking for a happy medium. > > pr > > -- > Pete Resnick<http://www.qualcomm.com/~presnick/> > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 networking: Bad news for small biz
In message <20120404212135.0e09a18c...@mercury.lcs.mit.edu>, Noel Chiappa write s: > > From: Doug Barton > > > My comments were directed towards those who still have the mindset, > > "NAT is the enemy, and must be slain at all costs!" > > In semi-defense of that attitude, NAT (architecturally) _is_ a crock - it put > s > 'brittle' (because it's hard to replicate, manage, etc) state in the middle o > f > the network. Having said that, I understand why people went down the NAT road > - when doing a real-world cost/benefit analysis, that path was, for all its > problems, the preferable one. > > Part of the real problem has been that the IETF failed to carefully study, an > d > take to heart, the operational capabilities which NAT provided (such as > avoidance of renumbering, etc, etc), and then _failed to exert every possible > effort_ to provide those same capabilities in an equally 'easy to use' way. > > Noel Most of the renumbering issues that remain are outside of the perview of the IETF. Hosts have had the ability to securely register themselves in the DNS for a decade now. Microsoft AD has hosts register themselves using these mechanisms. DHCP handles both static and dynamic addresses. Now we may want a way for a host to register itself securely with the firewall. That way when a host's IP address changes the firewall gets updated. Most of the renumber problem in people refusing to get out of the way of automation. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 networking: Bad news for small biz
In message <8155FD1BB2ABCD40AC6F8149BBE997E003E0682362F8@sdcexchms.netstarnetwo rks.com>, Greg Daley writes: > Hi Mark,=20 > =20 > > > But of course, I'm always delighted to hear your opinions. Is =3D > > > renumbering *really* that big of a deal? I suppose multihoming is the > > > =3D bigger, more serious concern - that's the one we see no viable > > > solution =3D but NAT for, given small site constraints and aggregation. > >=20 > > Total hogwash. Add a bit of source address based routing within the > > enterprise so that you hit the right exit routers for the source address = > being > > used. Tag route entries with valid source prefixes. > > Add redirect based on source address signaling. > > Source based routing is a pain to maintain and to troubleshoot! Why is a pain to maintain? Because no one has written a routing protocol to exchange the necessary information? Routing engines havn't been updated to use this information? The border routers add source address prefix tags to the routes they advertise internally for the prefixes they have been delegated by the ISP. This destination with these source addresses goes to this next hop. If you have PI then "these source addresses" becomes ::/0 in most cases. > In business-land I have had to pull out cruddy, unmaintainable solutions wh= > ich modify normal routing behaviour and sit undocumented in various busines= > ses. This is salient because some of the businesses are small, or started = > small. So rather than make a maintainable solution you throw out the idea. > Please don't suggest strange addressing or routing tricks, and I will not s= > uggest strange DNS tricks ;-) > > I would be OK if there was a straightforward RPF-like check which could be = > applied at edge routers to ensure that packets exit via the correct ISP, bu= > t my customers' routing tables are destination based, like 99% of the Inter= > net. And they still will be destination based with source addresses use to differentiate between different entries. > Greg Daley > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 networking: Bad news for small biz
In message <53d036fb-14bf-43c5-942a-51bcc6149...@sabahattin-gucukoglu.com>, Sab ahattin Gucukoglu writes: > IPv6 networking: Bad news for small biz > ### You may not get fired for buying Cisco, but you can go bust > http://www.theregister.co.uk/2012/03/31/ipv6_sucks_for_smes/ > > =46rom the comments the author opines (among other things): > > The article exists for one reason: to let the high priests of the = > internet know =93oh, BTW, that NPT66 thing that? It=92s in products and = > in use in SME shops all over the damned place already.=94 In other = > words: the utter failure of the priesthood to engage care for the issues = > faced by SME outfits resulted in them (shockingly!) going out and = > choosing the cheap and simple alternative that actually already existed! = > Note the two key words: =93cheap=94 and =93simple.=94 > > > That's us he's talking about. It seemed only fair to share that = > perspective, since I don't see any other mention of the article here. = > Needless to say, I really can't speak in polite terms of some of the = > shortsightedness demonstrated. He is also talking rubbish. > But of course, I'm always delighted to hear your opinions. Is = > renumbering *really* that big of a deal? I suppose multihoming is the = > bigger, more serious concern - that's the one we see no viable solution = > but NAT for, given small site constraints and aggregation. Total hogwash. Add a bit of source address based routing within the enterprise so that you hit the right exit routers for the source address being used. Tag route entries with valid source prefixes. Add redirect based on source address signaling. > And yet, = > here we are, on our way to flipping the big switch, and nobody seems to = > be in much of a panic. I do not operate on sites large enough, or = > disaster-resistant enough, to know one way or the other how big of an = > issue this really is. My gut feeling is that this article is not the = > whole story and that the author has worked up a good whinge. But I do = > think the belligerent attitude in this article says we won't be long = > finding out just how far a NAT-free existence will get us. Especially = > true given how much blame we get for "Not thinking it through properly" = > or, worse, directly compared with OSI protocols with all those fancy = > network path discovery features that we felt we didn't need, = > application-layer DNS kludges for failover, etc, that would have = > remediated these problems if the naysayers are to be believed. No doubt = > there's work to be done. I see already the progress made in v6ops of = > IPv6 multihoming without NAT. Cool. And, of course, there's HomeNet = > for putting the title of this article into question. > > Cheers, > Sabahattin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <20120309100152.gb13...@nic.fr>, Stephane Bortzmeyer writes: > Also, some programs added non-standard extensions to this format (such > as BIND's $TTL). $TTL is defined in RFC 2181. $GENERATE is a BIND extension and is documented as such. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <201203090422.q294mra2012...@fs4113.wdf.sap.corp>, Martin Rex writes : > Mark Andrews wrote: > > > > > > > > "not permitted" would require a "must not", but > > > I only see a "should not" here: > > > http://tools.ietf.org/html/rfc1035#section-5.2 > > > > RFC 1035 pre-dates the formalisation of MUST NOT/SHOULD NOT etc. > > > > 5.2. Use of master files to define zones > > > > When a master file is used to load a zone, the operation should be > > suppressed if any errors are encountered in the master file. The > > rationale for this is that a single error can have widespread > > consequences. For example, suppose that the RRs defining a delegation > > have syntax errors; then the server will return authoritative name > > errors for all names in the subzone (except in the case where the > > subzone is also present on the server). > > > > How anyone could rationalize serving a zone with missing data after > > reading that I don't know. I do know that doing so does cause > > operational problems and fixing named to stop serving the zone on > > load errors was was one of the ealier things I did. > > A zone file loaded by a DNS server is not necessarily an authoritative > zone file! And for a non-authoritative zone, a partial zone might > be considerably better than no data at all. You were still authoritative for it, just not a official server. The act of loading from a zone file makes you authoritative. Your content may have been slightly older if it had been updated on the master but it was still complete for the version of the zone you had. You were also within the expected tolerences for changes to be made visible to everyone. Those are specified in the SOA record. > In 1993 we had a worldwide private network with modate-size links > to remote locations and the links would occasionally fail for a > few hours. So I setup *all* DNS servers (primary&secondaries, > delegated primaries&secondaries and caching-only) to obtain all > zones via XFER in a tree structure. > > > -Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <201203090223.q292nazs005...@fs4113.wdf.sap.corp>, Martin Rex writes : > Mark Andrews wrote: > > > > The incredibly huge base that returned NOERROR to type 28 queries > > when was defined. Almost all of the offending boxes were > > designed after was defined. > > > When was defined is marginally relevant. Since IPv6 was designed > as a completely seperate universe, it was flying below the radar > for most software apps developers for >10 years. I was first bothered > about IPv6 in 2004. > > Had there been versions of BIND exhibiting such behaviour? No. Unknown types were always NOERROR/NXDOMAIN. > I know that during its development, BIND sometimes adopted annoying > unnecessary backwards-incompatible changes that caused folks to > not upgrade. IIRC, suddenly refusing to load zone with hostnames > containing underscores was one BIND change I remember from my early > days as DNS admin, that caused me to ignore BIND software updates > for several years (waiting for the "offending" hosts to die of age). Which was controllable behaviour. > > Lots of them get responses to RFC 1035 types wrong. If you don't > > implement the type then you can't load the zone if it contains the > > type, partial zone loads are not permitted as per RFC 1035. > > "not permitted" would require a "must not", but > I only see a "should not" here: > http://tools.ietf.org/html/rfc1035#section-5.2 RFC 1035 pre-dates the formalisation of MUST NOT/SHOULD NOT etc. 5.2. Use of master files to define zones When a master file is used to load a zone, the operation should be suppressed if any errors are encountered in the master file. The rationale for this is that a single error can have widespread consequences. For example, suppose that the RRs defining a delegation have syntax errors; then the server will return authoritative name errors for all names in the subzone (except in the case where the subzone is also present on the server). How anyone could rationalize serving a zone with missing data after reading that I don't know. I do know that doing so does cause operational problems and fixing named to stop serving the zone on load errors was was one of the ealier things I did. > > If you have loaded the zone then the type doesn't exist, so it doesn't > > matter that you don't implement it, you therefore can't match the > > type as per RFC 1034 so the answer is NOERROR or NXDOMAIN depending > > apon whether the name exists in the zone or not. > > From these discussions, your explanations and my latest reading of > 1034/1035 I believe I have a hunch what might have happened (to our > internal DNS) when my w2k3 IPv6 stack freaked out... > > It might be related to the particular fashion in which I originally > set up the private DNS universe as an intern in 1993. And while I > joined development in 1995 and the tools I had written to to generate > the DNS zone files got replaced ~1999 with a commercial solution, > the structure of the private DNS universe seems to be still the > way I originally set it up. > > Thank you for your patience and elaborate responses. > > > > > So if the behaviour (how to exactly respond to queries for unknown > > > QTYPEs) is neither explicitly specified, nor likely have been part of > > > the usual/common interop tests performed by the vendor, > > > what you're left with might be "ureflected&untested guessing" > > > on part of the implementors to fill those gaps. > > > > > > Bottom line, the receiver must be VERY conservative with assumptions > > > about what exactly can be infered from error responses for situations > > > that are fairly vague in the spec and potentially untested in the > > > installed base. That is called "robustness principle". > > > > Which is why there are lots of SERVFAILs as you can't infer anything > > from NOTIMP. > > Servfail is supposed to be a transient error. > > What should a _new_ recursive non-authoritative server send as response > back to the stub resolver when it encounters a NOTIMP response from the > authoritative server for an query? Well the server should try the next server for the zone. If all of them return NOTIMP, SERVFAIL/NOTIMP. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <201203090107.q2917cth001...@fs4113.wdf.sap.corp>, Martin Rex writes : > Martin Rex wrote: > > > > So if the behaviour (how to exactly respond to queries for unknown > > QTYPEs) is neither explicitly specified, nor likely have been part of > > the usual/common interop tests performed by the vendor, > > what you're left with might be "ureflected&untested guessing" > > on part of the implementors to fill those gaps. > > What you typically have is a certain amount of code processing a query, > and some 3-4 conditions under which this code fails, and where the > implementor will have to decide which RCODE to return. The choices > available in rfc1035 are: > > RCODE Response code - this 4 bit field is set as part of > responses. The values have the following > interpretation: > > 0 No error condition > > 1 Format error - The name server was > unable to interpret the query. > > 2 Server failure - The name server was > unable to process this query due to a > problem with the name server. > > 3 Name Error - Meaningful only for > responses from an authoritative name > server, this code signifies that the > domain name referenced in the query does > not exist. > > 4 Not Implemented - The name server does > not support the requested kind of query. > > 5 Refused - The name server refuses to > perform the specified operation for > policy reasons. For example, a name > server may not wish to provide the > information to the particular requester, > or a name server may not wish to perform > a particular operation (e.g., zone > transfer) for particular data. > > 6-15Reserved for future use. > > > The choice between RCODEs 1, 2 and 4 for failed queries > might be fairly random, the description for 3 is slightly confusing > in whether a DNS server might use this RCODE "creatively" by > returning it without AA. > > For an implementor that is being told "do not use use RCODE 4 for > unknown QTYPES", not sending any response at all to an unsupported > query seems like a reasonable choice. They are much more likely to have been told "you should be sending NOERROR or NXDOMAIN not NOTIMP" rather than just "you should not be sending NOTIMP". There are nameservers that don't respond to EDNS queries for type A, class IN. FORMERR, NOTIMP, REFUSED all trigger a retry with plain DNS. Silence is much harder to work out what to do with and it takes much lnger. As silence can be caused by lots of things not just EDNS so you can't infer anything if you succeed with plain DNS. Success after FORMERR, NOTIMP or REFUSED, for an otherwise identical query, is a reasonable indication that EDNS is not supported. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <201203082359.q28nxpwu027...@fs4113.wdf.sap.corp>, Martin Rex writes : > Mark Andrews wrote: > > > > Martin Rex writes: > > > > > > Thanks for mentioning rfc 4074. The stuff in that document matches > > > the thoroughly broken behaviour of the IPv6 DNS resolver client of > > > Windows 2003 that I had encountered just recently. > > > > > > IMO, rfc4074 exhibits a significant amount of cluelessness about DNS, > > > the "Full Standard" document maturity level, and the realities of > > > backwards compatibilities for an incredibly huge installed base. > > > > So not answering a query because the type is 28 matches RFC 1034 > > behaviour? DNS is a query/response protocol. > > > > So returning NXDOMAIN because the query type is 28 when you have > > type 1 in the database matches RFC 1034 behaviour? > > > > Returning A record content in software written *after* type code > > 28 was defined matched RFC 103[45] behaviour? The same servers > > shove A rdata into TXT rdata. Everything is a A record. > > We started this with the NOTIMP, which is certainly a permissible > response for an query per rfc1035. > > What I briefly saw the win2003 DNS client doing in a wireshark trace > (which I forgot to save before I had to reboot after windows disabled > all networking) was visualized as a mixture of "no name" and "server fail" > for 23 consecutive lookups until ~18 seconds later the first A lookup > was finally sent. > I assume the two locally configured DNS Server were caching(-only) servers, > not authoritative ones (at least our current DNS Zones do not contain > NS records for any of the two). > > > Besides what you can deduce from the spec itself, you will also have > to take into account how that incredibly huge installed base was > created. A number of software vendors perform only black-box testing > and limited interop testing, so it will not be unusual that your > queries may be the first queries of that kind that a DNS responder > might be seeing. The incredibly huge base that returned NOERROR to type 28 queries when was defined. Almost all of the offending boxes were designed after was defined. Lots of them get responses to RFC 1035 types wrong. If you don't implement the type then you can't load the zone if it contains the type, partial zone loads are not permitted as per RFC 1035. If you have loaded the zone then the type doesn't exist, so it doesn't matter that you don't implement it, you therefore can't match the type as per RFC 1034 so the answer is NOERROR or NXDOMAIN depending apon whether the name exists in the zone or not. > So if the behaviour (how to exactly respond to queries for unknown > QTYPEs) is neither explicitly specified, nor likely have been part of > the usual/common interop tests performed by the vendor, > what you're left with might be "ureflected&untested guessing" > on part of the implementors to fill those gaps. > > Bottom line, the receiver must be VERY conservative with assumptions > about what exactly can be infered from error responses for situations > that are fairly vague in the spec and potentially untested in the > installed base. That is called "robustness principle". Which is why there are lots of SERVFAILs as you can't infer anything from NOTIMP. > -Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <201203081845.q28ijgf0006...@fs4113.wdf.sap.corp>, Martin Rex writes : > Tony Finch wrote: > > > > Murray S. Kucherawy wrote: > > > > > > I looked at least at the titles of all the documents that update 1035, > > > and none of them appear to be related to the above. So where should we > > > be looking? > > > > The only thing I have found that implies NOTIMP doesn't apply to queries > > for unknown RR types is in RFC 4074, "Common Misbehavior Against DNS > > Queries for IPv6 Addresses": > > Thanks for mentioning rfc 4074. The stuff in that document matches > the thoroughly broken behaviour of the IPv6 DNS resolver client of > Windows 2003 that I had encountered just recently. > > IMO, rfc4074 exhibits a significant amount of cluelessness about DNS, > the "Full Standard" document maturity level, and the realities of > backwards compatibilities for an incredibly huge installed base. So not answering a query because the type is 28 matches RFC 1034 behaviour? DNS is a query/response protocol. So returning NXDOMAIN because the query type is 28 when you have type 1 in the database matches RFC 1034 behaviour? Returning A record content in software written *after* type code 28 was defined matched RFC 103[45] behaviour? The same servers shove A rdata into TXT rdata. Everything is a A record. > The answer to the question "what can I infer from a failed lookup" > must be deduced from STD 13 **ALONE**, and it amounts to "very close to > nothing at all". > > Now this puts the slow adoption of IPv6 into perspective if it takes > the IPv6 crowds >10 years to figure that one out, > > > -Martin > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <9452079d1a51524aa5749ad23e00392807e...@exch-mbx901.corp.cloudmark.c om>, "Murray S. Kucherawy" writes: > > -Original Message- > > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mar > k Andrews > > Sent: Wednesday, March 07, 2012 3:28 PM > > To: m...@sap.com > > Cc: jo...@iecc.com; ietf@ietf.org > > Subject: Re: provisioning software, was DNS RRTYPEs, the difficulty with > > > > > Maybe you believe that NOTIMP should be limited to unsupported OPCODES on > ly? > > > But that is definitely not what the spec says. > > > > Yet someone else that can't count beyond 1035. > > Weren't you the one that said "Actually it is STD 13. Get over it." earlier > in this thread? Randy claimed that presentation formats were not standardised. They are. Randy and others claimed that the presentation formats were owned by BIND and they are not. I never claimed that STD 13 was the be all and end all w.r.t. DNS. STD 13 didn't follow the normal process required to make a STD. There are lots of corrections to STD 13 in the RFC series. > I looked at least at the titles of all the documents that update 1035, and no > ne of them appear to be related to the above. So where should we be looking? > > -MSK > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <201203072304.q27n4gdx000...@fs4113.wdf.sap.corp>, Martin Rex writes : > Mark Andrews wrote: > > > > Martin Rex writes: > > > Mark Andrews wrote: > > > > > > > > "John Levine" writes: > > > > > > > > > > In case it wasn't clear, this is an authoritative server. > > > > > > If this is about permitted RCODEs here > > > > > > http://tools.ietf.org/html/rfc1035#section-4.1.1 > > > > > > then an RCODE of 4 in the response looks like a perfectly valid response > > > for a DNS Server to a query, authoritative or not is irrelevant, and > > > if any client chokes on such an answer, it is likely the client that > > > is broken. > > > > No, its about what should be generated. NOTIMP != NOERROR no data. > > Maybe you believe that NOTIMP should be limited to unsupported OPCODES only? > But that is definitely not what the spec says. Yet someone else that can't count beyond 1035. > Generating RCODE 4 (NOTIMP) seems _perfectly_ permissible for a DNS server > when responding to a query for an QCLASS or QTYPE that the server > does not implement. > > 4 Not Implemented - The name server does > not support the requested kind of query. > > > 1034&1035 are both at document maturity level "Full Standard", > 1034 says: > > 3.7.1. Standard queries > > > A standard query specifies a target domain name (QNAME), query type > > (QTYPE), and query class (QCLASS) and asks for RRs which match. This > type of query makes up such a vast majority of DNS queries that we use > the term "query" to mean standard query unless otherwise specified. The > QTYPE and QCLASS fields are each 16 bits long, and are a superset of > defined types and classes. > > 1035 says: > > RCODE Response code - this 4 bit field is set as part of > responses. The values have the following > interpretation: > > 0 No error condition > > 1 Format error - The name server was > unable to interpret the query. > > 2 Server failure - The name server was > unable to process this query due to a > problem with the name server. > > 3 Name Error - Meaningful only for > responses from an authoritative name > server, this code signifies that the > domain name referenced in the query does > not exist. > > 4 Not Implemented - The name server does > not support the requested kind of query. > > 5 Refused - The name server refuses to > perform the specified operation for > policy reasons. For example, a name > server may not wish to provide the > information to the particular requester, > or a name server may not wish to perform > a particular operation (e.g., zone > transfer) for particular data. > > 6-15Reserved for future use. > > > -Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <20120307223904.gw79...@mail.yitter.info>, Andrew Sullivan writes:
> On Thu, Mar 08, 2012 at 08:49:22AM +1100, Mark Andrews wrote:
>
> > Take SPF as a example. If providers had supported UNKNOWN format
> > then the SPF generation tools would have done UNKNOWN + SPF type
> > specific rather than TXT + SPF.
>
> My father used to have a saying: "If Johnny hadn't died, they wouldn't
> have buried him." Counterfactuals in engineering are just not that
> interesting.
>
> But anyway, providers (I am employed by one, FWIW) are not going to
> blindly support UNKNOWN on the input side. That's just an invitation
> to behaviour we don't understand and therefore cannot price
> correctly.
Charge by records, bytes and queries. Nameservers don't care beyond that.
> More importantly, any plan that involves UNKNOWN types
> also automatically comes with unknown support costs.
These are "as is" services. You can add them and remove them. We don't
provide additional support beyond that.
> We will be
> forced to provide customer support for types we don't even know exist,
> and that will necessarily lead to unhappy customers.
You have unhappy customers now because they can't add record types
they would like to use.
As for support its possible to support for unknown type what more
can be expected of you beyond "does what is served match what is in
the database" and the pre-dnssec type code roll version of dig shows
that would be possible.
If you are worried about "this type may need special processing"
then provide a simple way for the customer to ask for the type code
to be added and base level support is "unknown record format"
advanced support is "type specific record format".
Mark
bsdi:marka 09:48 {104} % dig -t 46 dv.isc.org
; <<>> DiG 8.3 <<>> -t dv.isc.org
;; res options: init recurs defnam dnsrch no-tld-query edns0
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1819
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 6
;; QUERY SECTION:
;; dv.isc.org, type = TYPE46, class = IN
;; ANSWER SECTION:
dv.isc.org. 1H IN TYPE46\# 94 ( ; unknown RR type
00 06 05 03 00 00 0e 10 4f a1 d8 a5 4f 52 b0 95 ; O...OR..
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 62 7b ; 8d.dv.isc.org.b{
3d c8 d0 31 85 0a 71 c3 cf 43 69 e4 9c f9 05 34 ; =..1..q..Ci4
31 6f d3 8f a3 c4 12 f0 0d 00 61 6f be 35 0b 9e ; 1oao.5..
1c 85 5a 6a 6d e8 15 87 f6 d4 30 ee b4 57 35 e4 ; ..Zjm.0..W5.
7c 54 46 ac be 65 b5 48 c2 9f fe 4a 0a 26 ) ; |TF..e.H...J.&
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 02 05 03 00 01 51 80 4f 8b 89 c2 4f 3c 63 3e ; ..Q.O...O
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 92 a7 ; 8d.dv.isc.org...
13 64 9d 31 85 aa 31 28 99 a0 7c af 56 a1 7b 0c ; .d.1..1(..|.V.{.
8f 99 4d bc c0 a2 38 b0 92 0f ed fc 77 fc f5 f8 ; ..M...8.w...
bb ff 38 8e f0 e2 a6 08 65 8a 3b 98 4b ee e1 ea ; ..8.e.;.K...
5a e8 9f 71 4d 41 10 ba f2 84 58 a8 5e 14 ) ; Z..qMAX.^.
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 0f 05 03 00 01 51 80 4f 8b 89 c2 4f 3c 63 3e ; ..Q.O...O
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 23 71 ; 8d.dv.isc.org.#q
d1 ff e6 08 6d a6 6c 4e 94 92 c7 83 e5 21 23 f7 ; m.lN.!#.
37 58 51 b5 0f f6 a2 d6 68 6b 83 8e 73 fb 46 b0 ; 7XQ.hk..s.F.
e5 c3 93 7b 5f 4f 79 9f ee 14 9e 7f 4e 8a e2 65 ; ...{_Oy.N..e
55 e4 99 d8 14 64 43 4a b6 9e ac 90 1c ee ) ; UdCJ..
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 2f 05 03 00 01 51 80 4f 96 dc 75 4f 47 bd 1c ; ./Q.O..uOG..
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 7a b5 ; 8d.dv.isc.org.z.
3b 7f 55 0d 46 ca 29 29 9d 3c 93 74 fd b5 96 35 ; ;.U.F.)).<.t...5
76 d4 65 18 fe 8a c2 17 42 e2 0a ba 38 9f ea 96 ; v.e.B...8...
5f 84 cc f0 6e df a2 da 83 c9 40 13 da e6 8c 3a ; _...n.@:
66 3c 7f 4e 92 6b d5 cc e0 5f 8a f5 49 be ) ; f<.N.k..._..I.
dv.isc.org. 1D IN TYPE46\# 158 (; unknown RR type
00 30 05 03 00 01 51 80 4f 8b 9e 5a 4f 3c 79 a8 ; .0Q.O..ZO A plan something like the one John Levine has proposed is the only
> viable one, in my view.
>
> Best,
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "John R. Levine" wr ites: > >>> Most provisioning systems really don't care about most of the data > >>> they are throwing about. It may as well be a opaque blob. ... > > >> Assuming you're not talking about editing zone files with vi, can you give > >> some specific examples of what you're talking about? > > > > Most provisioning systems ... > > Hi. Could you give some concrete examples of DNS provisioning systems > that let you enter arbitrary RRs? I've never seen one in the wild, other > than the one I wrote for myself. > > Yes, I know that hypothetically they could do all sorts of stuff. But > they don't. I well know they don't because they are still stuck in 1980's think mode. It's how do we get then out of 1980's think mode and get them to use some of the tools that were provided to them nearly a decade ago now. How do we apply the clue bat to the CTO and the CEO of these provisioning providers to get them to come out of the dark ages? ICANN might be able to do some something. Lots of their accredited registrar are also in the provisioning business. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "John R. Levine" wr ites: > Gee, by sheer random walk this has wandered back to the original topic, > that provisioning software is the major bar to deploying new RRs. > > > Most provisioning systems really don't care about most of the data > > they are throwing about. It may as well be a opaque blob. > > I couldn't disagree more. Other than my own homebrew system, all the > provisioning systems I know support a handful of specific RR types and > make it somewhere between painful and impossible to install anything else. > > Godaddy's is a good and very large example of this. They have a "wizard" > to create an SPF record, but it turns out to be a TXT record. If you want > a real type 99 SPF record, you're out of luck. > > Assuming you're not talking about editing zone files with vi, can you give > some specific examples of what you're talking about? Most provisioning systems dump the records into a database and have some other process extract them from the database and build the input to the nameserver. Those database records are also what the customer updates when they next come back. One of the problems with provisioning systems is they are mostly based on a pre RFC 3597 view of the world where you *needed* to know the type specific presentation format to enter the data. In a post RFC 3597 world it is possible to enter any record you want with a common format. You can dump that record straight into the nameserver, nsupdate or any other RFC 3597 aware tool and it will handle it. GoDaddy, for example, could handle HIP, SSHFP and IPSECKEY with the same input dialog if they wanted to by accepting the UNKNOWN record format. They could also handle the next type that is invented with that same dialog box. Stop asking for type support and ask for UNKNOWN record support from your provider. UNKNOWN record support will handle type and anything new that will come along. By supporting UNKNOWN record format, providers get to know which types are actually being used by their customers and can then hire developers to add support for the types that are actually being used. Tools to convert between UNKNOWN and type specific representations will appear. They are trivial to write. This is the sort of thing a 1st year CS student should be able to write as a learning exercise. I would give the one type to convert for the exercise but that the level of skill needed. Take SPF as a example. If providers had supported UNKNOWN format then the SPF generation tools would have done UNKNOWN + SPF type specific rather than TXT + SPF. Mark > Regards, > John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , =?iso-8859-1?Q?Pa trik_F=E4ltstr=F6m?= writes: > > On 7 mar 2012, at 03:49, John R. Levine wrote: > > >> However we do have standard presentation/entry formats defined and a good > >> front end will accept those as well. > > > > Sigh. Now we're back to "people who don't do it my way are wrong", so I gu > ess we're done. > > I disagree. > > "People who don't accept the standardized zone format are wrong" is Mark's st > atement. > > What you say is "as people do not support the standardized zone format as inp > ut, what do we do". > >Patrik The point of RFC 3597 was to provide a STANDARD text representation that could handle any DNS record format. It isn't pretty but as long as you accept it and emit it you are future proof. Its a lowest common format. A 1.2.3.4 == TYPE1 \# 4 01020304 Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. Pretty is for the next revision of the provisioning software. Look at what data you have in raw format and use that to decide what you need to handle in a prettier manner in the next revision. You don't even need to to change the database tables. It's just front end presentation that needs to be changed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <201203070539.q275dmj8001...@fs4113.wdf.sap.corp>, Martin Rex writes : > Mark Andrews wrote: > > > > "John Levine" writes: > > > > > > In case it wasn't clear, this is an authoritative server. > > If this is about permitted RCODEs here > > http://tools.ietf.org/html/rfc1035#section-4.1.1 > > then an RCODE of 4 in the response looks like a perfectly valid response > for a DNS Server to a query, authoritative or not is irrelevant, and > if any client chokes on such an answer, it is likely the client that > is broken. No, its about what should be generated. NOTIMP != NOERROR no data. > -Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , Randy Bush writes: > > One of point of having standard presentation formats is that they > > facilitate data interchange. > > bind's zone format is not a standard, and many implementations are not > compatible with it. get over it. Actually it is STD 13. Get over it. > randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "John R. Levine" wr ites: > > However we do have standard presentation/entry formats defined and a good > > front end will accept those as well. > > Sigh. Now we're back to "people who don't do it my way are wrong", so I > guess we're done. One of point of having standard presentation formats is that they facilitate data interchange. I can use my tools to generate the records and your system can just accept it. Having to re-format data is a pain. If you want to do something else as well there is no problem with that. It's a little like credit card numbers. Breaking them up into 4 boxes of 4 digits and having to move the focus between boxes is a absolute pain. These should be cut and pastable, with or without spaces in the middle. There are international standards for telephone numbers but every web developer seems to think they know best. > Regards, > John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <20120307000814.29422.qm...@joyce.lan>, "John Levine" writes:
> >> > Last month I ran into a guy on the dmarc list who complained that his
> >> > server returns NOTIMP in response to queries for SPF records ("because
> >> > it doesn't implement them") and clients were doing odd things. But
> >> > it's been a long time since I've run into anyone else like that, so I
> >> > agree, it's not an issue.
>
> In case it wasn't clear, this is an authoritative server.
A authoritative server should be returning NOERROR / NXDOMAIN not
NOTIMP provided the zone loads otherwise SERVFAIL if the load fails
for any type other than those in the reserved meta type range. If
the data isn't in the zone and the name is in use NOERROR is the
response you send. If the name isn't in use NXDOMAIN is the response
you send. Failure to load all of the zone is supposed to stop any
of it being served according to RFC 1035.
If you want to be a nameserver developer you don't stop counting
at 1035. The meta type range was initially reserved in RFC 2929
(Sep 2000).
> >A RFC 1035 recursive server should be able to handle SPF. It's
> >just a opaque data blob to it with a name, type, class and ttl
> >attributes.
>
> Agreed. Other than a few dusty Suns still running obsolete BIND 4.x,
> I don't know of any DNS caches that have problems with arbitrary RRs.
>
> R's,
> John
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "John R. Levine" wr ites: > >> They're not implementation specific, but they're also not required to > >> interoperate, as the wire format queries and responses are. > > > > They are a interchange standard as per RFC 1034. > > Yes, we all know that. But as I presume you also know, there are plenty > of DNS servers that store the zone info in other ways, ranging from djbdns > mutant syntax text files to various databases. > > Whatever the server uses, the provisioning system better match. BIND stores zones in other ways as well. You just have to be able accept them and produce them or else you don't have a comforming implementation. > > The standard format of master files allows them to be exchanged between > > hosts (via FTP, mail, or some other mechanism); this facility is useful > > when an organization wants a domain, but doesn't want to support a name > > server. The organization can maintain the master files locally using a > > text editor, transfer them to a foreign host which runs a name server, > > and then arrange with the system administrator of the name server to get > > the files loaded. > > That is one implementation. But it's far from the only one. > > My system has a web front end that lets my users edit groups of their > djbdns RRs, which it stores in a database. Once an hour, a perl script > goes through the database, regenerates the mutant text files, and stuffs > them into the name servers. It's not fabulous, but it gets the job done. Nobody says you can't have propriatry methods of data entry. However we do have standard presentation/entry formats defined and a good front end will accept those as well. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <4f564ac2.1040...@tana.it>, Alessandro Vesely writes:
> On 06/Mar/12 16:00, John R. Levine wrote:
> >
> >>> We seem to believe that the "D" part is deployed so that adding new
> >>> "unknown" RRTypes is not an issue.
> >>
> >> I think this is correct, but OTOH someone recently asked about
> >> possible issues in this area, and if I remember correctly,
> >> received no response.
> >
> > Last month I ran into a guy on the dmarc list who complained that his
> > server returns NOTIMP in response to queries for SPF records ("because
> > it doesn't implement them") and clients were doing odd things. But
> > it's been a long time since I've run into anyone else like that, so I
> > agree, it's not an issue.
>
> Hm... I have no idea how such response gets cached. RFC 2136 says
> that "an appropriate error will be returned to the requestor's caller"
> when RCODE is SERVFAIL or NOTIMP.
>
> Is that the same case that Scott noticed when he wrote:
>
>Particularly when querying for SPF records of type SPF, persistent
>2 ServFail results are /not rare/.
>
>http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html
>(emphasis added)
> ?
>
> IIRC there was also a mirroring issue...
>
> At least, I think these issues will gradually vanish as the software
> at the relevant servers gets upgraded.
A RFC 1035 recursive server should be able to handle SPF. It's
just a opaque data blob to it with a name, type, class and ttl
attributes. To serve SPF a RFC 1035 needed to be upgraded as it had
no way to store / load the record.
DNS software developers should read Section 3.6. "Defining new types,
classes, and special namespaces", especially the sentence:
New definitions should be expected.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "John R. Levine" wr ites: > >> I was also going to mention that. There's a lot of different formats for > zone > >> file data, with BIND-ish master files being only one of them. > > > > DNS master files are specified in RFC 1035 so it's wrong to imply they are > > implementation-specific. > > They're not implementation specific, but they're also not required to > interoperate, as the wire format queries and responses are. They are a interchange standard as per RFC 1034. The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn't want to support a name server. The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded. > Regards, > John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly > _______ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , Tony F inch writes: > Mark Andrews wrote: > > > > I would say DNS master file representation -> DNS wire representation > > is one of the main issues on the provisioning side. This conversion > > needs to be done at some point. > > John's draft addresses that. > > > The other this is verification of the input. > > What kind of verification? > > Tony. Most front ends want to make sure what they are feeding to the back ends wont make it choke. It also make for a better user experience. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message <77075c8c-04ed-48a2-b501-b2296bcfc...@frobbit.se>, =?iso-8859-1?Q?Pa
trik_F=E4ltstr=F6m?= writes:
> I think we should look a bit on the flow of data. If I simplify we have a flo
> w like this:
>
> Input -P-> DNS server -D-> DNS stub -Q-> Output
>
> P is the provisioning
> D is the DNS protocol
> Q is the query/parsing in the consumer of the data
>
> What we want is (as described in the IAB RFC on extensions of DNS) the abilit
> y to query (in D) for as precise data as possible in the triple {owner, type,
> class}. Some RR types like NAPTR and TXT have flaws where the selection betw
> een records in an RRSet is not in this triple. In some applications that is r
> esolved by having a prefix to the owner. In some other applications that is r
> esolved by parsing the RRSet.
>
> We all do believe that IF it was easier to add a new RRType for each applicat
> ion that would be an architecturally better solution (as adding prefix to the
> owner have its drawbacks). Now, the question is what blocks the ability to a
> dd new RRTypes.
>
> We seem to believe that the "D" part is deployed so that adding new "unknown"
> RRTypes is not an issue.
>
> Problem is then in "P" and "Q".
>
> And when we talk about parsing, we talk about what the mapping between provis
> ioning and DNS packet format is.
>
> Are we aligned so far?
>
>Patrik
I would say DNS master file representation -> DNS wire representation
is one of the main issues on the provisioning side. This conversion
needs to be done at some point. The other this is verification of
the input.
DNS wire representation -> text or structured object on the application
side. Part of the issue here is that some libraries don't provide
hooks to return unknown types as a raw data blob so even if you can
enter the data there isn't a exit path. I don't know what such
library developers were thinking. There has been a long but slow
history of new types being added to the DNS and the original set
of types was never expected to be sufficient for all uses.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message , "John R. Levine" wr ites: > >> By the way, what's your opinion of draft-levine-dnsextlang-02? > > > > It isn't clear to me what problem you're trying to solve. For resolving > > name servers 3597 should be enough. For authoritative name servers your > > idea is sort of interesting, but generally upgrading the software to > > pick up support for new RRtypes is a good idea, since you'll also pick > > up new security fixes, etc. > > Oh, wow. Now I see the problem: people here are totally unaware of what > using DNS software is like if you're not a DNS weenie. > > If you think that it's reasonable to require a new version of your DNS > software every time there's a new RR, you've conceded total defeat. On > most servers I know, software upgrades are risky and infrequent. It could > easily take a year for a new version of BIND to percolate out of the lab, > into the various distribution channels, and to be installed on people's > servers, by which time everyone has built their applications with TXT > records and it's too late. Well for BIND it's add a new file that defines the type's methods and recompile. That isn't a whole new version. > Moreover, the servers aren't the hard part, it's the provisioning systems. > You and I may edit our zone files with emacs, but civilians use web based > things with pulldown menus and checkboxes. If they can't enter an RR into > one of them it doesn't matter whether the name server supports it or not. > This latest round of teeth gnashing was provoked by discussions in the > spfbis WG, where we're wondering whether to deprecate the type 99 SPF > record. Among the reasons it's unused in practice is that nobody's > provisioning system lets you create SPF records. Which is why there is a format for unknown types. You can cut and paste them as easily as known types. Unfortunately the provision systems often do a subset of RFC 1035 types let alone anything newer. Basically they are often just plain garbage. > The point of my draft is that it's an extension language that both name > servers and provisioning systems can read on the fly. Add a new stanza to > /etc/rrtypes and you're done, no software upgrades needed. The risk is > much lower since the worst that will happen if the new stanza is broken is > that the provisioning software and name servers will ignore it, not > that the whole thing will crash. > > Sure, there are some RRs with complex semantics that can't be done without > new code (DNSSEC being the major example), but most RRs are syntactically > and semantically trivial, just a bunch of fields that the server doesn't > even interpret once it's parsed the master records or their equivalent. > > Until the DNS crowd admits that provisioning systems are a major > bottleneck, and telling people to hand-code more types into them isn't > going to happen, there's no chance of getting more RRs deployed. Until provisoning systems accept UNKNOWN record types they will always be a bottle neck. Without that you will have to wait for the change request to be processed. Given the history just getting records added to most of these system it will be forever. All the tools we ship support UNKNOWN record types and classes. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
In message <20120229013632.9326.qm...@joyce.lan>, "John Levine" writes: > >If your DNS hosting company doesn't support them find another one > >or complain to them. You are paying them to host your DNS services > >and this is a basic part of the job. > > Can you suggest some DNS hosting companies that provide support for > provisioning SPF records? I'm not aware of any. SPF is listed. http://dyn.com/dns/dns-comparison/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
In message <9452079d1a51524aa5749ad23e00392804c...@exch-mbx901.corp.cloudmark.co m>, "Murray S. Kucherawy" writes: > > -Original Message- > > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Doug > Barton > > Sent: Tuesday, February 28, 2012 2:24 PM > > To: John Levine > > Cc: ietf@ietf.org > > Subject: Re: DNS RRTYPEs, the difficulty with > > > > Intelligent sysadmin: We need to deploy SPF > > Boss: How does it work? > > I: Well, eventually it will have its own DNS RR, but for now it works > > with TXT records > > B: Ok, put those TXT records in > > > > I: It's now possible to use SPF RRs for SPF, so I need to make some > > changes, do some testing, etc. > > B: Are the TXT records working now? > > I: Well yes, but ... > > B: We have more important priorities that I need you to spend your time > > on, leave the thing that's working alone. > > > > Or, put more simply, your conclusion seems to be that we can never add > > new RRs. Given that adding new RRs is crucial to the growth of the > > Internet, I reject that conclusion completely. > > Your scenario illustrated the problem nicely: People started SPF with TXT reco > rds because they were available and the road to a new RRType was seen as a ste > ep one. Once that was even a little bit deployed, it became practically irrev > ersible. The same happened with DKIM, and then VBR, and now it's basically co > mmon practice to use naming tricks to sidestep the RRType arguments. > > I think the right endgame here is to make sure new RRTypes are accessible to t > hose that want to have them. This will remove the temptation to start with TX > T and, ultimately, stay there. They are there. They were there when SPF was being developed. They were there when DKIM was being developed. It's just the neigh sayers won out. Libresolv has supported unknown types for 25 years. Other C libraries support them. dnspython supports them. dnsjava supports them. It really isn't hard to get a length tagged blob of data back to the application. Authoritative nameservers support them. Recursive nameservers support them and always have modulo bugs. If your DNS hosting company doesn't support them find another one or complain to them. You are paying them to host your DNS services and this is a basic part of the job. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
In message <0b7e91ed-d286-4065-a91a-79032bf6a...@email.android.com>, Scott Kitte rman writes: > > > Doug Barton wrote: > > >On 2/27/2012 5:56 PM, John Levine wrote: > > > >> The problem is provisioning software. We weenies can stuff anything > >> into our DNS servers we want, because we use vi and emacs and (in my > >> case) custom perl scripts. For the other 99.5% of the world, what > >> they can put in their DNS zones is limited to whatever the web > >> provisioning software at their registrar or ISP or web host supports, > >> and I challenge you to find any that supports SPF records. > > > >I have been both the author and a consumer of the types of interfaces > >that you're describing, and I had a very peripheral role in the work to > >evangelize interface support for new TLDs, IPv6, and DNSSEC; so I'm > >familiar with the issue. My experience with these issues tells me that > >when there is demand to support a new RRtype, it will be supported. > > > >So, once again, we need to learn from the mistakes that were made with > >SPF. Here is how life goes in most busy enterprise environments: > > > >Intelligent sysadmin: We need to deploy SPF > >Boss: How does it work? > >I: Well, eventually it will have its own DNS RR, but for now it works > >with TXT records > >B: Ok, put those TXT records in > > > >I: It's now possible to use SPF RRs for SPF, so I need to make some > >changes, do some testing, etc. > >B: Are the TXT records working now? > >I: Well yes, but ... > >B: We have more important priorities that I need you to spend your time > >on, leave the thing that's working alone. > > > >Or, put more simply, your conclusion seems to be that we can never add > >new RRs. Given that adding new RRs is crucial to the growth of the > >Internet, I reject that conclusion completely. > > The original SPF work was done outside the IETF, so no amount of "Hey, you can > 't do that" would have made a difference. Unless it's dead easy for new design > s to use new RR Types it will be very difficult to get them deployed. > > It's not dead easy until the more global deployment problems are solved. > > Scott K As someone who has deploy a new type globally it isn't that hard. The hardest part as convincing the IESG that I wasn't trying to cirumvent what was happening with DNSSEC. I've even taken it from a private type (65323) to a documented type (32769). http://tools.ietf.org/html/rfc4431 Yes, I work for a name server vendor but nothing I did couldn't have been done by anyone else. We get have the occassional submission of code to support a new type. We also get requests to add a new type. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
In message <4f4c1106.4020...@gmail.com>, Hector writes: > Mark Andrews wrote: > > Many web interfaces are little more than line text editors with a pulldown > > list for the type. Very few are more than that. The data just gets passed, > > as text, to a backend which adds it to a database / zone. Lots of those > > backends already support the new type. The only change that needs to be > > made is to add a type to the pull down list. > > > > In one support case, gigantic isp to remain nameless, the addition of > new TXT-based protocol support now caused "wildcard conflicts" between > SPF and DKIM. > > Customer to us: What records to I add? > > Us: Use our tool-generated records and contact ISP - they should have > a "Total DNS management" web based system, to add the generated > records there. > > They did, there was a conflict with getting DKIM records and SPF > records, two different name spaces. Which is one of the reasons DNS people argued and argued and argued that TXT was not the right solution for DKIM. The IETF can still correct this by adding a DKIM type and deprecating the prefix. :-) > Us: Constant ISP, they should allow you to separate SPF and DKIM records. > > ISP to Customer: Nothing wrong, its all fine. Just add it under TXT. > > Customer to US: Is this your BUG? > > Us: It has to be the ISP, lets check it out - Remote support. > > There was no specific way to separate TXT records, it was all lump > under one input. > > US: Contact ISP, tell them what we told you. > > Customer to US: VOILA, fixed, ISP fixed it with a special prefix you > add to the record. No. You just need a interface that lets you specify the domain name of the record you are adding. > Basically, what they did was independent of the pull down, the > editable field allowed you to add the subdomain prefix. > > Whatever! :) > > Agree, it isn't so far to update the frontend, but we can't always > blame the ISP when the specification isn't all clear. If the > impression is that TXT is good enough, then the expense to do code > change is less justified. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
Many web interfaces are little more than line text editors with a pulldown list for the type. Very few are more than that. The data just gets passed, as text, to a backend which adds it to a database / zone. Lots of those backends already support the new type. The only change that needs to be made is to add a type to the pull down list. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
In message <20120226064025.gh8...@1wt.eu>, Willy Tarreau writes: > On Fri, Feb 24, 2012 at 05:57:31PM +0100, Patrik F=E4ltstr=F6m wrote: > > I am asking more generally why specifically this DNS issue is so stuck, > > because I think that is unfair. We upgrade other protocols... > > Because in HTTP, anybody can be anywhere. You can have client-side proxies, > server-side gateways, load balancers, etc... everyone in this chain may or > may not resolve, it's only a matter of configuration and architecture choic= > e. > There are plenty of places where clients won't access public resolvers at a= > ll > and rely on their proxies for this. So you can't make use of DNS to improve > these users' experience. Proxies can lookup SRV records. They already lookup A and records. > Also, DNS is SW. It's fast enough to send a mail. But for HTTP > it adds too much latency. Some people in the mobile world would like to be > able to configure an explicit proxy on their smartphones in order to avoid > a very expensive round trip before fetching an object : at 20 host names > on a web page, 300 ms round trip means 6 seconds are lost to resolve these > objects if they can't be totally parallelized. If they can't be parallelized then you can blame the page developer. As for SRV you can always do SRV + + A in parallel. > DNS suggestion is something going back and forth regularly. I think that > people who try to push it hard only see the very simple case where users > have a direct low-latency internet connection. The reality is much much > different. This well reflected by the fact that in the end, after many > proposals, it has still not been adopted ! > > Regards, > Willy > > _______ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
Additionally, java and python both support unknown types. Adding new types in both of these appears to be straight forward. C has always suppported unkown types. If your favourite language / OS doesn't support unknown types complain to the developer / vendor. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with
In message <3503462.Q2aCvq3QGU@scott-latitude-e6320>, Scott Kitterman writes: > On Monday, February 27, 2012 12:32:11 PM Paul Hoffman wrote: > > On Feb 27, 2012, at 11:57 AM, Murray S. Kucherawy wrote: > > >> -Original Message- > > >> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf > > >> Of Patrik F=E4ltstr=F6m Sent: Monday, February 27, 2012 11:43 AM > > >> To: Hector > > >> Cc: ietf@ietf.org > > >> Subject: Re: DNS RRTYPEs, the difficulty with > > >> = > > > >> I have not heard anything else than arguments in RFC5507 against > > >> reusing same RRType for many different kind of use. > > >> = > > > >> 5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R. > > >> = > > > >> Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT=3D44045 > > >> bytes) > > >> (Status: INFORMATIONAL) > > >> = > > > >> So, still, no, you should not reuse TXT. You should have your own > > >> RRType. Other choices makes your design very complex. > > >> = > > > >> Yes, many people will still disagree with me, using arguments I do not > > >> agree with... > > > = > > > > The conclusion of Section 3.5 of that document doesn't really address > > > the first bullet in the same section, namely that the user interface by > > > which the new RRType would get added to a zone often doesn't support > > > doing so. That's turned out to be a serious problem with, for example, > > > the deployment of the SPF record (RRType 99). > > Which user interfaces are people using to add RRtype 99? If you are having > > them edit zone files by hand well, yes, that would not work real well for > > SPF. If there is a simple tool that takes the needed information and crea= > te > > a standard-formatted record that can be copy-and-pasted, it would make use > > of that RRtype much easier. If no such tool exists, I propose that it can > > be created easily. > > We've published a script to take a Type TXT SPF record and give a Type SPF = > > output as part of the pyspf library since very shortly after Type SPF was = > > assigned. It's been around for years, so the lack of that type of tool isn= > 't = > > an issue. > > Scott K My user interface is "vi". RFC 4408 April 2006 revision 1.1 date: 2005-07-14 16:46:44 +1000; author: marka; state: Exp; branches: 1.1.2; 1892. [func] Support for SPF rdata type. [RT #15033] It was first available in BIND 9.4.0 (Feb 2007) earlier still if you were willing to run alpha/beta/rc. OS vendors could have supplied it earlier. cp lib/dns/rdata/generic/txt_16.c lib/dns/rdata/generic/spf_19.c cp lib/dns/rdata/generic/txt_16.h lib/dns/rdata/generic/spf_19.h s/TXT/SPF/ s/txt/spf/ s/16/99/ make clean make You don't even have to touch a Makefile. After that all the tools that come with BIND support SPF. If I remember correctly someone did something like that and made it available. Its definitely been done for a number of new types. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS RRTYPEs, the difficulty with (was: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis))
In message <20120224171427.gj48...@mail.yitter.info>, Andrew Sullivan writes: > cc:s trimmed. I'm not on the w3c list anyway, and I don't think the > IESG cares about this detail. > > On Fri, Feb 24, 2012 at 04:58:36PM +0100, Patrik Fältström wrote: > > > > Because people disagree on whether it is actually hard to get new > RRTYPEs deployed. > > > > I for example do completely disagree on it being hard. Sure, your user > interface in the gui of your favorite $EDITOR might not support the new > RRTYPE, but should that constrain deployment of good standards? > > > > Before those who think DNS weenies never listen to real-world problems > jump in, I want to point out what _I_ understand to be a problem. If > you're a DNS geek, then the natural thing to think is, "This is easy. > You just send a well-crafted UDP packet. How hard could that be? > Once the typecode is assigned, what's the problem with sending an > unknown RR?" > > If you're most application programmers, however, the entire conversation > ended at "send a well-crafted UDP packet". Your libraries don't > support injecting well-crafted UDP packets, and you have no idea how > to do that, and it's incredibly stupid, and why would anyone think > that was reasonable anyway? > > If you're most sysadmins, the entire conversation ended at "My tools > don't know what TYPE1234 is." > > If we seriously think that DNS RRTYPEs ought to be useful extensions > to people, we're going to have to make them _easy_ to deploy, not just > possible. I have no idea how to solve this problem, though. > > Best, > > A It's a simple library call in Windows to get SRV records returned. What windows doesn't have is the ability to lookup new types but SRV has been supported for over a decade now. DNS_STATUS WINAPI DnsQuery( __in PCTSTR lpstrName, __in WORD wType, __in DWORD Options, __inout_opt PVOID pExtra, __out_optPDNS_RECORD *ppQueryResultsSet, __out_optPVOID *pReserved ); http://msdn.microsoft.com/en-us/library/windows/desktop/ms682016(v=vs.85).aspx Posix: though you do have to parse the result. int res_query(const char *dname, int class, int type, u_char *answer, int anslen); There are libraries that will extact the records and return them as a list of length data blobs. You just need to parse the individual records. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
In message <4f46bfdf.3070...@dougbarton.us>, Doug Barton writes: > For my money it would be quite important for an HTTP 2.0 definition to > make SRV DNS records a full-fledged participant in the standard. Minimum > once a month there is someone asking for help on bind-users@ for which > the answer is, "The solution to that _would_ be SRV records, if they > were supported." > > 2782 was published 12 years ago this month. I suppose it can be > considered mature enough to deploy at this point? :) +1000 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
In message <201202231651.q1ngpxgl017...@fs4113.wdf.sap.corp>, Martin Rex writes : > Bob Hinden wrote: > > > > Martin Rex wrote: > > > > > > With a fully backwards compatible transparent addressing scheme, > > > a much larger fraction of the nodes would have switched to actively > > > use IPv6 many years ago. > > > > Right, just like they could have deployed dual stack many years ago too. > > Just two days ago I had an extremeley disappointing experience with IPv6. > Windows XP 64-bit (aka Win2003sp2) on a local network with a private > DNS universe, IPv4 only network, Windows IPv6 protocol stack installed > but IPv6 active only on the two virtual network interfaces of VMware. > > Somehow the DNS servers configured in the network settings had performed > only a partial zone reload and were replying only to some queries, > failing some DNS queries with server failure or timeout, > and one DNS zone had become completely invisible. > > I noticed the problem suddenly during work because every new connection > took ~16 seconds delay to complete. Wondering what was wrong, I started > wireshark. > > I saw Windows2003 send out 23 DNS lookups for records for the > requested hostname over the course of 16 seconds (some of which returned > server failure, some of which failed with no such name), > until Windows 2003 finally decided to also try a DNS A query--which got > immediately successfully answered and the connection was established. > The delay affected each and every connection attempt, even when contacting > the same host repeatedly (although there is a DNScache service running...). > > Disabling IPv6 on all network adapters did not stop this Windows frenzy, > I had to actually uninstall the IPv6 protocol stack (an action which > immediately kills *ALL* network connectivity of the machine and requires > a reboot to recover...) for this nonsense to end. > > During the past few years I had two similar encounters with sudden severe > connectivity problems on a Windows XP and a Linux installation, and > both times, the problem disappeared when I disabled IPv6. > > It is also significantly easier to configure the firewall for IPv4-only... > > -Martin > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf We (ISC) learned a long time ago (last century) that partial DNS service for a zone is worse than total failure for a zone. By totally failing a zone on error it gets fixed instead of trying to limp by on partial service. I also suspect the search algorithm is not stopping on NOERROR NODATA or SERVFAIL. Searches really should stop on both those conditions. By stopping I mean not going onto the next element in the search list without getting a NXDOMAIN response. You can ask multiple servers on SERVFAIL. I've been arguing this for around 10+ years. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with "prefer IPv6" [Re: Variable length internet addresses
In message <201202232352.q1nnqniq011...@fs4113.wdf.sap.corp>, Martin Rex writes : > Mark Andrews wrote: > > > > ned+i...@mauve.mrochek.com writes: > > > > > > Which brings us right back to my original point: This definition of > > > "ready" is operationally meaningless in many cases. > > Correct. > > > > > I contend that OS are IPv6 ready to exactly the same extent as they > > are IPv4 ready. This isn't a IPv6 readiness issue. It is a > > *application* multi-homing readiness issue. The applications do > > not handle unreachable addresses, irrespective of their type, well. > > The address selection rules just made this blinding obvious when > > you are on a badly configured network. > > There was *NO* multihoming involved at all. What addresses were there on the loopback interface? If there were IPv4 and IPv6 addresses then it was dual stack multi-homed machine. Applications need to work over the loopback interface as much as they need to work over a external interface. Having a IPv4 address on the loopback interface is NOT a given. A application MUST work over the loopback interface when it does not have a IPv4 address. I've yet to work on a machine that was not multi-homed to some extent. All of the machines I've worked on in the last 25 years have had multiple interfaces. > The OS of my primary workmachine has in IPv6 protocol stack with > an extremely bogus design that pretty much precludes any kind > of migration and testing. It delays sending DNS A lookups (in favour > to lookups) for whooping 16 seconds to DNS servers for which > only an IPv4 address is known over an interface that is IPv4-only > with a default route over that very same IPv4-only interface. > And even disabling IPv6 on the two virtual network interfaces > did not stop that non-sensical behaviour. If there is a 16 second delay you can blame the authoritative server adminstrators for either installing a non RFC compliant nameserver or misconfiguring a delegation which is detectable by looking at the negative response. The returned records are inconsistent with the delegation. DNSSEC however will help fix this as broken delegation like this don't work for positive signed answers either with a general purpose nameserver whereas that can be overlooked with simple testing in a non DNSSEC environment. A RFC 1035 compliant nameserver is quite capable of answering "I have no type 28 records at this name" or this name doesn't exist to a type 28 query. A RFC 1035 recursive server should also handle the lookup and return of type 28 records as opaque blobs of data. This is why compression pointers are only supported on "well known types" in RFC 1035 so it could handle records that it doesn't know the internal structure of. The only thing a RFC 1035 server can't do is serve records. Serving records requires a newer server. Secondly there is no evidence that asking for records is due to a OS problem or a application problem. Without reading the source code there is no way to know. > It just doesn't make sense to send out less DNS A lookups than > DNS lookup, and even less to delay DNS A queries for 16 seconds. Actually it can make sense to make queries. Knowing whether there are addresses or not can change how you behave when you can't reach the machine over IPv4 assuming there are A records. > The only solution was to rip IPv6 out of the OS entirely. Luckily > I had access to the console of the machine, because when requesting > uninstall of that (inactive) IPv6 protocol stack, the machine > immediately dropped *ALL* networking on all interfaces, > ipconfig /all gives an empty list, as if remote administration > of servers was a concept completely unknown to the OS vendor. > > If there is desire for widespread adoption of some new protocol > or feature, than it is a very very very very bad idea to create > such an extremely misbehaved implementation. And it's not like > "this is brand new and we didn't have time yet to fix this bug". Making a should add 1 round trip lookup, in most cases that's much less than 200ms to the startup of a application assuming no caching. If there is caching or overlapping queries the additional time can drop to nano seconds. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with "prefer IPv6" [Re: Variable length internet addresses in TCP/IP: history]
In message <01occ10b11tc00z...@mauve.mrochek.com>, ned+i...@mauve.mrochek.com w rites: > > On 02/23/2012 14:48, Ned Freed wrote: > > >> On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote: > > >>> Old news perhaps, but an unavoidable consequence of this is that the > > >>> oft-repeated assertions that various systems have been "IPv6 ready for > over 10 > > >>> years" don't involve a useful definition of the term "ready". > > > > > >> The OP specified "IPv4 only network." I suspect that if he had IPv6 > > >> connectivity his experience would have been quite different. I happily > > >> use Windows XP on a dual-stack network, for example. > > > > > > And systems running these old OS versions never under any circumstances m > ove > > > from one network to another where connectivity conditions change. Riiight > . > > > Brian already covered "unconditional prefer-IPv6 was a painful lesson > > learned," and I'm not saying that those older systems did it right. What > > I am saying is that for most values of "IPv6 Ready" which included > > putting the system on an actual IPv6 network, they worked as advertised. > > Which brings us right back to my original point: This definition of "ready" i > s > operationally meaningless in many cases. I contend that OS are IPv6 ready to exactly the same extent as they are IPv4 ready. This isn't a IPv6 readiness issue. It is a *application* multi-homing readiness issue. The applications do not handle unreachable addresses, irrespective of their type, well. The address selection rules just made this blinding obvious when you are on a badly configured network. No one expect a disconnected IPv4 network to work well when the applications are getting unreachable addresses. Why do they expect a IPv6 network to work well under those conditions? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
In message <9bbaf712-d199-4950-a516-33c830756...@checkpoint.com>, Yoav Nir writes: > > On Feb 16, 2012, at 4:48 PM, Roger J=F8rgensen wrote: > > > On Thu, Feb 16, 2012 at 3:34 PM, Yoav Nir wrote: > > > >> I think that an endorsement like "I work for Cisco and we intend to impl= > ement this in every one of our products" is useful. But it's not nearly as = > useful as "this is a terrible idea, and doing this will prevent IPv6 from e= > ver gaining traction". The objections raised in last call are really the po= > int, not the endorsements. > > = > > > = > > > Think I've read somewhere that the ground of good engineering (the E > > in IETF) are being able to argue against your own idea, search and > > look for flaws in it, and all in the name of testing it to see how it > > can be made even better, is it good enough? Or simple to consider the > > bigger picture, can my idea hurt the rest no matter how good it is? > > There are great and very good ideas out there that isolated are > > fantastic, but considered in just a bit bigger picture are horrible, > > they've ruin everything around them. > > I agree. IPv4 forever using CGNs may work for a lot of people and a lot of = > uses. If people remain double- or triple-natted it won't matter a bit to th= > e big web sites. = > > > It's far more important to hear what is not going to work with this solutio= > n. > > It's great if you can find such deficiencies in your own ideas, but we stil= > l need design reviews, code reviews, QA departments and IETF last calls so = > that others can get at your idea. To all of you saying that this only supports IPv4 only boxes. How do I connect up my Windows XP (with IPv6 enabled) or later box, Linux box (from anywhere in the last decade), *BSD box (from anywhere in the last decade), Apple box (from anywhere in the last decade) and get both IPv4 and IPv6 without being handed a IPv4 address via DHCP. That list pretty much covers the home computer space of dual stack computer space. People keep saying IPv6 provides additional solutions, and it does, however there is a enormous dual stack legacy device problem out there and saying "go IPv6 only" just isn't a viable for those devices yet. They still need a IPv4 address via DHCP which has all the issues a IPv4-only box has. There are dual stack CPE routers today that won't provide IPv4 unless there is address space provided via DHCP. I've got one and at some point my ISP will need to go the CGN route for IPv4. I don't know if there will be a firmware update to support IPv4 over IPv6 or if there is it will match the solution my ISP will choose. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
In message <201202142245.q1emjaou019...@fs4113.wdf.sap.corp>, Martin Rex writes : > The necessary changes to applications would be minimal, > the "happy eyeballs" contortion completely unnecessary > and the security assessment for an IPv6 enabled network > *MUCH* simpler. Happy eyeballs just points out problems with multi-homing in general. IPv4 has the *same* problem and sites spend 1000's of dollars working around the issue which could have been addressed with a couple of extra lines of code on the client side in most cases. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
In message
, Cameron Byrne writes:
> On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews wrote:
> >
> > In message <201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp>, Martin Rex =
> writes
> > :
> >> Brian E Carpenter wrote:
> >> >
> >> > On 2012-02-14 05:51, Noel Chiappa wrote:
> >> > > =A0 =A0 > From: Arturo Servin
> >> > >
> >> > > =A0 =A0 >> Are you volunteering to buy everyone on earth a new CPE? =
> If not, w
> >> ho
> >> > > =A0 =A0 >> do you suggest will?
> >> > >
> >> > > =A0 =A0 > I suggest the ISPs, they are charging for the service, rig=
> ht?
> >> > >
> >> > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. i=
> n our
> >> > > house, both our cable modem and the router attached to it are ours.
> >> >
> >> > Sure, that's very common, but these devices are consumer electronics a=
> nd
> >> > will get gradually replaced by IPv6-supporting boxes as time goes on.
> >> > (That is not hand-waving, the generation of boxes with IPv6 support is
> >> > starting to appear.) Nobody, I think, is denying that there will be a =
> long
> >> > period of coexistence as a result.
> >> >
> >> > That is a separate question from this draft, which gives ISPs space fo=
> r
> >> > *growing* their IPv4 customer base. I think that is what upsets people=
> .
> >>
> >>
> >> The problem of ISP not newly shipping CPE that is not IPv6 capable
> >> needs to be addressed by regulatory power (legistation), rather than
> >> by ignorance of the part of the IETF.
> >>
> >>
> >> ISPs *growing* their IPv4 customer base is a natural side effect
> >> whenever ISPs allow customers to use equipment that they already
> >> have (and might have been using with a different ISP before).
> >
> > You grow your IPv4 customer base by having new customers independent
> > of whether they are IPv6 customers as well. =A0I don't think there
> > is a customer that only wants to connect to IPv6 sites.
> >
> > Having IPv6 doesn't even cut down on needing to supply IPv4 unless
> > you have bleeding edge IPv6 equipment. =A0People still need to connect
> > to IPv4 literals and that will, for a quite a while yet, mean
> > supplying a dual stack service.
> >
> > NAT64 doesn't have a way to inform the CPE on the mapping needed.
> > It would be simple to do with DHCP but know one had written what
> > needs to be in the option.
> >
> > Similarly 464XLAT doesn't provide a way for the CPE to find the
> > prefix. =A0Blindly performing 464XLAT has similar issues to blindly
> > performing 6to4.
> >
>
> 464XLAT may indeed discover the PREF64 using
> http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05
draft-ietf-behave-nat64-discovery-heuristic-05 really isn't a solution.
It doesn't say anything about choosing the A records such that there
is no abmiguity when look for the embedded address.
It doesn't have the exceptions which are part of DNS64. This means
you can't use it reliably with dual stack internal and IPv6-only
external.
Below is the DNS64 configuration elements from named.
dns64 {
break-dnssec ;
clients { ; ... };
exclude { ; ... };
mapped { ; ... };
recursive-only ;
suffix ;
};
While not all of them are required for IPv4 literals more than netprefix and
suffix are required which is all draft-ietf-behave-nat64-discovery-heuristic-05
delivers.
> Running code says 464XLAT works with IPv4 literals, IPv4 referrals,
> and IPv4 socket APIs.
> CB
>
> > DS-Lite only became a RFC in the second half of 2011. =A0It will take
> > some time for IPv6 equipment vendors to add support (hosts and
> > routers).
> >
> >> The vast majority of customers does not know or care about not having IP=
> v6,
> >> because there is _very_ few equipment that is vitally dependent on IPv6,
> >> vs. huge amounts of equiment that requires IPv4. =A0If I had a CPE that
> >> supported IPv6 (mine is from early 2006 an IPv4-only), my concern would
> >> be how to reliably switch IPv6 off, because of the unsolved security and
> >> privacy problems that IPv6 brings along.
> >>
> >>
> >> It was the IETFs very own decision to build IPv6 in a fashion that it is
> >> not transparently backwards compatible with IPv4. =A0If the is anyone to
> >> blame for the current situ
Re: Last Call:
In message <201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp>, Martin Rex writes : > Brian E Carpenter wrote: > > > > On 2012-02-14 05:51, Noel Chiappa wrote: > > > > From: Arturo Servin > > > > > > >> Are you volunteering to buy everyone on earth a new CPE? If not, w > ho > > > >> do you suggest will? > > > > > > > I suggest the ISPs, they are charging for the service, right? > > > > > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our > > > house, both our cable modem and the router attached to it are ours. > > > > Sure, that's very common, but these devices are consumer electronics and > > will get gradually replaced by IPv6-supporting boxes as time goes on. > > (That is not hand-waving, the generation of boxes with IPv6 support is > > starting to appear.) Nobody, I think, is denying that there will be a long > > period of coexistence as a result. > > > > That is a separate question from this draft, which gives ISPs space for > > *growing* their IPv4 customer base. I think that is what upsets people. > > > The problem of ISP not newly shipping CPE that is not IPv6 capable > needs to be addressed by regulatory power (legistation), rather than > by ignorance of the part of the IETF. > > > ISPs *growing* their IPv4 customer base is a natural side effect > whenever ISPs allow customers to use equipment that they already > have (and might have been using with a different ISP before). You grow your IPv4 customer base by having new customers independent of whether they are IPv6 customers as well. I don't think there is a customer that only wants to connect to IPv6 sites. Having IPv6 doesn't even cut down on needing to supply IPv4 unless you have bleeding edge IPv6 equipment. People still need to connect to IPv4 literals and that will, for a quite a while yet, mean supplying a dual stack service. NAT64 doesn't have a way to inform the CPE on the mapping needed. It would be simple to do with DHCP but know one had written what needs to be in the option. Similarly 464XLAT doesn't provide a way for the CPE to find the prefix. Blindly performing 464XLAT has similar issues to blindly performing 6to4. DS-Lite only became a RFC in the second half of 2011. It will take some time for IPv6 equipment vendors to add support (hosts and routers). > The vast majority of customers does not know or care about not having IPv6, > because there is _very_ few equipment that is vitally dependent on IPv6, > vs. huge amounts of equiment that requires IPv4. If I had a CPE that > supported IPv6 (mine is from early 2006 an IPv4-only), my concern would > be how to reliably switch IPv6 off, because of the unsolved security and > privacy problems that IPv6 brings along. > > > It was the IETFs very own decision to build IPv6 in a fashion that it is > not transparently backwards compatible with IPv4. If the is anyone to > blame for the current situation, than it is the IETF, not the consumers > or the ISPs (except for those folks at ISPs who participated in the > development of IPv6). > > > -Martin > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Mark Andrews writes: > > In message <20120212204623.gl27...@besserwisser.org>, =?iso-8859-1?Q?M=E5ns?= > N > ilsson writes: > > On Sat, Feb 11, 2012 at 08:39:03PM -0500, Noel Chiappa wrote: > > > > From: Doug Barton > > > > > > We already have a way to make collisions "very unlikely," don't use > > > > either of 192.168.[01]. = > > > > > I gather that that's not desirable, because otherwise people wouldn't be > > > asking for another block. Of course it could probably be made to work > > > somehow - with enough thrust, etc, etc. But that's not the point - engine > = > > ering > > > is (or ought to be) all about balancing costs and benefits. > > > > Close. The cost to these late adapters without sensible business plans > > will be higher if they aren't given this allocation. > > How is this a "late adapter" problem? You either have enough > addresses to give every customer a IPv4 address or you don't. If > you don't have enough addresses you are going to have to use some > sort of CGN whether that is NAT444 or AFTR or some other transition > technology which shares IPv4 addresses. And if you restrict it to those that do IPv4 literals there isn't much other than NAT444 and AFTR and how many cpe's support B4 at this point? > Isn't the IETF's preferred transition strategy still "dual stack" > or are you thinking that ISP's that can't get enough IPv4 address > have to go IPv6 only? > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
In message <20120212204623.gl27...@besserwisser.org>, =?iso-8859-1?Q?M=E5ns?= N ilsson writes: > On Sat, Feb 11, 2012 at 08:39:03PM -0500, Noel Chiappa wrote: > > > From: Doug Barton > > = > > > > We already have a way to make collisions "very unlikely," don't use > > > either of 192.168.[01]. = > > > = > > > I gather that that's not desirable, because otherwise people wouldn't be > > asking for another block. Of course it could probably be made to work > > somehow - with enough thrust, etc, etc. But that's not the point - engine= > ering > > is (or ought to be) all about balancing costs and benefits. > > Close. The cost to these late adapters without sensible business plans > will be higher if they aren't given this allocation. How is this a "late adapter" problem? You either have enough addresses to give every customer a IPv4 address or you don't. If you don't have enough addresses you are going to have to use some sort of CGN whether that is NAT444 or AFTR or some other transition technology which shares IPv4 addresses. Isn't the IETF's preferred transition strategy still "dual stack" or are you thinking that ISP's that can't get enough IPv4 address have to go IPv6 only? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
In message <6.2.5.6.2.20120209091221.082cb...@resistor.net>, SM writes: > Hi Chris, > At 08:57 AM 2/9/2012, Chris Grundemann wrote: > >http://www.apnic.net/publications/news/2011/final-8 > > I am aware of the APNIC announcement. That's one out of five regions. > > >Are you proposing that every ISP on the planet be given a /10 for > >inside CGN use, rather than one single /10 being reserved for this > >purpose? > > No. > > If I am not mistaken, IPv4 assignments are on a needs basis. In my > previous comment, I mentioned that RIRs are still providing unique > IPv4 assignments to service providers that request IPv4 > addresses. Even if the IANA pool was not exhausted, it is unlikely > that an ISP would get a /20 due to the slow-start mechanism. > > Regards, > -sm In none of the discussions I've seen has anyone proposed forcing ISP's to use this space. It is being provided as a alternative, the same away RFC 1918 space is offered as a alternative. Today you get ask "have you considered RFC 1918 space?" You can still get space even if RFC 1918 space would have worked. I suspect a similar question, will be part of allocation proceedures, for this space in the future. You need to know that the applicant is aware of this space. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
