In message <CAHw9_iKOygzP0Q3=n6p7sr0zkqrdvhc0s7sebp308qdysfo...@mail.gmail.com>
, Warren Kumari writes:
> On Wed, Aug 6, 2014 at 6:24 PM, Mark Andrews <ma...@isc.org> wrote:
> >
> > The important thing to learn here is: Complain when you see a server
> > doing something wrong.
>
> +1.
>
> Otherwise it is entirely possible that the server operator /
> implementor simply doesn't know that they sending incorrect responses.
>
> The RFCs are sometimes, um, subtle...
>
> W
I just logged fault reports with the technical contact for every
tld that has a server that responds incorrectly to EDNS(1) queries
if they handle EDNS(0) queries. BADVERS should be the result if
they the support EDNS as EDNS(1) is not yet defined.
dig +edns=1 zone @host
I've had one contact acknowledge the report and say they have logged
a report upstream. This doesn't mean that the others won't be acted
on.
If we had consistent whois formats I would do the same for the Alexa top 1M.
For the tld's I only had to deal with one whois output.
The next round will be for those that don't correctly handle unknown
EDNS options. Unknown options should be ignored.
dig +ednsopt=100 zone @host
(requires BIND 9.11 - no reponse / a different error code /
echoed back indicates a error)
dig +sit zone @host
(requires BIND 9.10 and configure --enable-sit.
no response / a different error code / a short sit response
without the server tag which just echo back the client tag
indicates a bug.
- with server tag:
SIT: 26a669a68f2096beeb403f6153e56265211ffe35604a8aa1 (good)
- without server tag:
SIT: 26a669a68f2096beeb403f61 (good)
)
dig +expire zone @host
(requires BIND 9.10 - no reponse / a different error code /
echoed back indicates a error - a valid expire response
will have a 32 bit counter returned
e.g.
; EXPIRE: 2365198 (3 weeks 6 days 8 hours 59 minutes 58 seconds)
vs
; EXPIRE
)
dig +nsid zone @host
(no response / a different error code / echoed back indicates
a bug)
Mark
> > Mark
> >
> > In message <alpine.lsu.2.00.1408061719140.23...@hermes-1.csi.cam.ac.uk>, To
> ny F
> > inch writes:
> >> Tony Finch <d...@dotat.at> wrote:
> >> > Mark Andrews <ma...@isc.org> wrote:
> >> > >
> >> > > The TCP response is limited to the EDNS UDP buffer size resulting
> >> > > in silent truncation of results (no tc=1). This results in DNSSEC
> >> > > validation failures.
> >>
> >> This has changed to a different bug. Now TC is set, but the EDNS OPT
> >> record is still brokenly missing. (example below)
> >>
> >> > The sixth and seventh bugs are in IronDNS. If you send a DNSSEC query
> >> > with a too-small buffer size it replies with a minimal truncated reply
> >> > with no OPT record. If you send a non-DNSSEC query with a tiny buffer
> >> > size it replies with FORMERR containing an OPT record. (RFC 6891 says
> >> > you should treat tiny buffers the same as 512.)
> >>
> >> These bugs are now fixed. Thanks to the IronDNS staff for their helpful
> >> response.
> >>
> >> Mark has also adjusted BIND's EDNS handling to be more tolerant of these
> >> bad servers, though with the fixes from authority servers it is not so
> >> easy to test now :-)
> >>
> >>
> >> ; <<>> DiG 9.11.0pre-alpha <<>> +norec +dnssec +qr +bufsize=512 +ignore dn
> ske
> >> y soy. @ns-tld3.charlestonroadregistry.com.
> >> ;; global options: +cmd
> >> ;; Sending:
> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38835
> >> ;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >>
> >> ;; OPT PSEUDOSECTION:
> >> ; EDNS: version: 0, flags: do; udp: 512
> >> ;; QUESTION SECTION:
> >> ;soy. IN DNSKEY
> >>
> >> ;; QUERY SIZE: 32
> >>
> >> ;; Got answer:
> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38835
> >> ;; flags: qr aa tc; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> >>
> >> ;; QUESTION SECTION:
> >> ;soy. IN DNSKEY
> >>
> >> ;; ANSWER SECTION:
> >> soy. 86400 IN DNSKEY 256 3 8 AwEAAdjqNieDCzVc23
> se2
> >> bdg6iJstpAFaGyXERjWXT27dxlmAP8zObs0 a7qQK1JJxx7v8ote3JtmuKgaPCGDjKumCdVynI
> +Ys
> >> c1Nqxm/aDz1pe6c ykBr7taVhtbedoXczEFu0PWknZWN3TIrL6RCi75bqLGmzn8FHH7asXQJ w
> TQv
> >> gqWb
> >> soy. 86400 IN DNSKEY 257 3 8 AwEAAcWe+Yfs8YAAt8
> w1J
> >> aRXkN18rc9nlBMyLaDP0hhXcGZjjBSZk6Lj QB3mz68fCoL6NHWOztlrJFyOP4yiK+d2UHOC+G
> ALg
> >> vbStv5T44jBelh9 Hz70ja5t54ycpqduAUPzgMrixFKdxu3vnoU3HiqoebUPQfxTD62xDDW9 N
> Src
> >> oBZGG4vE6Ksma3ntwR9/dqE/sFmNvSM8hXRCsh1/ZuKw4noKluGq vvHPyLYVmVnXU7/vprD0d
> g6u
> >> i3uwkKmWPIC0DvPCDQ0697CXckuFSJWY 5vJKWG8plZkVJ+tiJpfNTNZF9WhIUQg6Au8lqWX+N
> wmP
> >> HTwZLw5P72gW o5JkoLHuLoU=
> >>
> >> ;; Query time: 12 msec
> >> ;; SERVER: 2001:4860:4802:36::69#53(2001:4860:4802:36::69)
> >> ;; WHEN: Wed Aug 06 17:20:13 BST 2014
> >> ;; MSG SIZE rcvd: 445
> >>
> >>
> >> Tony.
> >> --
> >> f.anthony.n.finch <d...@dotat.at> http://dotat.at/
> >> Dover, Wight, Portland, Plymouth, Biscay: Southwesterly 4 or 5, occasional
> ly
> >> 6
> >> at first, veering northwesterly 4. Slight or moderate. Occasional rain or
> >> showers. Moderate or good.
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
