Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

edns responses not sent by DNS Server

311 views
Skip to first unread message

Harshith Mulky

unread,
May 30, 2017, 3:39:44 AM5/30/17
to bind-...@lists.isc.org
Hello Experts,

I have bind installed on OpenSuse 13.2 with version: bind-9.9.5P1

I am doing a Test with client application telling that edns is supported on
DNS Server with udp-payload-size supported as 512 bytes

I have the following configuration on my DNS Server

server 127.0.0.1 {
edns yes;
edns-udp-size 512; //max size query sever can receive is upto 4096
bytes(default value=4096 )
max-udp-size 512; //max size server can transfer is upto 4096
bytes(default value =4096)
};

When my client is querying the external DNS Server, it is adding OPT RR
pseudo section for edns query

The query as below

Domain Name System (query)
[Response In: 116]
Transaction ID: 0xc015
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data: Unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
pcr21381.dflt.vzb.com: type NAPTR, class IN
Name: pcr21381.dflt.vzb.com
Type: NAPTR (Naming authority pointer)
Class: IN (0x0001)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (EDNS0 option)
UDP payload size: 512
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0

The answer to this query does not contain anything. The size of my answer
bytes is greater than 512(which i checked using dig) Will bind
limit/truncate/not send answers if it does not fall below the
max-udp-payload size

The answer is coming as below

Domain Name System (response)
[Request In: 115]
[Time: 0.000318000 seconds]
Transaction ID: 0xc015
Flags: 0x8720 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for
domain
.... ..1. .... .... = Truncated: Message is truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive
queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..1. .... = Answer authenticated: Answer/authority portion
was authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
pcr21381.dflt.vzb.com: type NAPTR, class IN
Name: pcr21381.dflt.vzb.com
Type: NAPTR (Naming authority pointer)
Class: IN (0x0001)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0


When i do a dig with these options I do not see any issues:

[ssuser@hmslavepsxvm1 BIN]$ dig @FD00:10:6B50:41C0:0:0:0:9B
pcr21381.dflt.vzb.com NAPTR +norecurse +edns=0 +bufsize=512
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.6.0-P1 <<>> @FD00:10:6B50:41C0:0:0:0:9B pcr21381.dflt.vzb.com
NAPTR +norecurse +edns=0 +bufsize=512
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50716
;; flags: qr aa; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pcr21381.dflt.vzb.com. IN NAPTR

;; ANSWER SECTION:
pcr21381.dflt.vzb.com. 300 IN NAPTR 11 38 "u" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 10 34 "s" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 11 36 "u" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 11 35 "u" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 10 34 "s" "SIP+D2T" ""
_sip._tcp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 11 40 "u" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 11 37 "u" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 11 39 "u" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.
pcr21381.dflt.vzb.com. 300 IN NAPTR 11 41 "u" "SIP+D2U" ""
_sip._udp.pcr21381.dflt.vzb.com.




--
View this message in context: http://bind-users-forum.2342410.n4.nabble.com/edns-responses-not-sent-by-DNS-Server-tp3884.html
Sent from the Bind-Users forum mailing list archive at Nabble.com.

Mark Andrews

unread,
May 30, 2017, 4:10:10 AM5/30/17
to Harshith Mulky, bind-...@isc.org
No. The answer contains a indication that the answer is truncated
and there is a OPT (EDNS) record. The client should retry the query
using TCP which is what DiG does below. This is standard client
behaviour. If your client does not do this then it is broken and
you should complain to the vendor.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Harshith Mulky

unread,
May 30, 2017, 5:15:40 AM5/30/17
to bind-...@lists.isc.org
Hello Mark,

Yes the client is retrying the query over TCP.

But initially I am getting no Answers
The ANSWER is as below

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18094
;; flags: qr aa tc rd ad ; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL:
1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;pcr21381.dflt.vzb.com. IN NAPTR

Should the server be sending some responses which are truncated (or) no
Responses in this case?





--
View this message in context: http://bind-users-forum.2342410.n4.nabble.com/edns-responses-not-sent-by-DNS-Server-tp3884p3886.html

Mark Andrews

unread,
May 30, 2017, 7:20:13 AM5/30/17
to Harshith Mulky, bind-...@isc.org

In message <14961348563...@n4.nabble.com>, Harshith Mulky writes:
> Hello Mark,
>
> Yes the client is retrying the query over TCP.
>
> But initially I am getting no Answers
> The ANSWER is as below
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18094
> ;; flags: qr aa tc rd ad ; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL:
> 1
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;pcr21381.dflt.vzb.com. IN NAPTR
>
> Should the server be sending some responses which are truncated (or) no
> Responses in this case?

The protocol allows for either behaviour.

Mark

> --
> View this message in context: http://bind-users-forum.2342410.n4.nabble.com/edns-responses-not-sent-by-DNS-Server-tp3884p3886.html
> Sent from the Bind-Users forum mailing list archive at Nabble.com.

Harshith Mulky

unread,
May 30, 2017, 7:33:44 AM5/30/17
to bind-...@lists.isc.org
Can this be controller in the Bind Server?

Are there any options to control this behavior?



--
View this message in context: http://bind-users-forum.2342410.n4.nabble.com/edns-responses-not-sent-by-DNS-Server-tp3884p3889.html

Barry Margolin

unread,
May 30, 2017, 11:45:38 AM5/30/17
to comp-protoc...@isc.org
In article <mailman.206.149613...@lists.isc.org>,
Harshith Mulky <harshit...@outlook.com> wrote:

> Hello Mark,
>
> Yes the client is retrying the query over TCP.
>
> But initially I am getting no Answers
> The ANSWER is as below
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18094
> ;; flags: qr aa tc rd ad ; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL:
> 1
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;pcr21381.dflt.vzb.com. IN NAPTR
>
> Should the server be sending some responses which are truncated (or) no
> Responses in this case?

BIND will omit the Additional Section (and maybe also the Authority
Section?) if that allows the response to fit. Otherwise I believe it
just sends an empty response, and the client is supposed to retry with
TCP.

The problem with sending a partial Answer Section is that there's no way
for the client to know if the omitted answers are important. So it has
to retry anyway.

--
Barry Margolin
Arlington, MA
0 new messages