Re: provisioning software, was DNS RRTYPEs, the difficulty with
On Wed, Mar 07, 2012 at 05:21:40PM -0500, John R. Levine jo...@iecc.com wrote a message of 22 lines which said: 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. My registrar and DNS hoster, Gandi http://www.gandi.net/ allows it, in a mode called Expert mode. As its name suggest, it is not easy to use (you have to translate the record in RFC1035-section5 format yourself). There is of course a User mode with the usual closed list of known types, and easy entry of values. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On Thu, Mar 08, 2012 at 01:10:24PM +1100, Mark Andrews ma...@isc.org wrote a message of 45 lines which said: 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. A better description of the situation would be there is a standard format, standardized in section 5 of RFC 1035 and in many other RFC for new RR types and its standard description is quite poor, with many unspecified things, so, in practice, a zone file accepted by a compliant implementation may not always work with another. Today, the IESG would never accept the sloppy language of RFC 1035. Also, some programs added non-standard extensions to this format (such as BIND's $TTL). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Murray S. Kucherawy m...@cloudmark.com 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: 4.3. Return Other Erroneous Codes Other authoritative servers return a response with erroneous response codes other than RCODE 3 (Name Error). One such RCODE is 4 (Not Implemented), indicating that the servers do not support the requested type of query. But I guess that NOTIMP *would* be an appropriate response if the request is for an unknown QTYPE between 128 and 255. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Mainly northeasterly 4 or 5, occasionally 6 in southeast Fitzroy. Moderate, becoming rough or very rough except in southeast Trafalgar. Fair. Good, occasionally poor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Martin Rex m...@sap.com wrote: Btw. the updates metadata on rfc1035 looks like a big mess to me. Expecting *anyone* to read all of the documents and merge them in their heads while implementing is completely unrealistic. http://blog.nominet.org.uk/tech/2010/05/24/436/ - DNS RFC dependency graphs Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Hebrides, Bailey, Fair Isle: West or southwest 6 to gale 8, occasionally severe gale 9. High or very high. Rain or squally showers. Moderate or good, occasionally poor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Tony Finch wrote: Murray S. Kucherawy m...@cloudmark.com 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. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Martin Rex wrote: Tony Finch wrote: Murray S. Kucherawy m...@cloudmark.com 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. 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. In case this isn't clear: this applies to DNS responses with one of the failure RCODEs (1,2,3,4,5) defined in rfc1035 _unless_ the response is accompanied by some protocol extension that can be used to **reliably** distinguish 1034/1035 DNS responders from those conforming to a later, optional DNS protocol extension. -Martin ___ 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 m...@cloudmark.com 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
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. 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 ureflecteduntested 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. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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 ureflecteduntested 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. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Sorry, s/some 3-4 conditions/some 3-4 dozen conditions/ Martin Rex wrote: 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 ureflecteduntested 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. -Martin ___ 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 ureflecteduntested 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 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 ureflecteduntested 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
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? 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). 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 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 ureflecteduntested 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? -Martin ___ 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 ureflecteduntested 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
Mark Andrews wrote: 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. +1, this seems logical. What is perhaps ultimately important to a developer is its application translation of DNS query results, including the application tracking for the redundancy of failures. *Rhetorically,* does a NOIMP enable an automated trigger to disable a specific DOMAIN query? Should a protocol translate SERVFAIL as an application temporary or permanent failure? Can a temp status change to permanent due to redundancy?, etc. -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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. 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 (primarysecondaries, delegated primariessecondaries and caching-only) to obtain all zones via XFER in a tree structure. -Martin ___ 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 (primarysecondaries, delegated primariessecondaries 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
There are some false equivalences floating around here. I don't think anyone is suggesting that having provisioning systems or even DNS servers themselves check for syntax errors in the contents of complex records like DKIM, SPF, DMARC, or whatever is necessarily a bad idea. (Whether or not it will actually happen is another matter; I'm dubious.) Rather, the issue is with requiring it to happen in order to deploy a new RRTYPE of this sort, which is the result you get if the DNS server returns some series of tokens instead of the original text string. That's the sort of thing that forces people to upgrade, or search around for a script to do the conversion (which won't even occur to some), and that's an extra burden we don't need to impose. It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. You're still not separating the two cases. Again, an *optional* plugin to check syntax of a record but not produce any sort of tokenized result is fine, a plugin that's *mandatory* to deploy is going to be almost as much of an impediment to deployment as requiring an upgrade. Code is code, and people don't install new code willy-nilly. The issue is to upgrade once rather than on each new RR type. Exactly. That's why mandatory plugins are a bad idea. Correct, but when you publish a complex record you are calling forth that complexity. I don't see much difference if the bug is at mines or at the remote site, since their effects are comparable. They most certainly are not. A bug in my client only affects me, a bug in the server can easily kill the entire zone. And even if separation techniques are employed, if the plugin fails the best you're going to be able to do is server out a domain with missing entries. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 07/Mar/12 09:42, ned+i...@mauve.mrochek.com wrote: It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. You're still not separating the two cases. I think I did, however badly. Let me try by example, assuming my server doesn't recognize SPF. As it's unrecognized, I have to write it as such, e.g. TYPE99 \# 12 0B 763D73706631 20 2D613131 Again, an *optional* plugin to check syntax of a record but not produce any sort of tokenized result is fine, Now the plugin can check the syntax and spot the error. I may correct it or not. If I don't, I'll just serve bad data. In any case, my zone source still contains the line above. Thus the plugin is optional. a plugin that's *mandatory* to deploy is going to be almost as much of an impediment to deployment as requiring an upgrade. Code is code, and people don't install new code willy-nilly. Possibly, I can also run, say: echo 'SPF v=spf1 -a11' | plugin --dump-hex --silent and have it dump the TYPE99 line above (without signalling the error, since I said --silent). Then I copy its output and paste it into the zone source. Finally, I can enable automatic invocation of the plugin. That way, I can write the SPF record directly in the zone source and have my DNS-fictional server do the copy and paste on the fly for me. I wouldn't call such thing mandatory. Correct, but when you publish a complex record you are calling forth that complexity. I don't see much difference if the bug is at mines or at the remote site, since their effects are comparable. They most certainly are not. A bug in my client only affects me, a bug in the server can easily kill the entire zone. Ooops, yes, that's right. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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? 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 07/Mar/12 09:42, ned+i...@mauve.mrochek.com wrote: It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. You're still not separating the two cases. I think I did, however badly. Let me try by example, assuming my server doesn't recognize SPF. As it's unrecognized, I have to write it as such, e.g. TYPE99 \# 12 0B 763D73706631 20 2D613131 OK, now I'm completely confused. What does lack of SPF record support in your server input format have to to with syntax checking of the *content* of the SPF record? I can write the record as text or in hex or base64 or whatever format I want; the issue is looking *inside* the data and either (a) just checking it's syntax versus (b) checking it and turning it into some kind of tokenized stuff the DNS server actually serves out. Again, an *optional* plugin to check syntax of a record but not produce any sort of tokenized result is fine, Now the plugin can check the syntax and spot the error. I may correct it or not. If I don't, I'll just serve bad data. In any case, my zone source still contains the line above. Thus the plugin is optional. a plugin that's *mandatory* to deploy is going to be almost as much of an impediment to deployment as requiring an upgrade. Code is code, and people don't install new code willy-nilly. Any plugin that's necessary to transform a nontrivial input format into a tokenized result is effectively mandatory. Sure, you can substitute a preprocessing script that does the transform and spits out hex or whatever, but no matter how you do it there's an essential translation component involved in provisioning those records. You may be able to avoid having that component cause the entire server fail, but it's still in the critical path for setting up those records. Possibly, I can also run, say: echo 'SPF v=spf1 -a11' | plugin --dump-hex --silent and have it dump the TYPE99 line above (without signalling the error, since I said --silent). Then I copy its output and paste it into the zone source. Let's please stop talking about what you can do manually. This isn't about people whose main provisioning tool is emacs or bind, and who operate their own servers with full autonomy and report to nobody. This audience doesn't have issues with any of this stuff. Finally, I can enable automatic invocation of the plugin. That way, I can write the SPF record directly in the zone source and have my DNS-fictional server do the copy and paste on the fly for me. I wouldn't call such thing mandatory. Again, it depends on whether or not it's in the critical provisioning path. A syntax checker isn't, a parser and tokenizer is. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203070926260.60...@joyce.lan, 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
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. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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. More importantly, any plan that involves UNKNOWN types also automatically comes with unknown support costs. We will be forced to provide customer support for types we don't even know exist, and that will necessarily lead to unhappy customers. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203071719100.78...@joyce.lan, 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
Most provisioning systems ... I well know they don't because they are still stuck in 1980's think mode. ... 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. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Mark Andrews wrote: 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. +1 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. +1 Tools to convert between UNKNOWN and type specific representations will appear. They are trivial to write. and most likely its specifics to tied to backend I/O storage methods. Not everything is a droppable text file and not everyone is going to be using EDLIN, QEDIT, NotePad or some *nix flavor text editor. Bind hass command line (CLI) tool to automatic the process of addng unnamed types, I am trying to find out if Windows DNS 5.0 DNSCMDS does, and so far it doesn't. But Microsoft .NET Provisioning API does support the creation of unnamed resource records. But from what I am reading so far, it seems to have been abandon starting with VS2010. I posted a question in the MSDN Directory Services and Network Infrastructure Servers support forums and so far, NADA. Personally, I thought this was resolved with DNS 5.0 which finally did add direct support for the previous wish list unknown type SRV and other records required for AD (Active Directory) and DNSSEC. But if the reality is such that the Default Window Server brand (not desktop brands) with its already optional installation DNS server option, does not come with an out of the box RFC3597 support by now, even if undocumented or via a registry option, well, its beating a dead horse now. I am all ready to support going with TXT only for SPF. 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. +1. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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. 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. 10341035 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 ___ 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...Oc
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...Oc
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..ZOy.
28 30 02 64 76 03 69 73 63 03 6f 72 67 00 24 51 ; (0.dv.isc.org.$Q
3c 2c 11 00 3f 77 aa ea 5f 94 f7 fc f6 9a 97 af ; ,..?w.._...
58 29 ef 76 3d a7 4b ab ea 90 f4 15 ac 22 7c 27 ; X).v=.K..|'
b2 cc e6 8b 1e 6b f9 b0 ba c8 7c 49 60 ed a8 4d ; .k|I`..M
89 1d c6 c4 f0 e9 a5 16 5f 4e ad 59 17 5d cf ce ; _N.Y.]..
79 a3 8a 81 8b 06 30 12 c4 27 8d 87 7a 0a 7f d5 ; y.0..'..z...
65 2e 1e 63 35 98 6c 38 dc 0a e0 75 40 1d 0b 75 ; e..c5.l8...u@..u
51 b6 cb 6d a7 b8 08 6f 46 f7 2a bf c5 7b 3c 56 ; Q..m...oF.*..{V
5b 84 17 fd a4 43 22 dd b0 99 db c2 9f 33 ) ; [C..3
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 30 05 03
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. 10341035 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
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark 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 only? 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? 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? -MSK ___ 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
Mark Andrews wrote: 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. That does not matter here. By assigning the full standard document maturity label to rfc1034/rfc1035 There are lots of corrections to STD 13 in the RFC series. That is a misunderstanding of the standards process. The only corrections to rfc1034/rfc1035 that exist are those that have been filed as errata and confirmed (accessible with the Errata URL here): http://tools.ietf.org/html/rfc1034 http://tools.ietf.org/html/rfc1035 But even the posted erratas are soft and not visible here: http://tools.ietf.org/html/std13 The only document that could be reasonably expected to be considered be a new implementation is rfc2181 (plus maybe rfc4343), although you have to keep in mind that neither of this is mentioned by STD13. Btw. the updates metadata on rfc1035 looks like a big mess to me. Expecting *anyone* to read all of the documents and merge them in their heads while implementing is completely unrealistic. The normal implementation approach is to use the base specification plus a clarifications document if one exists, implement the mandatory parts of that, and ship the result as a first step. As a second step, depending on requirements and funding/resouces, selected optional features from the base spec and from other optional protocol extensions may get added. 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? To answer the question does my client have to expect and cope gracefully with an RCODE 4 response, only 1034/1035 and the filed erratas are relevant. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Mark Andrews ma...@isc.org 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. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Plymouth, Biscay: Variable 4, becoming west 5 to 7. Moderate or rough. Rain or showers. Good, occasionally poor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.lsu.2.00.1203061314260.22...@hermes-2.csi.cam.ac.uk, Tony F inch writes: Mark Andrews ma...@isc.org 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
Input -P- DNS server -D- DNS stub -Q- Output P is the provisioning I think you want to break that into the provisioning interface and the data format it produces that the DNS server consumes. (My reason for that is we have a specification for at least such format, with all that implies.) 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. 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. Problem is then in P and Q. I personally don't see a big problem with Q, but others clearly do so we need to leave it in. I'm not aware of problems, but I don't use Windows which is where the problems are supposed to be. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Input -P- DNS server -D- DNS stub -Q- Output P is the provisioning I think you want to break that into the provisioning interface and the data format it produces that the DNS server consumes. (My reason for that is we have a specification for at least such format, with all that implies.) 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. 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. Problem is then in P and Q. I personally don't see a big problem with Q, but others clearly do so we need to leave it in. I'm not aware of problems, but I don't use Windows which is where the problems are supposed to be. Exactly - neither do I. (Well, OK, I have a Windows laptop at work to handle the company HR stuff that won't work in anything other than IE, but I try really, really hard never to use it.) Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 06/Mar/12 04:56, ned+i...@mauve.mrochek.com wrote: On 05/Mar/12 18:09, John Levine wrote: Would you really want to build an SPF or DKIM parser into every DNS server? That's a lot of code that the DNS manager doesn't care about, but the mail manager does. But it would be the same code, most likely by the same author(s). There are some false equivalences floating around here. I don't think anyone is suggesting that having provisioning systems or even DNS servers themselves check for syntax errors in the contents of complex records like DKIM, SPF, DMARC, or whatever is necessarily a bad idea. (Whether or not it will actually happen is another matter; I'm dubious.) Rather, the issue is with requiring it to happen in order to deploy a new RRTYPE of this sort, which is the result you get if the DNS server returns some series of tokens instead of the original text string. That's the sort of thing that forces people to upgrade, or search around for a script to do the conversion (which won't even occur to some), and that's an extra burden we don't need to impose. It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. Why is it important what the DNS manager cares about? Speaking as a DNS manager myself, I care a lot about being forced to upgrade. Upgrades bring unwanted bugs in other areas. (I'd be surprised if bugs in any area were wanted ;-) The issue is to upgrade once rather than on each new RR type. In fact I'm not entirely thrilled with the idea of plugins to do some extra syntax. More code means more possibilities of bugs. I'd actually prefer to see more cross-checking of existing stuff - less code and greater benefit. Depending on how the plugin mechanism is engineered, code insulation, data encapsulation, and component tests against large samples of data may help reduce bugs. To me, an important point is that zone files keep containing data source, rather than the output of possibly unreproducible commands. Diagnostic-mode execution of the plugin together with a text-based /etc/rrtypes may even allow to mechanically build GUI dialogs for each type, whether for the web or for the desktop. Parsers, including null parsers, would come with the same sub-package that enables the new RR type definition. Their complexity would only matter to the people who read/maintain their sources. I'm sorry, but you're being naive about this. Complexity does matter to the people who just use software because added complexity translates to more bugs. Correct, but when you publish a complex record you are calling forth that complexity. I don't see much difference if the bug is at mines or at the remote site, since their effects are comparable. Generating zone files full of hex escapes, so as to do without any plugin, can --perhaps should-- stay possible. However, I doubt that such usage would result in less bugs, on average. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
John R. Levine jo...@iecc.com wrote: 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. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber, Thames: Variable, becoming southwest, 4, increasing 6 to gale 8. Slight or moderate, occasionally rough later. Showers, rain later. Good, occasionally poor later. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On Tuesday, March 06, 2012 06:34:58 PM Alessandro Vesely wrote: 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. I don't think it's the same. It's been awhile since I had data because I simply stopped doing any type SPF queries in software I use or support due to issues with it (and there's no upside to go expend effort on revisiting the issue), but these were definitely SERVFAIL and not NOTIMP, but either would have had the same effect of a permanent temporary error. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203061203020.14...@joyce.lan, 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
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. 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. 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
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
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 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203061711470.25...@joyce.lan, 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
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. 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
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
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 Yes, we all know that. My point, which I would have thought was obvious, was that it's been a long time since I've run into anyone whose server was broken like that. As I said, it's not an issue. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203062148410.34...@joyce.lan, 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
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. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message m2obs9f3bj.wl%ra...@psg.com, 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
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. -Martin ___ 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
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 guess we're done. I disagree. People who don't accept the standardized zone format are wrong is Mark's statement. What you say is as people do not support the standardized zone format as input, what do we do. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message d468354f-be26-41d4-9f75-ea10c5189...@frobbit.se, =?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
On 3 mar 2012, at 17:29, Scott Kitterman sc...@kitterman.com wrote: Sometimes an ASCII text record will be fine, in other cases, it probably won't. My point is as we move again towards multiple text representations of the digit five for example, both encoding and parsing is easier and more secure if that digit is really for example eight bits and not text that someone has to parse. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Sometimes an ASCII text record will be fine, in other cases, it probably won't. My point is as we move again towards multiple text representations of the digit five for example, both encoding and parsing is easier and more secure if that digit is really for example eight bits and not text that someone has to parse. Unless you provision your DNS zones with a hex debugger, the digit will always start out as text that someone has to parse. The question is who does the parsing, the DNS server or the application. As I said in a previous message, I can see plausible reasons to put the parser into the application. Would you really want to build an SPF or DKIM parser into every DNS server? That's a lot of code that the DNS manager doesn't care about, but the mail manager does. R's, John PS: For anyone who didn't read my previous message, I am NOT saying that it's fine to overload everything into TXT. I am saying that new RRTYPEs that are text blobs interpreted by client software wouldn't necessarily be bad. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 05/Mar/12 18:09, John Levine wrote: Sometimes an ASCII text record will be fine, in other cases, it probably won't. My point is as we move again towards multiple text representations of the digit five for example, both encoding and parsing is easier and more secure if that digit is really for example eight bits and not text that someone has to parse. Unless you provision your DNS zones with a hex debugger, the digit will always start out as text that someone has to parse. The question is who does the parsing, the DNS server or the application. As I said in a previous message, I can see plausible reasons to put the parser into the application. Would you really want to build an SPF or DKIM parser into every DNS server? That's a lot of code that the DNS manager doesn't care about, but the mail manager does. But it would be the same code, most likely by the same author(s). It may be generic for a kind of syntax or specific for a RR type, according to its author's convenience. On a system that allows new RR types without recompiling, the code would come as some sort of plugin in both cases. Why is it important what the DNS manager cares about? Parsers, including null parsers, would come with the same sub-package that enables the new RR type definition. Their complexity would only matter to the people who read/maintain their sources. PS: For anyone who didn't read my previous message, I am NOT saying that it's fine to overload everything into TXT. I am saying that new RRTYPEs that are text blobs interpreted by client software wouldn't necessarily be bad. Agreed. That doesn't preclude syntax checking on loading the zone, though. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Alessandro Vesely wrote: Why is it important what the DNS manager cares about? Parsers, including null parsers, would come with the same sub-package that enables the new RR type definition. Their complexity would only matter to the people who read/maintain their sources. +1 PS: For anyone who didn't read my previous message, I am NOT saying that it's fine to overload everything into TXT. I am saying that new RRTYPEs that are text blobs interpreted by client software wouldn't necessarily be bad. Agreed. That doesn't preclude syntax checking on loading the zone, though. As a Windows shop, there is no hiding of the long product development battles between the *nix weenies world and the WinDoze world. At a general level, the WinDoze world is not one that is use to and relies on text based editors configuration, they need the GUI. I even recourse getting a private message suggesting my customers must be stupid. Nonetheless, to reach critical mass, it is important the GUI is developed for this stuff. I can't rely on customers becoming text editor people if that is the only way to make this work. They only way I could even begin to offer DKIM, ADSP and even now ATPS is to provide a GUI, like this public version we have here for ADSP and ATPS http://www.winserver.com/public/wcadsp Just consider that ATPS has SHA1, BASE32 functions to produce the records. That adds complexity for any DNS server manager (Windows or Bind) to consider. Its just not a plug and play consideration. Its probably easier for the ISP Web-based managers since its more of an add-on to there current DNS software, using command line tools to act on GUI posted information. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 05/Mar/12 18:09, John Levine wrote: Sometimes an ASCII text record will be fine, in other cases, it probably won't. My point is as we move again towards multiple text representations of the digit five for example, both encoding and parsing is easier and more secure if that digit is really for example eight bits and not text that someone has to parse. Unless you provision your DNS zones with a hex debugger, the digit will always start out as text that someone has to parse. The question is who does the parsing, the DNS server or the application. As I said in a previous message, I can see plausible reasons to put the parser into the application. Would you really want to build an SPF or DKIM parser into every DNS server? That's a lot of code that the DNS manager doesn't care about, but the mail manager does. But it would be the same code, most likely by the same author(s). It may be generic for a kind of syntax or specific for a RR type, according to its author's convenience. On a system that allows new RR types without recompiling, the code would come as some sort of plugin in both cases. There are some false equivalences floating around here. I don't think anyone is suggesting that having provisioning systems or even DNS servers themselves check for syntax errors in the contents of complex records like DKIM, SPF, DMARC, or whatever is necessarily a bad idea. (Whether or not it will actually happen is another matter; I'm dubious.) Rather, the issue is with requiring it to happen in order to deploy a new RRTYPE of this sort, which is the result you get if the DNS server returns some series of tokens instead of the original text string. That's the sort of thing that forces people to upgrade, or search around for a script to do the conversion (which won't even occur to some), and that's an extra burden we don't need to impose. Why is it important what the DNS manager cares about? Speaking as a DNS manager myself, I care a lot about being forced to upgrade. Upgrades bring unwanted bugs in other areas. In fact I'm not entirely thrilled with the idea of plugins to do some extra syntax. More code means more possibilities of bugs. I'd actually prefer to see more cross-checking of existing stuff - less code and greater benefit. Parsers, including null parsers, would come with the same sub-package that enables the new RR type definition. Their complexity would only matter to the people who read/maintain their sources. I'm sorry, but you're being naive about this. Complexity does matter to the people who just use software because added complexity translates to more bugs. PS: For anyone who didn't read my previous message, I am NOT saying that it's fine to overload everything into TXT. I am saying that new RRTYPEs that are text blobs interpreted by client software wouldn't necessarily be bad. Agreed. That doesn't preclude syntax checking on loading the zone, though. As long as we stick with syntax checking I'm (mostly) OK with it. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Would you really want to build an SPF or DKIM parser into every DNS server? Here's another thought experiment. DKIM records are a sequence of tag=value fields. Let's imagine a binary version of DKIM records where each field is a length byte, a tag byte, and a suitably coded value. For the values that are currently strings, it's the string, for the values that are currently base64, it's the binary value. Since DNS TXT records are a sequence of binary strings each preceded by a length byte, we could just stuff this version of DKIM directly into a TXT record, with the first binary string being v=DKIM2. Would that be a good idea? DNS servers can serve the records without adding any new features, the records will be marginally faster to parse. Would that be a good idea? Why or why not? Assume we wave our hands and we have some way to create the records, hacks in provisioning systems, or a wizard web site into which you type your parameters and it gives you a TXT master file record full of hex escapes. Or wave them even more vigorously and assume the parser is built into some future version of BIND. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
I think we should look a bit on the flow of data. If I simplify we have a flow
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 ability
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 between
records in an RRSet is not in this triple. In some applications that is
resolved by having a prefix to the owner. In some other applications that is
resolved by parsing the RRSet.
We all do believe that IF it was easier to add a new RRType for each
application 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 add 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
provisioning and DNS packet format is.
Are we aligned so far?
Patrik
___
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
I think we should look a bit on the flow of data. If I simplify we have a
flow like this:
Looking at data flows is usually a good idea.
Input -P- DNS server -D- DNS stub -Q- Output
P is the provisioning
I think you want to break that into the provisioning interface and the data
format it produces that the DNS server consumes. (My reason for that is we have
a specification for at least such format, with all that implies.)
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
ability 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
between records in an RRSet is not in this triple. In some applications that
is resolved by having a prefix to the owner. In some other applications that
is resolved by parsing the RRSet.
We all do believe that IF it was easier to add a new RRType for each
application 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 add new RRTypes.
Yes, I think we have agreement on all of that.
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.
Problem is then in P and Q.
I personally don't see a big problem with Q, but others clearly do so
we need to leave it in.
And when we talk about parsing, we talk about what the mapping between
provisioning and DNS packet format is.
I think we need to be a little finer grained than that, per the above.
Are we aligned so far?
Yes, pretty much.
Ned
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Hey, if people don't like the restrictions of the TXT RR, have I got an answer for you! See http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02 A little out of data but gives you a wide variety of formats :-) Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sat, Mar 3, 2012 at 11:39 AM, Hector sant9...@gmail.com wrote: � wrote: On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote: Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. Agree with you but too many people today just program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself. The original version of Sender-ID (Caller ID Policy) was an XML version of SPF. In fact, the experimental record still exist: nslookup -query=txt _ep.hotmail.com ep xmlns='http://ms.net/1' testing='true' outmindirectlist1._ep.hotmail.com/indirect indirectlist2._ep.hotmail.com/indirect indirectlist3._ep.hotmail.com/indirect/m/out/ep It was introductions like this that raised eyebrows and the need to include a new RR type with the simpler language SPF TXT fallback for SPF and SENDER-ID. If TXT becomes the acceptable norm, than perhaps the XML format cane easily be reconsidered for a DNS TXT storage with a common XML I/O construct. :( -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 03/Mar/12 00:13, John R. Levine wrote: 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. was unusually painful, since it requires adding a parser for IPv6 addresses. (Having hacked it into my provisioning system, I speak from experience.) Most new RR types are just strings, numbers, names, and the occasional bit field. Yeah, and if ISPs already had troubles with ho-de-ho-de-ho-de-ho, how will they join in on skee-bop-de-google-eet-skee-bop-de-goat? Given that, designers of new RR types will want to stick to string formats just to spare ISPs some parsing, at the cost of losing a half of the advantages that RFC 5507 talks about, along with syntactic validations aimed at preventing some permerror/permfail cases. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 03/Mar/12 00:13, John R. Levine wrote: 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. was unusually painful, since it requires adding a parser for IPv6 addresses. (Having hacked it into my provisioning system, I speak from experience.) Most new RR types are just strings, numbers, names, and the occasional bit field. Yeah, and if ISPs already had troubles with ho-de-ho-de-ho-de-ho, how will they join in on skee-bop-de-google-eet-skee-bop-de-goat? Given that, designers of new RR types will want to stick to string formats just to spare ISPs some parsing, at the cost of losing a half of the advantages that RFC 5507 talks about, along with syntactic validations aimed at preventing some permerror/permfail cases. Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. More generally, this is trying to have things both ways. We can't simultaneously assert that deploying simple new RRs is a breeze, making this unnnecessary, and that it's so difficult that everything should be crammed into TXT Format no matter the actual structure is. NNed ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote: Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. Agree with you but too many people today just program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself. Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
ned+i...@mauve.mrochek.com wrote: Given that, designers of new RR types will want to stick to string formats just to spare ISPs some parsing, at the cost of losing a half of the advantages that RFC 5507 talks about, along with syntactic validations aimed at preventing some permerror/permfail cases. Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. More generally, this is trying to have things both ways. We can't simultaneously assert that deploying simple new RRs is a breeze, making this unnnecessary, and that it's so difficult that everything should be crammed into TXT Format no matter the actual structure is. Whats missing from all this is whether a TXT based protocol application can successfully pass all IETF/IESG and DNS community reveals, full endorsement and move to Internet Status. Sounds like isn't an issue any more with the aggressive push with protocols like DKIM and other TXT only proposed standard protocols. That was what I was trying to get out of all this. What is the new developer going to think when he invents the next DNS application? Which approach does he use for greater endorsement? -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On Saturday, March 03, 2012 05:05:08 PM Patrik Fältström wrote: On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote: Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. Agree with you but too many people today just program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself. There's a design trade off here that one should not over generalize about. Sometimes an ASCII text record will be fine, in other cases, it probably won't. Making the 'easy' case really easy so that new RRTypes get traction is a worthwhile goal. It certainly won't apply to all new RRTypes and so claims that it's not a universal solution don't mean it's not useful. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
� wrote: On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote: Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. Agree with you but too many people today just program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself. The original version of Sender-ID (Caller ID Policy) was an XML version of SPF. In fact, the experimental record still exist: nslookup -query=txt _ep.hotmail.com ep xmlns='http://ms.net/1' testing='true' outmindirectlist1._ep.hotmail.com/indirect indirectlist2._ep.hotmail.com/indirect indirectlist3._ep.hotmail.com/indirect/m/out/ep It was introductions like this that raised eyebrows and the need to include a new RR type with the simpler language SPF TXT fallback for SPF and SENDER-ID. If TXT becomes the acceptable norm, than perhaps the XML format cane easily be reconsidered for a DNS TXT storage with a common XML I/O construct. :( -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote: Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. Agree with you but too many people today just program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself. Regardless of the language you program in, you still have to get your proposal approved. For that to happen the folks who review these things would in effect be conceding that there is in fact a major deployment problem out there. That's the point I was trying to make, not that people wouldn't argue for this approach. I am unaware of any counterexamples that have actually made it through the process, but if they exist feel free to point them out. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
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. 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. 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. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 03/02/2012 09:00, John R. Levine wrote: 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. Assuming you're the only one with the True WisdomTM is almost always a bad idea. I stated earlier in the thread that I've done the kinds of provisioning systems you describe. And I'm not going to throw my resume at you, but I'm also intimately familiar with DNS at the large enterprise level. 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. I understand what you're saying, and I've seen this kind of institutional lethargy in action. My point is that just because this is a very common situation doesn't make it correct, or even defensible. We have a longstanding culture of DNS being a set-and-forget service. Us DNS weenies have been the worst offenders in enabling this bad behavior by trying to be backwards-backwards-backwards compatible with every new change. Those days are over. And just because properly updating your software can be difficult doesn't make it the wrong answer. 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. Yes, I get that bit too. 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. So it seems to me that what you're proposing would also cause the need for changes to be made to the provisioning systems. Or are you suggesting that the same users who cannot handle anything other than point and click are suddenly going to be able to enter specially formatted text strings that they don't understand? And/or that the people who operate those provisioning systems are going to allow end users to Add a new stanza to /etc/rrtypes? 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. The rest of this discussion is almost certainly more suitable for dnsop, but I'll say one more time that I disagree with you on this point. Provisioning systems *are* a bottleneck, no one is disputing that. But our experience with new TLDs, IPv6 and DNSSEC shows that when there is user demand for these changes, they get made. I'll also add one more point based on my experience with DNS provisioning system UI design, most of what you are trying to accomplish with your draft on the UI side can be handled with a simple text field in an HTML form that allows the user to enter free-form stuff that is then checked for syntax errors and loaded if the name server software supports the record. I realize that we disagree on right solution for the name server support side of the equation, but my point is that most of what you claim to be trying to achieve is already easily accomplished. Doug (emacs!?! vi or die, baby) -- If you're never wrong, you're not trying hard enough ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On Mar 2, 2012, at 10:09 AM, Doug Barton wrote: 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. So it seems to me that what you're proposing would also cause the need for changes to be made to the provisioning systems. Or are you suggesting that the same users who cannot handle anything other than point and click are suddenly going to be able to enter specially formatted text strings that they don't understand? Yes, that's exactly the point. If they can copy-and-paste from a tool that created the text string, this will be of huge benefit. And/or that the people who operate those provisioning systems are going to allow end users to Add a new stanza to /etc/rrtypes? No, that's not what is proposed. What is proposed is that if the operator has added the stanza, the user can add the RRtypes. 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. The rest of this discussion is almost certainly more suitable for dnsop, but I'll say one more time that I disagree with you on this point. Provisioning systems *are* a bottleneck, no one is disputing that. But our experience with new TLDs, IPv6 and DNSSEC shows that when there is user demand for these changes, they get made. The purpose of the proposal is to allow protocols with less press oomph than new TLDs, IPv6 and DNSSEC to be deployed. Maybe you don't want that, but many of us do. I'll also add one more point based on my experience with DNS provisioning system UI design, most of what you are trying to accomplish with your draft on the UI side can be handled with a simple text field in an HTML form that allows the user to enter free-form stuff that is then checked for syntax errors and loaded if the name server software supports the record. I realize that we disagree on right solution for the name server support side of the equation, but my point is that most of what you claim to be trying to achieve is already easily accomplished. Here, I agree with you more than I agree with John, but history has shown that HTML forms are not sufficient. I'm not sure why. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 03/02/2012 10:34, Paul Hoffman wrote: On Mar 2, 2012, at 10:09 AM, Doug Barton wrote: 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. So it seems to me that what you're proposing would also cause the need for changes to be made to the provisioning systems. Or are you suggesting that the same users who cannot handle anything other than point and click are suddenly going to be able to enter specially formatted text strings that they don't understand? Yes, that's exactly the point. If they can copy-and-paste from a tool that created the text string, this will be of huge benefit. So new tools still have to be created for new RRtypes, right? This sounds like an elephants all the way down situation to me. And/or that the people who operate those provisioning systems are going to allow end users to Add a new stanza to /etc/rrtypes? No, that's not what is proposed. What is proposed is that if the operator has added the stanza, the user can add the RRtypes. So less difficult than a full-fledged change to the provisioning system, but still requires operator intervention, and now you have operators *and* users with chances to make fatal errors. 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. The rest of this discussion is almost certainly more suitable for dnsop, but I'll say one more time that I disagree with you on this point. Provisioning systems *are* a bottleneck, no one is disputing that. But our experience with new TLDs, IPv6 and DNSSEC shows that when there is user demand for these changes, they get made. The purpose of the proposal is to allow protocols with less press oomph than new TLDs, IPv6 and DNSSEC to be deployed. Maybe you don't want that, but many of us do. Please don't use that kind of ad-hominem-adjacent line of argument with me. I'm already on record numerous times, including in this thread, saying that I believe the ability to deploy new RRtypes is crucial to the ongoing health of the Internet. I'll also add one more point based on my experience with DNS provisioning system UI design, most of what you are trying to accomplish with your draft on the UI side can be handled with a simple text field in an HTML form that allows the user to enter free-form stuff that is then checked for syntax errors and loaded if the name server software supports the record. I realize that we disagree on right solution for the name server support side of the equation, but my point is that most of what you claim to be trying to achieve is already easily accomplished. Here, I agree with you more than I agree with John, but history has shown that HTML forms are not sufficient. I'm not sure why. IME this has been because of the lack of a validation step in between user entry and (attempted) deployment. My (simplified) work flow for these kinds of systems has been: User input | Sanity checks based on internal policy | named-checkzone (or equivalent) | Deploy to name server | Validate that the new zone loaded correctly Skipping steps 2, 3, or 5 *will* cause tears, at some point. Doug -- If you're never wrong, you're not trying hard enough ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Skipping over all the parts I agree with, and noting that two decades of telling people to upgrade their DNS servers frequently hasn't worked, we get to ... I'll also add one more point based on my experience with DNS provisioning system UI design, most of what you are trying to accomplish with your draft on the UI side can be handled with a simple text field in an HTML form that allows the user to enter free-form stuff that is then checked for syntax errors Checked for syntax errors? By what? The whole point of the extension language is to describe the syntax of new RRs as data that provisioning software and nams servers can read at runtime, so you don't have to patch your software for every new RR. It also can be translated into an HTML form for the RR that the user can fill in, the provisioning software can syntax check by field, so you don't have to build an entire BIND master file parser into your PHP web scripts. And, of course, your DNS server uses the same data to parse new RRs without being patched. 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
Re: provisioning software, was DNS RRTYPEs, the difficulty with
I've rarely read a message on this list that I agreed with more. +1000 to everything said below. Ned 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. 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 03/02/2012 10:48, John R. Levine wrote: Skipping over all the parts I agree with, and noting that two decades of telling people to upgrade their DNS servers frequently hasn't worked, we get to ... I'll also add one more point based on my experience with DNS provisioning system UI design, most of what you are trying to accomplish with your draft on the UI side can be handled with a simple text field in an HTML form that allows the user to enter free-form stuff that is then checked for syntax errors Checked for syntax errors? By what? Didn't you answer your own question further down in your own post? :) But seriously folks, I really do understand what you're saying, but my experience as both a DNS protocol weenie and as a designer/builder of provisioning systems designed for non-DNS-protocol-weenie end users tells me that your proposed solution is not likely to work in the (IMO overly optimistic) manner in which you describe, and even if it did it's the wrong solution to the problem. If you want to discuss it further, dnsop is probably where that discussion should take place, I've already repeated myself enough times here. Doug -- If you're never wrong, you're not trying hard enough ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203020941360.37...@joyce.lan, 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: provisioning software, was DNS RRTYPEs, the difficulty with
Well for BIND it's add a new file that defines the type's methods and recompile. That isn't a whole new version. Recompile - new version. These days, most server systems are built from precompiled packages. Check your local Linux box for an example. 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. Well, yes. Wouldn't it be nice to have provisioning systems that could be configured to support the RR types you want to use? If so, you might want to look at my draft. 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. was unusually painful, since it requires adding a parser for IPv6 addresses. (Having hacked it into my provisioning system, I speak from experience.) Most new RR types are just strings, numbers, names, and the occasional bit field. 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
