On May 2, 2013, at 9:56 PM, Mark Andrews <marka@xxxxxxx> wrote:
>
> In message <5182828C.3040200@xxxxxxxx>, Hector Santos writes:
>> Mr. Resnick, for the record, I wasn't upset. Believe it or not, I was
>> actually applying an suggestion posted last month or so here with the
>> IETF diversity talks to help get a major WG issue resolved, one with a
>> near surety of an appeal, resolved and addressed much faster and hence
>> avoid a waste of time on the behalf of all.
>>
>> How appropo, that a topic of "balancing of process" as being considered.
>> It is one thing I believe the IETF needs and can be actually apply
>> today. Yes, I don't agree with the negative tone taken in SPFBIS where
>> in effect, an attempt to shut down communications and indirectly
>> personally attack posters occurred and the advocates of the SPF RRTYPE
>> removal (incidentally, a SPEC change which I believe was prohibited by
>> the charter), basically blowing off advocates of a RFC4408 status quo.
>> If you believe that was proper, I think we have a WG problem.
>>
>> Overall, I believe this (keep the migration path) is the proper
>> compromise to resolve the issue, and I believe that this particular
>> issue is industry-wide important to resolve with across the board
>> engineering input. It *SHOULD NOT* be reserved only to the applications
>> SPFBIS group especially when we know what the DNS community will say
>> about this and has said so since MARID 2003 and again last year in IETF
>> and DNSOPs. I was simply hoping to help "Balance the process" then as I
>> was attempted to do again. If I was in error for trying to get a
>> serious issue resolve, then please accept my apology.
>>
>> Sincerely,
>>
>> Hector Santos
>
> One of the questions is how to deal with vendors that claim to ship
> a product which is in compliance with the protcol when they are
> not.
>
> The DNS protocol has a error code for when you do not understand a
> query, FORMERR. It also has a error code for when you do not
> implement part of the protocol, NOTIMP.
>
> With RFC 103[45] you have three choices as a developer when you get
> a query type you don't know about.
>
> 1. Treat it as a FORMERR.
> 2. Treat it as a NOTIMP.
> 3. Treat it as a opaque data.
>
> Now in my book it isn't a FORMERR as you can understand the question
> even if you can't deal with it. NOTIMP is a reasonable response
> though I believe the intent in RFC 103[45] was to treat it as opaque
> data query which is what RFC 3597 says to do.
>
> Nowhere in RFC 103[45] does it say DO NOT RESPOND to the query yet
> we have DNS vendors that ship products that do just that and are
> claiming that they conform to the protocol.
>
> For a example of a set of servers that does this see earthlink.net's
> servers.
>
> Query for HINFO/earthlink.net at the authoritative servers for
> earthlink.net (itchy.earthlink.net and scratchy.earthlink.net) and
> you will not get a response. A RFC 103[45] compliant server should
> know about HINFO. It should also be capable of returning a NOERROR
> NODATA response for that query and it fact will if you ask for a
> non-existent TXT record at a name it serves.
>
> How do we deal with sites?
> How do we deal with vendors that ship such product?
Unless the caffeine just hasn't sunk in yet, it works for me:
wmbt-macbookair:Preferences wkumari$ dig HINFO earthlink.net @scratchy.earthlink.net
; <<>> DiG 9.8.3-P1 <<>> HINFO earthlink.net @scratchy.earthlink.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1906
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;earthlink.net. IN HINFO
;; AUTHORITY SECTION:
earthlink.net. 1800 IN SOA itchy.earthlink.net. hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800
;; Query time: 51 msec
;; SERVER: 207.69.188.197#53(207.69.188.197)
;; WHEN: Fri May 3 12:59:50 2013
;; MSG SIZE rcvd: 84
So, maybe the way you fix such sites / deal with vendors that ship such products is you post to ietf@xxxxxxxx and cc hostmaster@site?
:-P
W
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
>
--
Hope is not a strategy.
-- Ben Treynor, Google