Am 15.09.2017 um 09:37 schrieb Harshith Mulky:
> Hello Experts,
>
> I had a query on advertising the payload size on client in DNS Responses
> over UDP/TCP
>
>
> This is as much I have understood from RFC 6891, that a
> requester(client) can address his capabilities to restrict the UDP
> Payload size to a limit between 512 to 4096 bytes based on his
> limitation when supporting EDNS Procedures.
>
> Is it the same case with TCP?
>
> Can we(client) advertize our capabilities over TCP to limit the payload
> size in Responses?
why would you want do do that?
TCP don't suffer from the problem of a faked sourcip and the repsonse
going back to the attacke victim! what do you imagine to happen when
your response data is larger? in case of UDP the fallback is simply TCP
and then you want to cripple that fallback?
[Harshith] But I do not understand why would OPT section required in a TCP
Query. As i see from my Traces, Even TCP Queries carry a OPT section with the
advertized sizes the client supports! Why would this be necessary? I do not
want to cripple the fallback, but if a query is intending to do so from a
resolver, how Do we stop that?
Thanks
________________________________
From: bind-users <bind-users-boun...@lists.isc.org> on behalf of
bind-users-requ...@lists.isc.org <bind-users-requ...@lists.isc.org>
Sent: Friday, September 15, 2017 5:30 PM
To: bind-users@lists.isc.org
Subject: bind-users Digest, Vol 2734, Issue 2
Send bind-users mailing list submissions to
bind-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org
You can reach the person managing the list at
bind-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."
Today's Topics:
1. Re: What is wrong with my second $ORIGIN (Harshith Mulky)
2. Re: Is there a need for clients to advertize the capabilities
for DNS Responses over TCP (Reindl Harald)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Sep 2017 01:16:08 -0700 (MST)
From: Harshith Mulky <harshith.mu...@outlook.com>
To: bind-users@lists.isc.org
Subject: Re: What is wrong with my second $ORIGIN
Message-ID: <1505463368415-0.p...@n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
Than you All.
Did not notice I had missed a trailing '.'
Will make sure I do not miss these things the next time I test
--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
------------------------------
Message: 2
Date: Fri, 15 Sep 2017 12:30:23 +0200
From: Reindl Harald <h.rei...@thelounge.net>
To: bind-users@lists.isc.org
Subject: Re: Is there a need for clients to advertize the capabilities
for DNS Responses over TCP
Message-ID: <ac3458f0-305d-fc4f-868b-bd5ffed1f...@thelounge.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Am 15.09.2017 um 09:37 schrieb Harshith Mulky:
> Hello Experts,
>
> I had a query on advertising the payload size on client in DNS Responses
> over UDP/TCP
>
>
> This is as much I have understood from RFC 6891, that a
> requester(client) can address his capabilities to restrict the UDP
> Payload size to a limit between 512 to 4096 bytes based on his
> limitation when supporting EDNS Procedures.
>
> Is it the same case with TCP?
>
> Can we(client) advertize our capabilities over TCP to limit the payload
> size in Responses?
why would you want do do that?
TCP don't suffer from the problem of a faked sourcip and the repsonse
going back to the attacke victim! what do you imagine to happen when
your response data is larger? in case of UDP the fallback is simply TCP
and then you want to cripple that fallback?
------------------------------
Subject: Digest Footer
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
------------------------------
End of bind-users Digest, Vol 2734, Issue 2
*******************************************
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
