RE: What is wrong with my second $ORIGIN

2017-09-15 Thread Darcy Kevin (FCA) 
Just as a general piece of advice, if you're trying to troubleshoot a zonefile 
parsing issue, sometimes it's useful to just do a zone transfer of the loaded 
zone and eyeball it. This is obviously more practical with a smaller zone (such 
as the one you showed) than a huge one, but even if the zone is large, you can 
focus on only the specific names/RRsets that you consider problematic.

In this case, a zone transfer would have shown the $ORIGIN being appended to 
the name in the input file which was missing the trailing period. It should 
have stuck out like a sore thumb, as they say, because the name would have been 
long and strange-looking. Sometimes that's a really quick way to home in on the 
problem than to stare at the input zone file and mimic the zonefile-parsing 
algorithm in one's head.

Of course, this assumes the zone loaded at all. It's possible to mess up a 
zonefile so much that it doesn't even load, but, in such cases, BIND usually 
gives a very specific error message about what's wrong. So those don't tend to 
lead to "mysteries" like the more subtle errors do (e.g. trailing-period 
omissions).


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Harshith Mulky
Sent: Friday, September 15, 2017 4:16 AM
To: bind-users@lists.isc.org
Subject: Re: What is wrong with my second $ORIGIN

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/
___
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
___
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

Re: Is there a need for clients to advertize the capabilities for DNS Responses over TCP

2017-09-15 Thread Warren Kumari 
On Fri, Sep 15, 2017 at 3:37 AM, Harshith Mulky
 wrote:
> 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?

What is it that you are actually trying to accomplish / why?
I'm going to assume that this is to deal with some sort of brokenness
and not just idle curiosity[0].

If you are actually experiencing issues with DNS over TCP it is most
likely that you have some sort of broken path MTU discovery issue, and
have a lower than expected MTU (this is likely also affecting other
applications), but it could also be some broken middle box -- for
example Cisco PIX has some, er, interesting DNS TCP artifacts:
"Customers with NAT configured on a Cisco IOS device may experience
issues receiving large DNS query response messages when TCP is used as
the transport. Cisco IOS NAT does not have support for reassembling
TCP segments. The lack of support for TCP segment reaasembly is a
well-known issue that is documented under the question "Q. What is the
difference between IP fragmentation and TCP segmentation?" at the
following link:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml.
"

Anyway, without knowing more it is tricky to know what your actual
issue is, but a: fixing pMTUd by making sure ICMP is allowed would
likely be helpful, or b: decreasing the MTU / MSS to your actual MTU
may help.

W
[0]: Which is also fine, but I needed to start somewhere.


>
>
> Thanks
>
> Harshith
>
>
>
> ___
> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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

Re: Is there a need for clients to advertize the capabilities for DNS Responses over TCP

2017-09-15 Thread Reindl Harald 


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?

___
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

Re: What is wrong with my second $ORIGIN

2017-09-15 Thread Harshith Mulky 
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/
___
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

Is there a need for clients to advertize the capabilities for DNS Responses over TCP

2017-09-15 Thread 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?


Thanks

Harshith

___
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