In message <86172038-8F62-4508-8199-BE4C16906A65(_at_)kumari(_dot_)net>, Warren
Kumari writes:
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
Did you see the bounce that came back from hostmaster(_at_)earthlink(_dot_)net?
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(_at_)isc(_dot_)org
--
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(_at_)isc(_dot_)org