26 Kvě
2016
26 Kvě
'16
19:20
Hello,
On 26/05/2016 13:29, Jan Včelak wrote:
This is due to the
use of different daemons and configs. As far as i
know bind, nsd and knot all act differently in the way they handle glue
in the additional section. (although i haven't tested bind that much)
clients?
l root still sees a lot of queries without EDNS
http://stats.dns.icann.org/plotcache/L-root/edns_version/2016-05-25T00:00-2…
This seems reasonable to me
Hello.
> However, if Knot is able to fit in at least one glue record into the
> delegation response, then it doesn't make sense to set TC. That's
> because the client can contact the glue address provided to discover the
> missing A/AAAA records. A client needs to do this anyway, because the
> glue records from the parent are not authoritative.
Its worth mentioning this
is how NSD works. Im not sure which behavior
i prefer.
This raises many questions:
- How will the requester differentiate whether the provided glue is
complete or not?
The authority section would still contain the full nsset so the
cache
would know if it did not have A/AAAA records for all records in the NS set
- What if only the first A glue record fits the zone
and the requester
is IPv6 only?
knot could try to include one AAAA record fi one exists, if not it
should add the single A record (the client may be dual stacked so may be
able to use the A record)
- What if only the first glue server fits but the
server is unreachable
from requester?
This is the down side to the way NSD operates the downside to
knot is
the potential increased TCP load.
- Are all the slave servers equal? Or should we prefer
the first one?
all equal IMO
I prefer giving the requester a complete information
about the glue.
Otherwise the query resolution logic gets complicated both on the
authoritative and resolver part.
I notice that the behavior for an in zone nsset is
different and glue is
added depending on the EDNS size.
e.g.
dig +dnssec ns example.com. @5.28.63.78 +bufsize=1680
dig +dnssec ns example.com. @5.28.63.78 +bufsize=1780
vs
dig +tcp +dnssec ns example.com. @5.28.63.78
I have also noticed inconsistencies in relation to when RRSIGs get added
to the additional section.
When running the following query i get inconsistent results
dig +dnssec ns nic.cz @194.0.12.1 +bufsize=600
This normally provides the following answer which seems to follow the
logic of add all the glue records then add the RRSIG's if they fit
-------------------------------------------------------------------
; <<>> DiG 9.10.3-P4 <<>> +dnssec ns nic.cz @194.0.12.1
+bufsize=615 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40303
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 8
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; NSID: 64 6e 73 2d 73 2d 30 31 2e 6e 69 63 2e 63 7a ("dns-s-01.nic.cz")
;; QUESTION SECTION:
;nic.cz. IN NS
;; ANSWER SECTION:
nic.cz. 1800 IN NS a.ns.nic.cz.
nic.cz. 1800 IN NS b.ns.nic.cz.
nic.cz. 1800 IN NS d.ns.nic.cz.
nic.cz. 1800 IN RRSIG NS 5 2 1800 20160608070658 20160525085002 37152
nic.cz. A5JPuZTPiZyY6QTz9k3DaS6kigPZf+3Exnchr1gQbu0dY4WwwrdbKGST
R9oT4dpPnq59kfPVehdDjFJJns9vUFOmQrh6SIB8oF3bS+GJwLttZU/z
gIe35hMLA6eDAYs5oUnFt4XTRf8W3E/0kJpaoGUdqQphapRaxrMzBdiC 2nw=
;; ADDITIONAL SECTION:
a.ns.nic.cz. 1800 IN A 194.0.12.1
a.ns.nic.cz. 1800 IN AAAA 2001:678:f::1
b.ns.nic.cz. 1800 IN A 194.0.13.1
b.ns.nic.cz. 1800 IN AAAA 2001:678:10::1
d.ns.nic.cz. 1800 IN A 193.29.206.1
d.ns.nic.cz. 1800 IN AAAA 2001:678:1::1
a.ns.nic.cz. 1800 IN RRSIG A 5 4 1800 20160607203614 20160525085002
37152 nic.cz. PXqbWak0/qU6g/P7Vm/XGjuwxTL8XiWLnlrTG5Z/g5XJhpknN/49MTtN
SeQ5LxryZojrvzyiKrauPFz6WWZmID8RUgRr95nC7pmZauilRAUVyRXR
q5tgvRKRIpoxp9hw+db/36HvZPr4CVSzscufEdVRiO8jliLfinIJu7r3 WZs=
;; Query time: 45 msec
;; SERVER: 194.0.12.1#53(194.0.12.1)
;; WHEN: Thu May 26 15:56:26 BST 2016
;; MSG SIZE rcvd: 569
-------------------------------------------------------------------
however i occasionally get the following (from dns-r-01.nic.cz) which
suggests that if you add a glue record then also its rrsig. if there is
more room add another glue record and its rrsig. swapping between a
bufsize of 617 and 615 suggests that glue will only be added if the
RRSIG also fits
-------------------------------------------------------------------
; <<>> DiG 9.10.3-P4 <<>> +dnssec ns nic.cz @194.0.12.1
+bufsize=615 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54745
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; NSID: 64 6e 73 2d 72 2d 30 31 2e 6e 69 63 2e 63 7a ("dns-r-01.nic.cz")
;; QUESTION SECTION:
;nic.cz. IN NS
;; ANSWER SECTION:
nic.cz. 1800 IN NS a.ns.nic.cz.
nic.cz. 1800 IN NS b.ns.nic.cz.
nic.cz. 1800 IN NS d.ns.nic.cz.
nic.cz. 1800 IN RRSIG NS 5 2 1800 20160608070658 20160525085002 37152
nic.cz. A5JPuZTPiZyY6QTz9k3DaS6kigPZf+3Exnchr1gQbu0dY4WwwrdbKGST
R9oT4dpPnq59kfPVehdDjFJJns9vUFOmQrh6SIB8oF3bS+GJwLttZU/z
gIe35hMLA6eDAYs5oUnFt4XTRf8W3E/0kJpaoGUdqQphapRaxrMzBdiC 2nw=
;; ADDITIONAL SECTION:
a.ns.nic.cz. 1800 IN A 194.0.12.1
a.ns.nic.cz. 1800 IN RRSIG A 5 4 1800 20160607203614 20160525085002
37152 nic.cz. PXqbWak0/qU6g/P7Vm/XGjuwxTL8XiWLnlrTG5Z/g5XJhpknN/49MTtN
SeQ5LxryZojrvzyiKrauPFz6WWZmID8RUgRr95nC7pmZauilRAUVyRXR
q5tgvRKRIpoxp9hw+db/36HvZPr4CVSzscufEdVRiO8jliLfinIJu7r3 WZs=
;; Query time: 41 msec
;; SERVER: 194.0.12.1#53(194.0.12.1)
;; WHEN: Thu May 26 15:56:26 BST 2016
;; MSG SIZE rcvd: 453
-------------------------------------------------------------------
again im not sure which behavior i prefer but seems related to this thread
Now, with Knot setting TC in a delegation
response, it has the potential
to cause clients make one more query to the parent server, and this
query, in my opinion, isn't necessary.
It seems that root servers are inconsistent as for the TC setting and
glue. The A root and J root are setting the TC flag as we do:
for server in {a..m}.root-servers.net; do
echo $server
kdig +notcp +dnssec +bufsize=512 @"$server" www.com | grep "^;;
Flags";
done
A much more interesting case is mn.
for server in {a..m}.root-servers.net;
do
echo $server;
kdig +notcp +dnssec +bufsize=512 @"$server" ns mn ;
done
This produces a referral with no glue from all servers accept A and J.
It would
I wonder if it's desired. The glue for .com
belongs to .net, so this
probably should not cause a truncation. (It would case TC with Knot
2.2.1 as well.)
however both net is still a child of . so i think the server
should
still try to send at least one glue record.
Having said
this though, this is all a problem only for clients that
aren't using ENDS, or using EDNS with a small buffer (such as when BIND
falls back to small buffers to get around firewalls, for example).
Anand, do you have any estimation, what is the proportion of these 
I can see CZNIC's point of view in making
this change to set TC always,
but I'm not yet convinced that this is a good idea.
I understand this. And we can always change it again for everyone's
satisfaction.
So what about the following: We will set TC in the response if complete
mandatory glue doesn't fit the response. Mandatory glue means that the
name servers reside within or bellow the delegated zone. Otherwise, we
will treat the glue records as optional.