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