In message <86172038-8F62-4508-8199-BE4C16906A65@xxxxxxxxxx>, Warren Kumari writes:
>
> 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
Did you see the bounce that came back from hostmaster@xxxxxxxxxxxxx?
You follow the link in that email and there is no where to report
the problem. None of the options offered was really sensible though
I did open a chat window and report the problem. I doubt it will
have much effect.
Whois doesn't help. Same bouncing email address or one needs to
make a international phone call to report the problem.
And no it still doesn't work, below, from where I am in the world
not that ietf@ is the right place to diagnose this specific issue.
Earthlink.net isn't the only zone, it is just a example.
The ones in a position to make a difference are the registries and
registrars. They can test the nameservers when they are registered
and annually there after. They can also remove the delegation if
a detected problem is not fixed in a timely manner.
One shouldn't be allowed to register a non compliant nameserver,
where not responding to arbitary query types is a form of non
compliance. Similar non compliance is returning a SOA record other
that that for the delegated zone in a negative answer.
These are the two errors that most impact on the ability to deploy
new types. They are also things that are not usually checked for.
Yes this is a attempt to clean up the commons.
Mark
[drugs:~/git/bind9] marka% dig soa earthlink.net @scratchy.earthlink.net
; <<>> DiG 9.9.3-S1rc2 <<>> soa earthlink.net @scratchy.earthlink.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39882
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;earthlink.net. IN SOA
;; ANSWER SECTION:
earthlink.net. 1800 IN SOA itchy.earthlink.net. hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800
;; AUTHORITY SECTION:
earthlink.net. 1800 IN NS itchy.earthlink.net.
earthlink.net. 1800 IN NS scratchy.earthlink.net.
;; ADDITIONAL SECTION:
itchy.earthlink.net. 1800 IN A 207.69.188.196
scratchy.earthlink.net. 1800 IN A 207.69.188.197
;; Query time: 241 msec
;; SERVER: 207.69.188.197#53(207.69.188.197)
;; WHEN: Sat May 04 09:49:15 EST 2013
;; MSG SIZE rcvd: 164
[drugs:~/git/bind9] marka% dig hinfo earthlink.net @scratchy.earthlink.net
; <<>> DiG 9.9.3-S1rc2 <<>> hinfo earthlink.net @scratchy.earthlink.net
;; global options: +cmd
;; connection timed out; no servers could be reached
[drugs:~/git/bind9] marka% traceroute scratchy.earthlink.net
traceroute to scratchy.earthlink.net (207.69.188.197), 64 hops max, 52 byte packets
1 192.168.191.233 (192.168.191.233) 1.498 ms 1.435 ms 1.139 ms
2 10.72.0.1 (10.72.0.1) 30.066 ms 18.106 ms 19.995 ms
3 bla2-ge0-0-1.gw.optusnet.com.au (198.142.160.185) 26.258 ms 26.529 ms 21.209 ms
4 * * *
5 bla5-ge13-0.gw.optusnet.com.au (211.29.125.249) 27.672 ms 34.851 ms 38.224 ms
6 203.208.131.57 (203.208.131.57) 181.029 ms 161.411 ms 181.544 ms
7 las-b3-link.telia.net (80.239.167.189) 163.015 ms 177.855 ms 189.488 ms
8 las-bb1-link.telia.net (213.155.131.84) 179.306 ms 179.604 ms
las-bb1-link.telia.net (213.155.134.252) 226.815 ms
9 ae8.edge1.losangeles.level3.net (4.68.70.129) 169.711 ms 171.338 ms 174.650 ms
10 vlan90.csw4.losangeles1.level3.net (4.69.144.254) 234.904 ms
vlan60.csw1.losangeles1.level3.net (4.69.144.62) 246.798 ms 228.503 ms
11 ae-62-62.ebr2.losangeles1.level3.net (4.69.137.17) 227.185 ms
ae-82-82.ebr2.losangeles1.level3.net (4.69.137.25) 237.125 ms 229.297 ms
12 ae-3-3.ebr3.dallas1.level3.net (4.69.132.78) 242.771 ms 244.128 ms 231.012 ms
13 ae-7-7.ebr3.atlanta2.level3.net (4.69.134.22) 311.533 ms 230.136 ms 235.348 ms
14 ae-63-63.ebr1.atlanta2.level3.net (4.69.148.242) 225.662 ms
ae-73-73.ebr2.atlanta2.level3.net (4.69.148.254) 273.549 ms
ae-63-63.ebr1.atlanta2.level3.net (4.69.148.242) 239.239 ms
15 ae-26-52.car2.atlanta2.level3.net (4.69.150.70) 242.421 ms
ae-16-51.car2.atlanta2.level3.net (4.69.150.6) 237.273 ms
ae-26-52.car2.atlanta2.level3.net (4.69.150.70) 238.109 ms
16 earthlink-i.car2.atlanta2.level3.net (4.71.254.14) 251.459 ms 335.603 ms 239.819 ms
17 cor01-vl-10.ga-atlanta0.ne.earthlink.net (207.69.223.158) 240.427 ms 270.848 ms 228.444 ms
18 * * *
19 * * *
20 * * *
21 * * *
^C
[drugs:~/git/bind9] marka%
> > 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
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx