ietf
[Top] [All Lists]

Re: [IETF] Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)

2013-05-03 19:51:38

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