Comcast residential DNS contact
marka at isc.org
Thu Dec 4 00:11:33 UTC 2014
DNS Cookies / SIT (DNS Cookies w/o the error code) will also deal
with forged traffic. It allows you to identify traffic from a
client that you have replied to in the past and to which you can
safely send a large response. It lets you sort the wheat from the
SIT is available in BIND 9.10 (configure --enable-sit) and uses a
experiment EDNS OPT code. BIND 9.11 will have DNS Cookies / SIT
will on by default with a allocated code point.
The only thing is the amount of non EDNS compliance with servers
will make this hard to deploy. In theory unknown EDNS options are
supposed to be IGNORED (See RFC6891, 6.1.2 Wire Format). This was
done to allow you to send a EDNS option without knowing if the other
end supported that option safely.
Unfortunately there are firewalls that block such queries. There
are nameserver implementations that return FORMERR when they see
such queries. There are nameserver implementations that return
BADVER when they see such queries. There are nameserver implemations
that echo back the option. There are also implementations that
don't return a EDNS response unless DO=1 is set.
If your nameserver / firewall combination fails to properly handle
EDNS queries with unknown options can you please fix it.
You can test EDNS option handling with the following allocated code
dig +nsid soa $zone @$server
dig +expire soa $zone @$server
Experimentatal code point (requires BIND 9.10).
dig +sit soa $zone @$server
Unallocated code point (requires pre BIND 9.11 code from sources.isc.org).
dig +ednsopt=100 soa $zone @$server
There are also issues with attempting to use a new EDNS version
(this should get BADVERS returned) or setting a new EDNS flag bit
(supposed to be ignored). Firewalls also stupidly block these even
more so than unknown EDNS options.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG