I want to send larger responses (more glue)

I manage a DNS Yeti <http://yeti-dns.org/&gt; root name server and, for
experimental purposes, we now have 23 root name servers. But NSD does
not send the glue for all of them:

% dig @dahu1.yeti.eu.org NS .

; <<>> DiG 9.9.5-12.1-Debian <<>> @dahu1.yeti.eu.org NS .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 368
;; flags: qr aa rd; QUERY: 1, ANSWER: 24, AUTHORITY: 0, ADDITIONAL: 12
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 86400 IN NS bii.dns-lab.net.
. 86400 IN NS yeti.bofh.priv.at.
. 86400 IN NS yeti.ipv6.ernet.in.
. 86400 IN NS yeti.aquaray.com.
. 86400 IN NS dahu1.yeti.eu.org.
. 86400 IN NS dahu2.yeti.eu.org.
. 86400 IN NS ns-yeti.bondis.org.
. 86400 IN NS yeti-ns.ix.ru.
. 86400 IN NS yeti-ns.lab.nic.cl.
. 86400 IN NS yeti-ns.tisf.net.
. 86400 IN NS yeti-ns.wide.ad.jp.
. 86400 IN NS yeti-ns.conit.co.
. 86400 IN NS yeti-ns.switch.ch.
. 86400 IN NS yeti-ns.as59715.net.
. 86400 IN NS yeti-ns1.dns-lab.net.
. 86400 IN NS yeti-ns2.dns-lab.net.
. 86400 IN NS yeti-ns3.dns-lab.net.
. 86400 IN NS yeti-dns01.dnsworkshop.org.
. 86400 IN NS 18ac3e7343f016890c510e93f93526.yeti-dns.net.
. 86400 IN NS 2e7d2c03a9507ae265ecf5b5356885.yeti-dns.net.
. 86400 IN NS 3e23e8160039594a33894f6564e1b1.yeti-dns.net.
. 86400 IN NS 3f79bb7b435b05321651daefd374cd.yeti-dns.net.
. 86400 IN NS ca978112ca1bbdcafac231b39a23dc.yeti-dns.net.
. 86400 IN RRSIG NS 8 0 86400 (
        20160603050150 20160504050150 20454 .
        oXf6MeGVkVFcWu7iUdfx06LuD6CPGSpzJDpPc38hactA
        3fm9oIQ7K2vySs4V+xd4FXEwLML2jq0LlvZ9/bt8hDJM
        jXvF/6wszHu7i900Rtf+CpGt7cYe/yCuEVTJwNogpsyU
        v0xFs4LlpfVWYouMKG5uOUBu4qHOiR4R2ibqmZw= )

;; ADDITIONAL SECTION:
bii.dns-lab.net. 86400 IN AAAA 240c:f:1:22::6
yeti.bofh.priv.at. 86400 IN AAAA 2a01:4f8:161:6106:1::10
yeti.ipv6.ernet.in. 86400 IN AAAA 2001:e30:1c1e:1::333
yeti.aquaray.com. 86400 IN AAAA 2a02:ec0:200::1
dahu1.yeti.eu.org. 86400 IN AAAA 2001:4b98:dc2:45:216:3eff:fe4b:8c5b
dahu2.yeti.eu.org. 86400 IN AAAA 2001:67c:217c:6::2
ns-yeti.bondis.org. 86400 IN AAAA 2a02:2810:0:405::250
yeti-ns.ix.ru. 86400 IN AAAA 2001:6d0:6d06::53
yeti-ns.lab.nic.cl. 86400 IN AAAA 2001:1398:1:21::8001
yeti-ns.tisf.net. 86400 IN AAAA 2001:559:8000::6
yeti-ns.wide.ad.jp. 86400 IN AAAA 2001:200:1d9::35

;; Query time: 22 msec
;; SERVER: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b#53(2001:4b98:dc2:45:216:3eff:fe4b:8c5b)
;; WHEN: Wed May 04 10:24:16 CEST 2016
;; MSG SIZE rcvd: 1222

The EDNS buffer size of the server is 4096 bytes:

% grep ipv6-edns /etc/nsd/nsd.conf
        ipv6-edns-size: 4096

How could I tell it to send all the glues when the EDNS buffer size is
large enough? I do not find such an option in the documentation.

NSD 4.1.9, running on Linux

Hi Stephane,

I manage a DNS Yeti <http://yeti-dns.org/&gt; root name server and,
for experimental purposes, we now have 23 root name servers. But
NSD does not send the glue for all of them:

% dig @dahu1.yeti.eu.org NS .

; <<>> DiG 9.9.5-12.1-Debian <<>> @dahu1.yeti.eu.org NS . ; (1
server found) ;; global options: +cmd ;; Got answer: ;;
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 368 ;; flags: qr
aa rd; QUERY: 1, ANSWER: 24, AUTHORITY: 0, ADDITIONAL: 12 ;;
WARNING: recursion requested but not available

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;;
QUESTION SECTION: ;. IN NS

;; ANSWER SECTION: . 86400 IN NS bii.dns-lab.net. . 86400 IN NS
yeti.bofh.priv.at. . 86400 IN NS yeti.ipv6.ernet.in. . 86400 IN
NS yeti.aquaray.com. . 86400 IN NS dahu1.yeti.eu.org. . 86400
IN NS dahu2.yeti.eu.org. . 86400 IN NS ns-yeti.bondis.org. .
86400 IN NS yeti-ns.ix.ru. . 86400 IN NS yeti-ns.lab.nic.cl. .
86400 IN NS yeti-ns.tisf.net. . 86400 IN NS yeti-ns.wide.ad.jp. .
86400 IN NS yeti-ns.conit.co. . 86400 IN NS yeti-ns.switch.ch. .
86400 IN NS yeti-ns.as59715.net. . 86400 IN NS
yeti-ns1.dns-lab.net. . 86400 IN NS yeti-ns2.dns-lab.net. .
86400 IN NS yeti-ns3.dns-lab.net. . 86400 IN NS
yeti-dns01.dnsworkshop.org. . 86400 IN NS
18ac3e7343f016890c510e93f93526.yeti-dns.net. . 86400 IN NS
2e7d2c03a9507ae265ecf5b5356885.yeti-dns.net. . 86400 IN NS
3e23e8160039594a33894f6564e1b1.yeti-dns.net. . 86400 IN NS
3f79bb7b435b05321651daefd374cd.yeti-dns.net. . 86400 IN NS
ca978112ca1bbdcafac231b39a23dc.yeti-dns.net. . 86400 IN RRSIG NS
8 0 86400 ( 20160603050150 20160504050150 20454 .
oXf6MeGVkVFcWu7iUdfx06LuD6CPGSpzJDpPc38hactA
3fm9oIQ7K2vySs4V+xd4FXEwLML2jq0LlvZ9/bt8hDJM
jXvF/6wszHu7i900Rtf+CpGt7cYe/yCuEVTJwNogpsyU
v0xFs4LlpfVWYouMKG5uOUBu4qHOiR4R2ibqmZw= )

;; ADDITIONAL SECTION: bii.dns-lab.net. 86400 IN AAAA
240c:f:1:22::6 yeti.bofh.priv.at. 86400 IN AAAA
2a01:4f8:161:6106:1::10 yeti.ipv6.ernet.in. 86400 IN AAAA
2001:e30:1c1e:1::333 yeti.aquaray.com. 86400 IN AAAA
2a02:ec0:200::1 dahu1.yeti.eu.org. 86400 IN AAAA
2001:4b98:dc2:45:216:3eff:fe4b:8c5b dahu2.yeti.eu.org. 86400 IN
AAAA 2001:67c:217c:6::2 ns-yeti.bondis.org. 86400 IN AAAA
2a02:2810:0:405::250 yeti-ns.ix.ru. 86400 IN AAAA
2001:6d0:6d06::53 yeti-ns.lab.nic.cl. 86400 IN AAAA
2001:1398:1:21::8001 yeti-ns.tisf.net. 86400 IN AAAA
2001:559:8000::6 yeti-ns.wide.ad.jp. 86400 IN AAAA
2001:200:1d9::35

;; Query time: 22 msec ;; SERVER:
2001:4b98:dc2:45:216:3eff:fe4b:8c5b#53(2001:4b98:dc2:45:216:3eff:fe4b:

8c5b)

;; WHEN: Wed May 04 10:24:16 CEST 2016

;; MSG SIZE rcvd: 1222

The EDNS buffer size of the server is 4096 bytes:

% grep ipv6-edns /etc/nsd/nsd.conf ipv6-edns-size: 4096

How could I tell it to send all the glues when the EDNS buffer size
is large enough? I do not find such an option in the
documentation.

Try using --disable-minimal-responses for ./configure.

It is removing the optional additional section records that make the
packet above the fragmentation size. That is enabled by default.

Best regards, Wouter

a message of 108 lines which said:

Try using --disable-minimal-responses for ./configure.

It works, thanks.

But it is not very convenient if you use a package and do not compile
yourself. Would it be possible to make it a configurable option and
not just a compile-time one?

Stephane,

how often would be this option used? In most cases the minimal responses
are what you want (even if you don't know you want it :)).

Let's not bikeshed the (nsd and general) config files, please...

Cheers,

Hello All,

I'm looking at minimal responses and i wanted to get some input about
how it works. I understand that

" The minimal response size is 512 (no-EDNS), 1480 (EDNS/IPv4),
1220 (EDNS/IPv6), or the advertised EDNS buffer size if that is
smaller than the EDNS default."

What i wanted to ask is how does the name server decided what parts of
the additional section is removed? For instance if the query came in
over IPv6 would nsd attempt to add AAAA glue before A glue. If the zone
is signed will it attempt to only add glue if it can also add the rrsig
record?

Finally i thought that you would have to include at lease on glue record
in the additional section otherwise a resolution is not possible.
However nsd will answer with an empty additional section even if all
labels in the NS set are in zone. Is this an error or have i missed
something?

I have set up an example.com zone on one of my server's to demonstrate
this. The following query produces no glue records in the additional
section.

dig ns example.com. @5.28.62.36 +bufsize=1440 +norec

increasing the bufsize does add additional glue until you get to 1.5k
at which point the hard limit in nsd kicks in. you can also see that no
glue is given over dnssec but the bufsize at this point is already over
the 1500 limit

dig +dnssec ns example.com. @5.28.62.36 +bufsize=1620 +norec

can also test this over ipv6 @2001:41c9:1:41c::36

thanks John

Hi John,

What i wanted to ask is how does the name server decided what parts of
the additional section is removed? For instance if the query came in
over IPv6 would nsd attempt to add AAAA glue before A glue. If the zone
is signed will it attempt to only add glue if it can also add the rrsig
record?

I can't answer this as I don't know the code, but the NSD developers
should be able to.

However, the idea of preferring glue based on the query's address family
has been added to BIND recently. Look at the 9.10.4 release notes.
However, I don't think NSD pays attention to the query's address family
when deciding which glue to add.

Finally i thought that you would have to include at lease on glue record
in the additional section otherwise a resolution is not possible.
However nsd will answer with an empty additional section even if all
labels in the NS set are in zone. Is this an error or have i missed
something?

I have set up an example.com zone on one of my server's to demonstrate
this. The following query produces no glue records in the additional
section.

dig ns example.com. @5.28.62.36 +bufsize=1440 +norec

Right, so here, NSD isn't providing any glue. However... the recursor
already has at least one address that it knows answers for example.com
(because the response had AA), and this address is 5.28.62.36. So the
recursor should be able to follow up with A and AAAA queries to
5.28.62.36 for all those NS records it got in the answer.

However, if the response from 5.28.62.36 had not been an authoritative
answer, but rather a delegation, then missing glue would make resolution
fail. NSD should recognise this, and set the TC bit in the response to
encourage the client to come back over TCP.

Regards,
Anand

I have set up an example.com zone on one of my server's to demonstrate
this. The following query produces no glue records in the additional
section.

dig ns example.com. @5.28.62.36 +bufsize=1440 +norec

Right, so here, NSD isn't providing any glue. However... the recursor
already has at least one address that it knows answers for example.com
(because the response had AA), and this address is 5.28.62.36. So the
recursor should be able to follow up with A and AAAA queries to
5.28.62.36 for all those NS records it got in the answer.

Ahh yes thanks

However, if the response from 5.28.62.36 had not been an authoritative
answer, but rather a delegation, then missing glue would make resolution
fail. NSD should recognise this, and set the TC bit in the response to
encourage the client to come back over TCP.

So i created a delegation and i still receive no glue see the following

dig ns sub.example.com. @5.28.62.36 +bufsize=1444 +norec
dig ns sub.example.com. @2001:41c9:1:41c::36 +bufsize=1444 +norec

This server will also allow axfr for the example.com and the nsd config
is available as here
https://gist.github.com/b4ldr/ec7e27c96099da0c86c815340c286697

Thanks John

John,

The NS is 40 records that requires a 1444 byte answer so when I increased the buffer size to 3K
I got two A records indicating that the server is limiting answers it gives out over UDP
With tcp I got

;; Query time: 89 msec
;; SERVER: 5.28.62.36#53(5.28.62.36)
;; WHEN: Wed May 11 15:13:04 EDT 2016
;; MSG SIZE rcvd: 3204

check your settings for

**ipv4-edns-size: <number>**
Preferred EDNS buffer size for IPv4.
**ipv6-edns-size: <number>**
Preferred EDNS buffer size for IPv6.

Olafur

Hi Olafur,

The NS is 40 records that requires a 1444 byte answer so when I increased the buffer size to 3K
I got two A records indicating that the server is limiting answers it gives out over UDP
With tcp I got
;; Query time: 89 msec
;; SERVER: 5.28.62.36#53(5.28.62.36)
;; WHEN: Wed May 11 15:13:04 EDT 2016
;; MSG SIZE rcvd: 3204

check your settings for
ipv4-edns-size: <number>
Preferred EDNS buffer size for IPv4.
ipv6-edns-size: <number>
Preferred EDNS buffer size for IPv6.

Both of these are set to 4k on the server side. however the dig
commands i use are forcing the edns size to 1444 to highlight this
issue. For clarity and to remove edns from the equation i have created
a delegation that will never send glue records unless one queries over
TCP. Furthermore TC=1 will never be sent unless your edns buff size is
< 1480.

`dig ns sub1.example.com. @5.28.62.36`

This is been controlled by the minimum response size feature introduced
in nsd 3.2.9

'''
Minimize responses to reduce truncation: NSD will only add optional
records to the authority and additional sections when the response size
does not exceed the minimal response size.

The minimal response size is 512 (no-EDNS), 1480 (EDNS/IPv4), 1220
(EDNS/IPv6), or the advertized EDNS buffer size if that is smaller than
the EDNS default.
'''

My expectation is that nsd should always endeavour to send at least one
glue record when answering with a delegation. Otherwise recursion will
fail at this point and in this case sub1.example.com would never resolve.

Thanks John

Hi,

Hi Olafur,

The NS is 40 records that requires a 1444 byte answer so when I increased the buffer size to 3K
I got two A records indicating that the server is limiting answers it gives out over UDP

My expectation is that nsd should always endeavour to send at least one
glue record when answering with a delegation. Otherwise recursion will
fail at this point and in this case sub1.example.com would never resolve.

I have implemented the following fixes (in the code repository, works
with the example.com zone that John set up): NSD includes AAAA before A
when the query is over IPv6 for glue. NSD sets TC if it cannot provide
at least one glue (only for delegations that have glue; only glue of the
matching address family counts).

I hope this resolves this issue.

Best regards, Wouter

Hi Wouter

thanks for the speedy response I have checked out trunk and this seems
to work as expected however it introduces another curiosity.

With sub.example.com i can control the amount of glue i get by changing
the bufsize. for example

The following will result in TC been received and the query been
preformed over tcp

`dig ns sub.example.com. @5.28.62.36 +bufsize=1444`

The following queries will produce one and two glue records respectively

dig ns sub.example.com. @5.28.62.36 +bufsize=1460
dig ns sub.example.com. @5.28.62.36 +bufsize=1476

Increasing the buf size beyond this has no further effect and you will
only ever revive two glue records.

This is not such an issue until we consider the sub1.example.com. With
this zone the answer section with one glue record is above the 1500 byte
minimial-responses limit for IPv4. This means that no matter what value
one advertises in EDNS they will always be given an answer with TC=1. This

Im not suggesting this behavior is incorrect and can see the benefits in
avoiding fragmentation. However with this discussion and the comments
from Stephane last week. i wonder if it is worth considering having a
config item for minimal response size. something like

ipv4-minimal-response: <number or edns>
  NSD will only add optional records to the authority and additional
sections when the response size does not exceed this value in bytes or
the advertised EDNS size if set to 'edns'. The default is 1480

ipv6-minimal-response: <number or edns>
  NSD will only add optional records to the authority and additional
sections when the response size does not exceed this value in bytes or
the advertised EDNS size if set to 'edns'. The default is 1220