now when I create a new record and check the propagation
That's not how DNS works. Every single recursive system in operation throughout the internet has to learn about the individual records (barring proof of nonexistence provided by DNSSEC signed zones -- see kasperd's answer), and many of those have limits defined for the maximum TTL that they're willing to honor. The servers also forget this cached information whenever they are restarted. This is an unwinnable war against an internet's worth of recursive systems that in all likelihood outnumber the actual devices requesting your DNS records.
Is that a good practice?
Even if we operate under the assumption that you can use cached data to put a significant dent in what remote systems throughout the internet are asking for, the answer is still no. Many people are unaware of the fact that most recursive DNS implementations cache the non-existence of records in addition to their existence. Instead of feeding DNS servers bogus data that will simply take up more space in DNS caches and confuse the people who are trying to request the resource (because you're telling them to talk to an IP instead of telling them it doesn't exist), you should simply be telling those servers to remember your non-existent records for longer. As kasperd rightly points out, interfering with NXDOMAIN actually prevents recursive systems from determining nonexistence without submitting additional queries.
The negative TTL is controlled by the NEGATIVE field of the TTL, and the TTL of the SOA record itself. The minimum (lesser) of the two values prevails. Kudos to Håkan for the reminder!
example.com. IN SOA ns.example.com. hostmaster.example.com. (
2003080800 ; sn = serial number
172800 ; ref = refresh = 2d
900 ; ret = update retry = 15m
1209600 ; ex = expiry = 2w
3600 ; nx = nxdomain ttl = 1h
(sample SOA record borrowed from DNS for Rocket Scientists)
Your effective negative TTL tells remote recursive servers how many seconds they should wait before asking again if a record doesn't exist. The drawback is (unsurprisingly) that you shoot yourself in the foot if your company prematurely starts directing customers to a DNS record before it is actually live. Fortunately you can't shoot yourself in the foot too badly, as most DNS server software ignores very high TTL values (including negative) that are above a maximum that they've defined in their local configuration.
In short, it's almost always best to be honest about a record's nonexistence.
Advertise a smaller negative TTL if you want remote servers to remember the non-existence of your data longer, or identify why you get so many stale requests for data and solve the problem at its source. (out of date links, etc.)